Pagos
Tokenización de pagos
La tokenización de pagos consiste en reemplazar los detalles de la tarjeta con un token de referencia para que un comerciante pueda cobrar una credencial almacenada repetidamente sin tener que guardar el número de tarjeta en sí.
Es lo que hace posible la facturación recurrente sin que cada comerciante se convierta en una bóveda de tarjetas dentro del alcance de PCI. El token carece de significado fuera del contexto que lo emitió, lo cual es la propiedad de seguridad.
Esa misma propiedad es la comercial. Un token emitido por una plataforma o proveedor de aplicaciones generalmente no puede ser utilizado por nadie más, por lo que quien lo posee tiene su capacidad de facturar. Establezca la portabilidad por escrito antes de tener una base de suscriptores lo suficientemente grande como para que importe.
Qué se está reemplazando y qué es realmente un token
Lo que se protege es el número de cuenta principal —el PAN, el número largo en el anverso de la tarjeta— junto con la fecha de caducidad y, en el momento de la entrada, el código de seguridad. Esos tres valores son datos del titular de la tarjeta, y guardarlos es lo que arrastra a un negocio al extremo costoso de PCI DSS.
Un token reemplaza el PAN con un valor que no tiene relación matemática con él. Esa es la distinción con el cifrado, y no es pedante: el texto cifrado puede ser revertido por cualquiera que obtenga la clave, mientras que un token solo puede ser resuelto por la bóveda que contiene el mapeo. Robar una base de datos de tokens no produce nada sin comprometer también la bóveda, que es un sistema separado bajo control separado.
Los tokens vienen en dos formas y se confunden constantemente. Los tokens que preservan el formato se parecen a los números de tarjeta —misma longitud, pasando la misma suma de verificación— para que puedan viajar a través de sistemas construidos para transportar un PAN. Los tokens opacos son identificadores arbitrarios, las cadenas de estilo `tok_` y `pm_` familiares de las APIs modernas, y no pueden hacerse pasar por una tarjeta en ningún lugar.
La confusión más importante es entre un solo uso y múltiples usos. El valor que un campo de pago del lado del cliente entrega a su servidor suele ser un token de un solo uso: existe para llevar una entrada de tarjeta del navegador al procesador sin tocar su infraestructura, y muere en el primer uso. El valor que usted almacena para futuras facturaciones es un objeto completamente diferente —una referencia de bóveda duradera, creada deliberadamente, que sobrevive para ser cobrada de nuevo. Tratar el primero como el segundo es cómo los equipos descubren en la primera renovación que nunca guardaron nada.
Tres tipos de token, y no son intercambiables
La palabra abarca varias configuraciones que difieren en quién posee el mapeo, y ese único hecho determina todo sobre la portabilidad, la resiliencia y lo que sucede cuando la tarjeta es reemitida.
Un token de bóveda de pasarela o PSP es el caso común y el más limitado: el mapeo reside en la base de datos de un proveedor y no significa nada fuera de ella. Un proveedor de servicios de token independiente tiene la misma forma con la bóveda bajo un techo diferente, elegido precisamente para que la bóveda no sea propiedad de la parte que quizás desee dejar. Un token de red, descrito en su propia entrada, es emitido por la red de tarjetas y es el único de los tres que las propias redes mantienen.
| Tipo | Quién posee el mapeo | Sobrevive a la reemisión de la tarjeta | Utilizable por otro procesador |
|---|---|---|---|
| Token de pago de un solo uso | El procesador, brevemente | No aplicable — expira con el uso | No |
| Token de bóveda de pasarela o PSP | El proveedor de pagos | No, sin un actualizador de cuentas | No — se requiere una transferencia de bóveda |
| Proveedor de servicios de token independiente | Un proveedor de bóvedas con el que contrata directamente | No, sin un actualizador de cuentas | Sí — esa es la razón para usar uno |
| Token de red | La red de tarjetas | Sí, automáticamente | Depende del acuerdo con el solicitante del token |
Cómo reduce el alcance de PCI y dónde el alcance no desaparece
El alcance de PCI DSS sigue a los datos del titular de la tarjeta. Los sistemas que almacenan, procesan o transmiten un PAN están dentro del alcance; los sistemas que solo guardan tokens no lo están, porque un token no son datos del titular de la tarjeta. Por lo tanto, la tokenización es una técnica de reducción de alcance antes que cualquier otra cosa.
La reducción solo se materializa si el número de tarjeta realmente nunca llega a sus servidores. Eso es lo que los campos alojados, un iframe del procesador, la tokenización del lado del cliente y las redirecciones completas existen para lograr. Una integración que envía la tarjeta a su backend y la tokeniza allí ha sacado el almacenamiento del alcance, dejando el procesamiento y la transmisión firmemente dentro de él, lo cual es un ahorro mucho menor de lo que sugiere el diagrama de arquitectura.
Lo que sobrevive es la propia página de pago. Usted sigue controlando la página que carga el campo de pago, y un script inyectado en esa página puede leer una tarjeta antes de que el procesador la vea. PCI DSS v4 aborda esto directamente con requisitos que cubren la gestión de scripts en las páginas de pago y la detección de manipulaciones en esas páginas — 6.4.3 y 11.6.1. Ninguno de ellos se cumple mediante la tokenización.
El resumen honesto es que la tokenización traslada a un comerciante de probar la seguridad de una bóveda de tarjetas a probar la integridad de una página de pago. Ese es un intercambio mucho mejor, y no es lo mismo que no tener obligaciones.
La trampa de la portabilidad: un token de pasarela no se mueve
La propiedad que hace que un token sea seguro es que carece de significado fuera del contexto que lo emitió. Esa propiedad no distingue entre un atacante y su próximo proveedor de pagos.
La migración de un libro de credenciales almacenadas, por lo tanto, requiere una transferencia de bóveda a bóveda: el proveedor saliente exporta los datos de la tarjeta bajo condiciones compatibles con PCI al proveedor entrante, quien los vuelve a tokenizar. Este es un procedimiento bien establecido, ambas partes pueden hacerlo, y requiere la cooperación de una empresa cuyo interés comercial se beneficia de que la transferencia no ocurra. La alternativa es pedir a cada suscriptor activo que vuelva a introducir una tarjeta, y una parte significativa de ellos simplemente no lo hará — eso no es una baja que se recupera, es una baja que usted causó.
La cláusula a asegurar es el derecho a exportar credenciales almacenadas a un proveedor alternativo nombrado, bajo solicitud, dentro de un período establecido, a un costo establecido. No cuesta nada negociar antes de tener una base de suscriptores y es casi imposible de obtener una vez que la base existe.
Almacenamiento de una credencial para facturación recurrente
Un token por sí solo no es suficiente para volver a facturar a un cliente. Lo que hace válida una carga posterior es el registro de consentimiento que lo acompaña, y ese registro tiene varias partes que una migración ingenua deja atrás.
La credencial almacenada necesita el mandato: a qué accedió el cliente, cuándo accedió, la versión de los términos que aceptó, y la cadencia y el monto a los que dio su consentimiento. Necesita el tipo de transacción — recurrente, a plazos o no programada — porque las redes los tratan de manera diferente. Y necesita el identificador de transacción de red devuelto por la autorización original iniciada por el cliente, que los cargos posteriores iniciados por el comerciante deben referenciar para ser reconocidos como continuaciones autorizadas en lugar de como cargos no adjuntos contra una tarjeta.
Ese último campo es el que se pierde. Una migración que mueve tokens pero no los identificadores de transacción de red originales deja al procesador receptor incapaz de presentar las renovaciones como transacciones válidas iniciadas por el comercio, y el resultado es una tasa de autorización que cae en el primer ciclo de facturación después del cambio por razones que nadie en el plan del proyecto anticipó.
Junto con la credencial en sí, vale la pena conservar lo que se le permite guardar para mostrar y para predicción: la marca de la tarjeta, los últimos cuatro dígitos y la fecha de vencimiento. Eso es lo que permite a un cliente reconocer qué tarjeta está registrada, y lo que le permite identificar las credenciales que caducarán antes de la próxima renovación y contactar a esos clientes antes de que el cargo falle.
Preguntas frecuentes
- ¿Qué es la tokenización de pagos?
- La tokenización de pagos reemplaza un número de tarjeta con un valor sustituto, un token, que no tiene relación matemática con la tarjeta. Una bóveda guarda el mapeo entre ambos. El comercio almacena solo el token y lo presenta para cobrar al cliente de nuevo, por lo que los datos de la tarjeta nunca residen en los sistemas del comercio mientras la facturación recurrente sigue funcionando.
- ¿Cuál es la diferencia entre tokenización y cifrado?
- El cifrado transforma un número de tarjeta en texto cifrado que cualquiera que tenga la clave puede revertir, por lo que la protección viaja con los datos y depende de la gestión de claves. La tokenización sustituye un valor no relacionado y mantiene el mapeo en una bóveda separada, por lo que una base de datos de tokens robada no produce nada por sí misma. El cifrado protege los datos en movimiento; la tokenización los elimina por completo de sus sistemas.
- ¿La tokenización de pagos reduce el alcance de PCI?
- Sí, si el número de tarjeta nunca llega a sus servidores. Los sistemas que solo contienen tokens están fuera de alcance porque los tokens no son datos del titular de la tarjeta, por lo que existen los campos alojados, los iframes y la tokenización del lado del cliente. El alcance no desaparece: la página de pago sigue siendo suya, y los requisitos 6.4.3 y 11.6.1 de PCI DSS v4 cubren la gestión de scripts y la detección de manipulaciones en esa página.
- ¿Se pueden mover los tokens de pago a otro proveedor?
- No directamente. Un token de pasarela no tiene sentido fuera de la bóveda que lo emitió, por lo que la migración requiere una transferencia de bóveda a bóveda en la que el proveedor actual exporta los datos subyacentes de la tarjeta al nuevo bajo condiciones de cumplimiento de PCI. Ambas partes pueden hacerlo, pero el proveedor saliente no tiene incentivo comercial, por lo que el derecho de exportación debe figurar en el contrato antes de firmar.
- ¿Es la tokenización de pagos lo mismo que un token de red?
- Un token de red es un tipo de token de pago, emitido por Visa, Mastercard o American Express en lugar de por un proveedor de pagos. Es el único tipo que permanece válido cuando la tarjeta se reemite y el único tipo con alguna ruta a otro procesador. Un token de bóveda de pasarela es el tipo más común y no tiene ninguna de estas propiedades.
- ¿Qué más necesita además del token para facturar una suscripción?
- Necesita el registro de consentimiento: a qué accedió el cliente, cuándo, la versión de los términos aceptados, el tipo de transacción y el identificador de transacción de red devuelto por la autorización original iniciada por el cliente. Los cargos posteriores iniciados por el comercio hacen referencia a ese identificador para ser reconocidos como continuaciones autorizadas. La migración de tokens sin él suele reducir las tasas de autorización en el primer ciclo después del cambio.