Sí, el TPV virtual es seguro: ni ves ni guardas la tarjeta, y la ley obliga a la doble verificación

Vas a empezar a cobrar por internet, o ya lo haces, y te ronda la misma duda que a casi todo el mundo: meter un formulario de pago en tu web suena a abrir una puerta. ¿Y si alguien roba las tarjetas de mis clientes? ¿Y si me cuelan una robada y el marrón es mío? Normalmente la pregunta se resume en una frase: "¿esto del TPV virtual es fiable o me estoy metiendo en un lío?".

¿Dónde está la tarjeta de mi cliente?

Esta es la pieza que cambia toda la respuesta, y casi nadie la explica. En un TPV virtual bien montado, el número de la tarjeta no pasa por tu servidor ni se queda en tu base de datos. Cuando el cliente va a pagar, o bien lo teclea en una página del banco o de la pasarela (no en la tuya), o bien lo teclea en un campo que la pasarela ha incrustado en tu web pero que envía el dato directamente a sus sistemas, cifrado, sin que tu código lo llegue a leer.

Tú, al final de la operación, recibes dos cosas: que el pago salió bien y una referencia de la operación. El número largo de la tarjeta no está entre ellas. Eso significa que, aunque alguien reventara tu web mañana, ahí no hay tarjetas que robar: no las tienes.

Quien sí las maneja —el banco o la pasarela— está obligado a cumplir un estándar de seguridad específico para datos de tarjeta, el PCI DSS, que es un conjunto de reglas sobre cómo se guardan, se cifran y se transmiten esos datos. No es una etiqueta de marketing: es el motivo por el que tiene sentido que la tarjeta la custodie quien está preparado para ello y no tu tienda. Si estás montando el cobro online y quieres que esa frontera quede bien puesta desde el principio, es justo el primer punto que miramos al montar pagos e integraciones para un negocio.

Las capas de seguridad de un cobro online, y quién pone cada una

Un cobro por internet no está protegido por una sola cosa, sino por varias que se apilan. Lo útil es ver cuáles te tocan a ti y cuáles vienen de serie:

Fíjate en el reparto: la mayoría de las capas no las pones tú. Lo tuyo es poco y concreto —tener la web en HTTPS y elegir un proveedor serio—; el peso de la seguridad lo llevan el banco y la pasarela. Eso es, en el fondo, por qué el TPV virtual es seguro aunque tú no seas experto en seguridad: no te pide que lo seas.

¿El TPV virtual de Redsys es fiable?

Es la pregunta concreta que se hace mucha gente, porque Redsys es lo que hay detrás del "TPV virtual" de casi todos los bancos españoles. La respuesta corta es que sí, y por el mismo motivo de antes: en la integración habitual de Redsys, el cliente acaba tecleando la tarjeta en una página del propio Redsys (tu web le "redirige" allí un momento), paga, y vuelve a tu tienda con la confirmación. Tu web nunca ve el número.

Que Redsys sea fiable no es una cuestión de confiar en una marca, sino de entender ese reparto: la plataforma que procesa millones de pagos al día es quien custodia el dato sensible, y tu tienda se queda solo con el "sí, cobrado". Si ya estás decidiendo entre el TPV virtual del banco (sobre Redsys) y una pasarela como Stripe, la comparación de fondo —comisiones, flexibilidad, a quién llamas si falla— la vimos en Stripe o Redsys: qué pasarela conviene a tu negocio; aquí nos quedamos en que, en seguridad, las dos opciones parten de la misma base sólida.

¿Qué es la autenticación reforzada y por qué te protege?

Habrás notado que, desde hace unos años, pagar por internet casi siempre te pide un segundo paso: un código que llega por SMS, la huella, o confirmar en la app del banco. Eso es la autenticación reforzada de cliente (lo verás también como SCA, o por su implementación técnica, 3D Secure). No es un capricho del banco: lo obliga la ley de servicios de pago.

El Real Decreto-ley 19/2018, en su artículo 68, lo dice así de claro:

"Los proveedores de servicios de pago aplicarán la autenticación reforzada de clientes [...] cuando el ordenante: a) acceda a su cuenta de pago en línea; b) inicie una operación de pago electrónico; c) realice por un canal remoto cualquier acción que pueda entrañar un riesgo de fraude en el pago u otros abusos."

Para ti, como comercio, esto es una red de seguridad que no tienes que montar: el banco del comprador verifica que quien paga es de verdad el dueño de la tarjeta antes de dar el cobro por bueno. Y tiene una consecuencia práctica importante, que es la que de verdad te interesa.

Si me cuelan una tarjeta robada, ¿quién paga?

Aquí está el miedo real, más que el del robo de datos. La respuesta depende de una sola cosa: si se aplicó la autenticación reforzada.

Cuando el pago pasó por esa doble verificación del banco, la responsabilidad del fraude recae normalmente en el banco emisor, no en ti: fue él quien dio el visto bueno a que esa persona era quien decía ser. El problema aparece al revés: cuando por lo que sea esa verificación no se aplicó y hubo fraude, el comercio puede terminar asumiendo el contracargo. Por eso el consejo es simple y gratis: asegúrate de que tu TPV virtual tiene activada la autenticación reforzada, que a fecha de hoy es lo estándar y te lo dan de serie casi en cualquier proveedor.

A eso se le suma la protección antifraude que añade la propia pasarela: sistemas que miran la operación y levantan la mano cuando algo huele raro (muchos intentos seguidos, una tarjeta de un país que no cuadra, importes anómalos). No es infalible, pero trabaja a tu favor sin que tú hagas nada, y puedes afinarlo con reglas si tu negocio lo pide.

¿Qué riesgo sí sigue siendo tuyo?

Conviene ser honesto, porque un comparador no te lo va a decir: el TPV virtual resuelve muy bien la seguridad del dato y buena parte del fraude, pero no te quita un riesgo que no es informático, el contracargo por disputa.

Es esto: un cliente real, que sí hizo la compra, reclama el cargo a su banco. A veces de mala fe, pero muchas veces no: no reconoce el nombre que le aparece en el extracto, o dice que no le llegó el pedido. Eso no es un fallo de seguridad del TPV virtual —el cobro se hizo bien—, sino una disputa comercial, y se resuelve con pruebas: un justificante de entrega, una descripción del cobro que el cliente reconozca, un correo de confirmación. No se arregla con más cifrado; se arregla teniendo ordenada la trazabilidad de cada venta, que es otra conversación.

Un ejemplo con números

Una tienda online pequeña que factura unos 8.000 € al mes en pedidos con tarjeta no guarda ni una sola tarjeta: todas las operaciones pasan por el TPV virtual de su banco sobre Redsys, con la doble verificación activada. En un año recibe un par de intentos de pago con tarjeta robada; los dos los frena el banco en el paso de autenticación, antes de que llegue a cobrarse nada, así que no hay ni cargo ni marrón que gestionar.

Lo que sí le llega, una o dos veces en el año, es un contracargo por disputa: un cliente que no reconoció el cargo en su extracto. Se resuelve enseñando el justificante del pedido y su entrega. Moraleja del caso tipo: el dinero y el esfuerzo no se le van en seguridad informática —esa la lleva la infraestructura—, sino en tener cada venta bien documentada para cuando toca demostrar que el cobro era legítimo.

Si estás montando tu cobro online y no tienes claro cómo dejar bien puesta esta frontera —qué pasa por tu web y qué no— escríbenos a contact@easybyte.es y lo miramos juntos.