Tokenización de marca: lo que realmente sucede detrás del "token de la tarjeta"
Explico de forma práctica qué es la tokenización de marca (network token), cómo funciona entre bastidores, diferencias con el token de gateway, flujo técnico de autorización, impacto en la seguridad (PCI DSS) y decisiones arquitectónicas para evitar el lock-in en integraciones de pago.
En mi día a día trabajando con integraciones de adquirentes y proveedores, ya he oído esta frase decenas de veces:
¿Pero no estamos ya tokenizando? Si no almacenamos el PAN directamente, ¿por qué esto sigue importando?
Y aquí es donde empieza la confusión.
Mucha gente mezcla:
- Token interno de la empresa
- Tokenización de marca (Visa, Mastercard, etc.)
No son lo mismo, y entender esta diferencia cambia completamente tu visión de cómo funciona todo.
Hoy quiero explicarte, de forma práctica y sin marketing, cómo funciona la tokenización de marca, qué sucede entre bastidores y qué decisiones arquitectónicas debes tomar.
Primero: el problema real
Cuando almacenas un PAN (Primary Account Number, el número de la tarjeta), entras directamente en el mundo del PCI DSS (Payment Card Industry Data Security Standard).
Esto significa:
- Un enorme alcance de seguridad
- Auditorías
- Altos costos
- Riesgo real de filtración
La tokenización de marca surge para resolver exactamente esto: dejar de traficar y almacenar el número real de la tarjeta.
Pero no es solo enmascarar. Es cambiarlo por otra cosa que funcione en la red.
¿Qué es la Tokenización de Marca?
Es un proceso en el que la marca de la tarjeta (Visa, Mastercard, ELO, etc.) sustituye el PAN por un token que:
- Parece un número de tarjeta
- Funciona como una tarjeta
- Pero no es la tarjeta real
Este token se llama DPAN (Device Primary Account Number) o simplemente Network Token.
La tarjeta real es el FPAN (Funding PAN).
Intentemos simplificarlo
Piensa en el PAN como la llave de tu casa.
La tokenización de marca crea una llave de repuesto:
- Que abre solo una puerta específica
- Puede desactivarse en cualquier momento
- No revela la llave original
Si alguien roba esta llave de repuesto, el daño es mucho menor.
¿Quién participa en el proceso?
Una tokenización de marca involucra a:
- Merchant / Plataforma
- Gateway o PSP
- Adquirente
- Marca (Visa, Mastercard, etc.)
- Token Service Provider (TSP)
Normalmente, la propia marca opera el TSP.
Ejemplos:
- Visa Token Service (VTS)
- Mastercard Digital Enablement Service (MDES)
Cómo funciona entre bastidores
Ahora vamos a lo que interesa.
1. Provisionamiento del token
Flujo simplificado:
- El cliente informa la tarjeta.
- El gateway envía el PAN a la marca a través del TSP.
- La marca valida con el emisor.
- La marca genera un token (DPAN).
- El token vuelve al ecosistema.
El punto importante:
El merchant nunca más necesita usar el PAN real.
En muchos modelos modernos, el PAN ni siquiera pasa por el merchant (ej: checkout tokenizado directamente en el gateway).
2. El papel del EMV
Seguro que has oído hablar de EMV (Europay, Mastercard, Visa).
Es el estándar que define cómo se comunican las tarjetas con chip.
Dentro del EMV, existen conceptos como:
- Criptogramas
- Dynamic CVV
- Autenticación dinámica
En la tokenización de marca, el token funciona junto con estos mecanismos para:
- Generar criptogramas únicos
- Garantizar que la transacción no pueda ser reutilizada
Esto reduce drásticamente el fraude por replay.
3. Durante la autorización
Cuando se envía la transacción:
- El merchant envía el token (DPAN)
- El adquirente lo envía a la marca
- La marca hace el detokenization mapping
- El emisor recibe el PAN real
El emisor no siempre sabe que ha habido tokenización, esto es transparente.
Diferencia: Token del Gateway vs Token de Marca
Este es un punto que tardé en entender y quiero intentar ayudarte a comprender.
| Tipo | Quién genera | Dónde funciona | Seguridad |
|---|---|---|---|
| Token del Gateway | PSP | Solo en ese PSP | Reduce el alcance, pero depende del PSP |
| Token Interno | Tu empresa | Solo en tu sistema | Aún puedes estar en el alcance PCI |
| Token de Marca | Visa/Mastercard | Funciona en toda la red | Reduce el riesgo estructural |
El token de marca es nativo de la red de pagos.
Beneficios reales
Además de la seguridad, existen ganancias estratégicas:
- Actualización automática de la tarjeta (Account Updater integrado)
- Mayor tasa de aprobación
- Tokens por dispositivo (menos fraude)
- Posibilidad de controlar el dominio de uso
Y aquí entra una buena práctica de arquitectura:
Siempre modela tu sistema para soportar múltiples tipos de token.
No asumas que tendrás solo PAN o solo network token.
Riesgos y decisiones arquitectónicas
Aquí va lo que poca gente cuenta.
1. Lock-in
Si dejas la tokenización 100% acoplada a tu PSP, puedes quedarte atrapado.
Buena práctica:
- Almacena metadata suficiente para la migración.
- Modela la entidad de instrumento de pago desacoplada del proveedor.
2. Múltiples tokens para la misma tarjeta
Una misma tarjeta puede tener:
- Un token por dispositivo
- Un token por merchant
- Un token por wallet
No trates el token como un identificador global del cliente.
3. La seguridad sigue siendo tu responsabilidad
Incluso usando token:
- TLS obligatorio de punta a punta
- Segregación de ambientes
- Logs sin datos sensibles
- Criptografía en reposo
El token no elimina la ingeniería segura.
Flujo lógico ideal en una arquitectura moderna
Yo suelo pensar así:
- El cliente envía la tarjeta
- El backend llama al servicio de tokenización
- El servicio devuelve:
- token
- last4
- brand
- expiration
- token_reference_id
- Tú almacenas solo:
- token
- metadata
- referencia de vault
¿Y el PAN? Nunca toca tu base de datos.
¿Dónde se usa esto en la práctica?
- Apple Pay
- Google Pay
- Click-to-Pay
- Credenciales guardadas para recurrencia
- Pagos in-app
Todos usan tokenización de marca por debajo.
Pero no podemos hablar de tokenización sin hablar de dos componentes súper importantes.
¿Y el Cryptogram? ¿Y el ECI?
Si has llegado hasta aquí pensando que la tokenización termina en el DPAN, aún falta una pieza importante.
Cuando hablamos de tokenización de marca, principalmente en wallets como Mercado Pago, Apple Pay y Google Pay, dos campos pasan a ser críticos:
- Cryptogram
- ECI
Cryptogram (o EMV Cryptogram)
El cryptogram es un valor criptográfico dinámico generado en cada transacción.
Nace dentro del contexto EMV (Europay, Mastercard, Visa), el mismo estándar utilizado por las tarjetas con chip, y funciona como una prueba criptográfica de que:
- El token es válido
- La transacción es legítima
- La credencial no ha sido copiada
¿Intentamos simplificarlo de nuevo?
Si el token es la llave de repuesto de la casa, el cryptogram es como una firma digital que prueba que la llave fue usada en ese exacto momento, y no es una copia.
Técnicamente:
- Se genera con claves simétricas almacenadas de forma segura
- Es validado por la marca
- Evita el replay attack
Sin un cryptogram válido, la transacción puede ser denegada o sufrir una degradación de responsabilidad.
ECI (Electronic Commerce Indicator)
El ECI indica el nivel de seguridad de la transacción.
Señaliza a la marca y al emisor:
- Si hubo autenticación fuerte
- Si la transacción proviene de un wallet
- Si es e-commerce tradicional
- Si existe liability shift
En resumen:
El ECI ayuda a definir quién asume el riesgo del fraude.
Un ECI incorrecto puede significar:
- Pérdida de liability shift
- Más chargebacks
- Mayor tasa de fraude percibida
Y aquí está el punto crítico:
Token sin cryptogram y ECI correcto es solo la mitad de la solución.
¿Por qué no he profundizado tanto en esto aquí?
Porque el cryptogram y el ECI merecen un artículo propio.
Impactan:
- Tasa de aprobación
- Riesgo
- Chargeback
- Configuración en el adquirente
- Campos obligatorios en la integración
Y es exactamente aquí donde muchos equipos se equivocan, no en la tokenización en sí, sino en la forma en que envían los datos de autenticación.
En el próximo artículo puedo desgranar:
- Diferencia entre ARQC y AAV
- Cómo se valida el cryptogram
- Cómo impacta el ECI en el liability shift
- Errores comunes de integración
Lo que debes llevarte de esto
Si eres desarrollador junior o pleno, entiende esto:
- La tokenización no es solo "enmascarar el número".
- El token de marca es infraestructura de red, no una feature del gateway.
- Una arquitectura mal pensada aquí genera dolor en la migración futura.
- La seguridad no es opcional, es estructural.
Al final del día, la tokenización de marca se trata de:
Reducir el riesgo, aumentar la aprobación y mantener la flexibilidad arquitectónica.
Y si trabajas con medios de pago, tarde o temprano tendrás que entender esto a fondo, no solo para integrar, sino para diseñar bien desde el principio.