Tokenización de tarjetas y flujos safe PAN

1) Por qué la tokenización y qué es PAN-seguro

• minimizar el PCI DSS scop (y el coste de control),
• reducir el riesgo de fugas,
• mejorar la autorización (búsqueda automática, COF, one-click),
• simplificar el enrutamiento multi-PSP y los reinicios.

Un flujo PAN-safe es un escenario de usuario y servidor en el que el PAN sólo aparece dentro de un perímetro de confianza aislado (valt/TSP/PSP iframe) y nunca pasa a través de su backend/logs/bus de eventos en abierto.

2) Tipos de tokens y ciclo de vida

2. 1 Vault-tokens (privado)

Son generados por su token valt o proveedor de seguridad de terceros.
Están enlazados a PAN, pero la correspondencia reversible sólo se almacena en valt (HSM).
Se utilizan para enrutar a cualquier PSP/acavyer (flexibilidad).
Además: independencia de los esquemas; Menos: requiere su propio compliant-valt.

2. 2 tokens de red (diagramas; Visa/Mastercard/AmEx TSP)

Son lanzadas por redes a través de TSP; a menudo se acompaña de device-/merchant-binding y criptograma.
Mejora la autorización: por encima de la tasa de approval, menos positivos de frod-fols.
Admite la actualización automática al volver a lanzar la tarjeta.
Menos: atadura para soporte PSP/procesador y cobertura de mercados.

2. 3 Desechables (single-use) y reutilizables (COF)

Solo uso: para una sola descarga/iniciación SCA.
COF (Card-on-File): para suscripciones, retiros, pagos repetidos.

2. 4 Ciclo de vida

1. Inicialización: el frente no recibe campos de pago de su dominio (campos hosted/iframe TSP/PSP).
2. Tokenización: PAN → token (vault o network), emisión de criptogramas (si es necesario).
3. Almacenamiento: token y metadatos (datos BIN, esquema, fecha límite, dominio binding).
4. Uso: autorización/capchur/retrae por token.
5. Rotación/actualización: auto-update (red), tarjeta updater (vault/PSP).
6. Revocación/eliminación: a petición del usuario (GDPR/DSR) o por política de retención.

3) Patrones arquitectónicos PAN-safe

3. 1 Capa de cliente (web/mobile)

Hosted fields/iFrame SDK de PSP/TSP: PAN se introduce fuera de su DOM.
Su frontend sólo recibe token + atributos no críticos (los últimos 4 dígitos, BIN-meta).
SCA/3DS se inicia a través del proveedor; sus servidores reciben el resultado/veredicto.

3. 2 Servicio «Payments Orchestrator»

No ve PAN; opera con tokens.
Implementa: enrutamiento (PSP primario/secundario), llaves idempotency, retries/backoff, enrutamiento inteligente (por BIN/regiones/conversiones).
Mantiene la configuración de reglas y muestras de salud PSP (SLI/SLO).
Sabe detokenize-proxy (sólo como un «servicio-lanzadera» dentro de un perímetro de confianza al valt).

3. 3 Token-valt (si es suyo)

HSM-backend, cifrado compatible con FIPS.
Aislamiento de red/segmentación, AAA (MFA/privilegio least), registros de auditoría, rotación clave.
API: tokenize (), detokenize (), rotate (), purge () con ACL/Scopes finos.
Soporte de cifrado de preservación de formato (FPE): opcional si necesita almacenamiento visualmente «enmascarable».

3. 4 Bus de evento y DWH

En eventos, sólo tokens y metadatos seguros.
Enlace de autorización ↔ capchura/refundición a través de payment_id (no PAN).
En los repositorios de BI, PAN y CVV están prohibidos.

4) Flujos (gráficos de texto)

4. 1 COF primario (guardar tarjeta)

1. User → Hosted Fields (PSP/TSP iframe) introduce PAN.
2. PSP/TSP → devuelve token (+ dispositivo binding/cryptograma).
3. Front → Backend (Orchestrator): `{token, order_id, context}`.
4. Orchestrator → PSP: 'auth' por token (3DS challenge es posible).
5. PSP → Orchestrator: `auth_result`.
6. Orchestrator → Wallet Service: guardamos 'token' y meta.

PAN no aparece en ninguna parte de sus servicios.

4. 2 Nuevo cargo/suscripción

1. Scheduler/Business → Orchestrator: `charge(token, amount)`.
2. Orchestrator → PSP: `capture/auth`.
3. PSP → Orchestrator: resultado + arn/rrn.
4. Orchestrator → Ledger/Reconciliation.

4. 3 Failover и smart-routing

Regla: 'IF PSP_A. degraded OR BIN in {X} THEN PSP_B ELSE PSP_A`.
Para los tokens de red, asegúrese de que ambos PSP admiten su aceptación; de lo contrario: mantenga la referencia binaria (network + vault).

5) 3DS y SCA en el circuito PAN-seguro

3DS2 se ejecuta desde hosted-SDK; sus servidores aceptan alias de estado (frictionless, challenge, failure).
Asocie el veredicto 3DS con el payment_id; almacene los artefactos transaccionales (ARes, CRes refs) sin PAN.
Para recaranting (MIT/recurring/unscheduled COF): marque correctamente las banderas de transacción (tipo MIT, referencia CIT original).

6) Seguridad, cumplimiento y política de datos

PCI DSS scop: frente sin PAN, beckend sin PAN ⇒ evaluación simplificada (SAQ-A/variaciones). Si hay su propio valt/desintoxicación - scope arriba (SAQ-D).
HSM/rotación clave: rotaciones periódicas de claves maestras, control dual, split knowledge.
GDPR/DSR: eliminación de token y metadatos relacionados a petición del usuario (mientras que PAN permanece desconocido).
Logs/tracks: enmascaramientos estrictos, detectores de fugas (DLP), saneamiento en la serialización de errores.
Segmentación: valt en el segmento dedicado; Acceso: sólo por mTLS y tokens de vida corta (STS).

7) Integración con PSP/acavayers

7. 1 Conjunto mínimo de capacidades PSP para PAN-safe

Hosted fields/SDK con tokenización.
Aceptación de tokens de red (si es posible) y/o exportación de tokens vault.
Card updater, marcas COF, banderas MIT.
3DS server + orquestación SCA.
Webhooks con entrega idempotent y firma.

7. 2 arquitectura Multi-PSP

Abstracción del «conector» en Orchestrator (unificación de campos).
Tabla de «escalas/prioridades» + pings de salud.
Tabla de políticas BIN (esquema, región, producto, puntuación de riesgo).
PSP de respaldo para rutas críticas (fallback SLA).

8) Renovación de tarjetas y durabilidad de tokens

tokens de red: actualizaciones automáticas durante el relanzamiento (mejor para LTV).
Vault tokens: use la tarjeta updater (a través de PSP/3rd-party).
Seguimiento de vencimientos, notificaciones al usuario, retraídas suaves (retroceso exponencial + jitter).
Vincular el COF a la cuenta-id, no al usuario por PII, para un simple re-lanzamiento.

9) Retraídas, errores e idempotencia

Idempotency-key = хеш(merchant_id, account_id, order_id, attempt_n).
Categorización de errores: hard (decline code constante) vs soft (timeout, network, risk pending).
Backoff: 1m → 10m → 1h → 24h con límite superior y cancelación en hard-decline.
Deduplicación de webhooks: almacena transiciones de event_id y estado (state machine).

10) Reconciliación y finanzas

Mantenga Ledger de pago sin PAN: 'payment _ id', 'psp _ txn _ id', 'arn/rrn',' token _ id ', estados.
La ingestión diaria de ficheros ref de PSP/Acavyer; compensación de sumas, comisiones, charjbacks.
Pipelines individuales para refunds/voids/chargebacks; negociación con facturación/contabilidad.
KPI por PSP/países/tabs BIN.

11) Métricas y objetivos (KPI)

Seguridad/cumplimiento

% de los servicios que nunca ven PAN (objetivo: 100%).
Nivel PCI scope (por debajo - mejor).

Negocios

Approval Rate (AR) por tipo de señal (network vs vault).
Tasa de retención COF, una fracción de los métodos actualizados automáticamente.
D + 0/D + 1 discrepancias de reconsificación (objetivo: → 0).

Tiempo de tokenización p95.
Participación de transacciones a través de PSP fallback.
Kol-en desintoxicaciones (objetivo: minimizar, sólo dentro del valt).

12) Anti-patrones frecuentes

Lógica PAN/CVV en excepciones.
Formularios de cliente sin campos hosted.
Enviar PAN a través de su bus API «temporalmente».
Mezcla de tokens de diferentes dominios sin una política explícita (risk).
No hay tarjeta de enrutamiento (todos los pagos «en un solo PSP»).
Almacenamiento de artefactos 3DS con PII redundantes.

13) Plan de implementación (por pasos)

1. Frontend: integrar hosted fields/SDK, eliminar sus propios formularios de pago.
2. Selección PSP/TSP: confirmamos el soporte para tokens de red, 3DS2, webhooks, tarjetas de actualización.
3. Orchestrator: capa de abstracción sobre PSP, reglas de enrutamiento, idempotency, retries.
4. Valt (opcional): seleccionamos managed-vault o construimos el nuestro (HSM, ACL, rotaciones).
5. Datos/eventos: prohibición de PAN en bus y DWH; implementar una puerta DLP en CI/CD.
6. Cumplimiento: actualizar el área PCI, procedimientos, registros de auditoría, pruebas de enmascaramiento.
7. Observabilidad: métricas AR/LSR/latencia por PSP, alertas de degradación, dashboards.
8. Economía: prueba de red A/B vs vault tokens por AR/frod/valor, optimización de flow.

14) Lista de verificación PAN-seguro

• Escribir PAN sólo en iframe/hosted fields.
• Beckend nunca acepta PAN/CVV.
• Los tokens se cifran en el almacenamiento, las claves en HSM, la rotación está activada.
• 3DS2 y SCA están correctamente etiquetados (CIT/MIT/COF).
• Multi-PSP enrutamiento y failover probado.
• Tarjeta de actualización habilitada (red/PSP).
• Registros/remolques/volcado - sin PAN (máscaras/desinfectantes).
• Reconciliation y chargeback-pipelines sin PAN.
• Se han implementado políticas de eliminación de tokens/GDPR.
• Las métricas y alertas cubren la calidad del token flow.

15) Glosario brevemente

PAN: número de tarjeta.
Token (vault/network): sustituto seguro del PAN.
TSP: Token Service Provider (servicio de token de red).
COF/MIT/CIT: almacenamiento de tarjetas/iniciativa de merchant/iniciativa del cliente.
HSM: módulo de seguridad de hardware.
SCA/3DS2: Fuerte autenticación/protocolo de autenticación por tarjeta.

16) Resumen

La tokenización es una técnica básica para reducir los riesgos PCI, el crecimiento de la tasa de approval y el enrutamiento flexible de pagos en iGaming. Combine los tokens de red (mediante conversiones y actualizaciones automáticas) con vault tokens (a través del control y la independencia), construya un flow PAN-safe con campos hosted, orquestador, administración de claves y observación transparente desde la autorización hasta la reconciliación. Esto dará seguridad, escala y monetización predecible.