Entender 3‑D Secure (3DS): autenticación, desafíos y fallos comunes de pago

Por qué importa

3‑D Secure (especialmente la versión moderna 3DS2) es el método técnico principal para la autenticación por el emisor en pagos online sin tarjeta física; las fallas suelen deberse a fallos de integración, interrupciones en el dispositivo/UX, políticas del emisor, manejo del gateway o normas regionales de SCA — y existen mitigaciones prácticas.

Qué es 3‑D Secure y versiones en uso

3‑D Secure es un protocolo que integra la autenticación del emisor (ACS) en el proceso de pago online para que el emisor pueda evaluar riesgo o desafiar una transacción antes de autorizarla. EMVCo mantiene la especificación; hoy se utilizan las versiones EMV® 3‑D Secure (3DS2).

EMVCo publica versiones v2.x; se recomienda usar v2.2 o posterior por mejoras funcionales. v2.3 introdujo soporte para WebAuthn/FIDO; confirme la versión vigente en la fecha de publicación.

• 3DS conecta la petición del comercio (AReq) con el ACS del emisor para evaluación de riesgo.
• Use EMVCo v2.x (recomendado >= v2.2) para aprovechar flujos sin fricción.

Cómo funciona un flujo típico de 3DS2

El comercio envía una AReq con datos de transacción y dispositivo al directorio de la scheme y al ACS del emisor. El emisor puede devolver una respuesta frictionless o iniciar un challenge (OTP, push de app, WebAuthn) para el titular.

Tras la ARes, el comercio continúa con la autorización a través del adquirente y la red. 3DS2 permite enviar datos más ricos y usar SDKs nativos para reducir desafíos innecesarios.

• AReq → directorio/ACS → frictionless o challenge → ARes → autorización.
• 3DS2 admite WebAuthn y métodos OOB/app‑push.

Causas comunes de fallos de autenticación

Las causas reales suelen ser: datos 3DS incompletos (errores de integración), problemas cliente (iframes bloqueados, cambio de app), políticas del emisor y falta de soporte 3DS2, inconvenientes o riesgos de OTP vía SMS, y errores de gateway o mapeo de resultados.

Para diagnosticar: revise AReq para campos obligatorios, pruebe SDK en contexto nativo, verifique códigos de rechazo del emisor y valide el mapeo de resultados de autenticación en su gateway/PSP.

• AReq incompleto → fallback/decline; asegure enviar campos obligatorios.
• Interrupciones en cliente → timeouts; preferir SDKs nativos.
• OTP por SMS es vulnerable; fomentar WebAuthn donde sea posible.
• Gateways pueden perder resultados de autenticación — comprobar en sandbox.

Mitigaciones prácticas y buenas prácticas

Use un SDK 3DS2 aprobado por EMVCo, envíe el contexto completo del dispositivo y la transacción en la AReq y pruebe escenarios en el sandbox del PSP. Esto aumenta la probabilidad de flujos frictionless.

Mejore la experiencia de usuario: explique al comprador qué esperar durante un challenge (no cambiar de app), ajuste timeouts con criterio y ofrezca métodos alternativos si la autenticación falla.

• Confirmar SDK en la lista aprobada de EMVCo.
• Enviar todos los campos device/transaction requeridos en AReq.
• Probar con tarjetas de test oficiales en sandbox.
• Implementar mensajes accionables y rutas de pago alternativas.

Qué comprobar

• Instalar y verificar un SDK 3DS2 aprobado.
• Enviar datos completos de dispositivo y transacción en AReq.
• Probar flujos en sandbox con tarjetas de prueba del PSP.
• Proveer instrucciones al usuario durante el challenge y métodos alternativos.