3-D Secure 2. 0 y SCA

1) Por qué el operador de iGaming 3DS2 y qué es SCA

3-D Secure 2. x (EMV 3DS): protocolo de autenticación del titular de la tarjeta en e-commerce.
SCA (Strong Customer Authentication) es un requisito regulatorio (PSD2/UK) que obliga a realizar una verificación de dos factores en una serie de escenarios.

• Liability shift: si se autentica correctamente, el riesgo de fraude pasa al emisor.
• Por encima de la conversión vs 3DS1: la recopilación de 100 + datos-elementos permite frictionless sin challenge.
• Escenarios nativos: SDK para confirmaciones de iOS/Android, in-app, decoupled y out-of-band.

2) Roles y componentes (EMV 3DS)

3DS Server (usted o PSP): genera consultas en el diagrama, suma los datos del dispositivo, controla las versiones 2. 1/2. 2/2. 3.
Servidor de directorio (DS): router de esquema (Visa/Mastercard/AmEx, etc.).
Access Control Server (ACS): servidor emisor; toma la decisión: frictionless o challenge.
SDK/Método: recolección de señales de dispositivo (fingerprinting), web-SDK/iframe y mobile-SDK.

3) Flujos UX típicos

3. 1 Frictionless (sin desafío)

1. Merchant/PSP → DS: AReq con datos 3DS (device, historial, señales de riesgo).
2. DS/ACS → ARes (frictionless): la autenticación se realiza sin la participación del usuario.
3. A continuación → la autorización (Auth).

Cuando se dispara: bajo riesgo, whitelist (Beneficencia confiable), HVL, datos cualitativos.

3. 2 Desafío (con desafío)

1. ARes requiere CReq/CRes (OTP, confirmación push en el banco, biometría).
2. Después del éxito → la autorización, liability shift se ha guardado.

3. 3 Decoupled / Out-of-Band

Confirmación en la aplicación del banco sin redirección. Útil en escenarios móviles.

3. 4 3RI (3DS Requestor Initiated)

Se utiliza para el MIT (transacciones iniciadas por merchant) - suscripciones, retraídas. No hay SCA en cada repetición, pero se requiere una referencia correcta a la CIT inicial.

4) SCA: donde es obligatorio y donde actúa

Obligatorio: la mayoría de las transacciones e-commerce en EEA/UK si el emisor y el ecuador están en la zona SCA.
Fuera de la zona/Out-of-scope: MOTO (correo/teléfono), algunos canales corporativos, rutas interzonales (se puede aplicar el TRA del emisor).

4. 1 Excepciones (Exemptions)

TRA (Transaction Risk Analysis): bajo riesgo de proveedor/banco (confirmado por métricas de frod).
LVP (Pagos de bajo valor): pequeñas cantidades, con umbrales y contadores de emisor.
Whitelist: el destinatario en la lista blanca del cliente en el emisor.
Secure Corporate/Merchant Initiated (MIT): cargos posteriores fuera de SCA si hay CIT inicial con SCA y enlaces correctos.

5) Etiquetado de transacciones y banderas para iGaming

CIT (Customer Initiated Transaction): el cargo principal, generalmente requiere SCA (o exemption).
MIT Recurring/Unscheduled COF: descargas posteriores; no requieren SCA cuando hay un ligamento con el CIT original (referencias/identificadores de larga duración).
Los indicadores correctos en las solicitudes PSP/diagrama son críticos para los mayúsculas de liability y para omitir SCA en repeticiones.

6) Datos que afectan a la solución ACS

• Device/Browser: user-agent, accept headers, screen, timezone, language.
• Cuenta de datos: edad de la cuenta, fecha de la última contraseña, número de entradas fallidas.
• Transaction data: JSF/categoría, suma/moneda, intentos anteriores, velocity.
• Envío/Facturación: coincidencia de direcciones, historial del destinatario.
• 3DS método completion indicator: ¿Ha tenido tiempo de trabajar 3DS Método (huella digital).
• Cuanto más rico es el contexto, mayor es la probabilidad de frictionless.

7) Flujos de integración con el orquestador de pagos

7. 1 Secuencia (web/móvil)

1. Iniciate 3DS (3DS Server ↔ DS/ACS) → obtener ARes.
2. Si el desafío → trabajar CReq/CRes a través de SDK/iframe.
3. Éxito → Auth (autorización) especificando el resultado 3DS (ECI, CAVV/cryptograma, dsTransID).
4. Webhook PSP → un orquestador → Ledger/DWH (sin PAN).

7. 2 Soft-decline y retraídas

La autorización sin SCA puede volver 'soft-decline (code)' → repetir el pago con SCA.
El orquestador sostiene la máquina de intento de estado: no SCA → soft-decline → 3DS2 → Auth.

7. 3 Multi-PSP

Compruebe la compatibilidad con las versiones 3DS (2. 1/2. 2/2. 3), app-SDK, decoupled.
Smart-routing: al degradar ACS en una parte de los emisores, utilice la ruta de backup (si las políticas/esquemas lo permiten).

8) Patrones UX que mejoran la conversión

Native/SDK en aplicaciones móviles: menos redirecciones, mayor finalización.
Pre-collect de datos (e-mail, dirección, señales de comportamiento) hasta 3DS.
Pantallas de espera transparentes y textos comprensibles (localización por idioma/región).
Taimautas con devolución de pago suave y repetición de desafío.
Whitelisting prompt: invita al cliente a añadir merchant a los de confianza del banco (donde esté disponible).

9) Errores y casos extremos

Timeout/Unavailable ACS → códigos y repeticiones correctos (o fallback por política).
Versión downgrade: si 2. 2/2. 3 no está disponible, retrocede a la versión compatible.
Método parcial: si 3DS Method no se ha completado, aún así envíe AReq - mejor datos parciales que cero.
Flows mixtos: 3DS + verificación de direcciones AVS al mismo tiempo - mappite correctamente los estados.
Chargeback después de 3DS: disputa con artefactos (ECI, CAVV, ARes/CRes refs).

10) Documentos y artefactos que se deben almacenar

Identificadores de transacción 3DS (dsTransID, threeDSServerTransID).
Resultados de autenticación (ECI, CAVV/AVV, estados ARes/CRes).
Registros SDK (sin PII/PAN), temporizadores y códigos de error.
Enlaces MIT a CIT inicial para suscripciones/repeticiones.
Políticas de procesamiento soft-decline y de excepción TRA.

11) Métricas y objetivos (KPI para iGaming)

Conversión

3DS completion rate (porcentaje de autenticación completada con éxito).
Frictionless vs challenge share (el objetivo es ↑ frictionless).
Abandonment rate en pantallas 3DS.

Riesgo

Fred Reat después de liability shift (debajo - mejor).
Fracción soft-decline y éxito de los retiros posteriores con 3DS.

Tiempo de 3DS p95 (iniciación → resultado).
Errores SDK/iframe, temporizadores ACS.

12) Lista de comprobación de inicio 3DS2 + SCA

• 3DS Server está conectado (versiones 2. 1/2. 2/2. 3), los vendajes de prueba se han trabajado.
• Los SDK/mobile-SDK web están integrados (scripts in-app + webview).
• Se incluye la colección de datos de-vice/browser (Método 3DS).
• Las marcas CIT/MIT/COF son correctas; se almacena una referencia a CIT inicial.
• Flujo soft-decline → repetición con SCA implementado en el orquestador.
• Exemptions (TRA/LVP/whitelist) están configurados y las causas/resultados son lógicos.
• Multi-PSP: las versiones 3DS y fallback-path están probadas.
• Дэшборды KPI: frictionless %, challenge success %, abandon, soft-decline.
• Las políticas de retención de artefactos 3DS y dispute-playbooks están listas.
• Las pruebas A/B de pistas de UX (localización, textos, temporizadores) están programadas.

13) Relación con PCI DSS y tokenización

3DS2 no reemplaza al PCI DSS: es acerca de la autenticación y el PCI es sobre la protección de datos.
Para PAN-safe: introducir la tarjeta en los campos alojados/iframe; el orquestador sólo ve tokens y artefactos 3DS (ECI/CAVV).
Para COF/MIT, utilice tokens de red o vault-tokens para reducir el flúor y aumentar la autorización.

14) Preguntas frecuentes breves

¿Es necesario hacer siempre 3DS? En la zona SCA, sí, a menos que haya una exención/exclusión correcta. El emisor puede requerir un desafío.
¿Si el banco se ha roto? Utilice las directivas Retray/Timeout y, si es posible, otra ruta.
¿3DS dará el crecimiento de la conversión? Un 3DS2 correctamente configurado con datos ricos aumenta la proporción de frictionless y disminuye el frod/charjbeki.
¿Qué es lo más crítico para el éxito? Datos contextuales enriquecidos, banderas CIT/MIT/COF correctas, UX rápido y procesamiento soft-decline competente.

15) Resumen

Para iGaming, 3DS2 + SCA no es un «dolor obligatorio», sino una herramienta de crecimiento: más frictionless, menos frod, transferencia de responsabilidad al emisor, monetización estable de suscripciones y cancelaciones repetidas. Coloque las banderas correctas (CIT/MIT/COF), mantenga las exemptions según las reglas, proporcione una entrada de pan segura y construya un orquestador con retratos inteligentes y observabilidad - entonces la autenticación se convertirá en un aliado, no en un freno a la conversión.