Back to guides SEGURIDAD

Pasarela de Pago 3D Secure: Cómo 3DS2 Protege a los Comerciantes del Fraude

3D Secure es un protocolo de autenticación desarrollado por los circuitos de tarjetas que añade una capa de verificación de identidad a las transacciones con tarjeta en línea. Cuando un cliente paga a través de una pasarela habilitada para 3D Secure, su banco emisor verifica la transacción antes de autorizarla, ya sea mediante una verificación de fondo sin fricción o pidiendo al cliente que se autentique a través de su aplicación bancaria. Para los comerciantes, 3D Secure proporciona dos beneficios críticos: reduce significativamente las pérdidas por fraude en transacciones en línea, y traslada la responsabilidad de contracargos por disputas de fraude del comerciante al banco emisor. Esta guía explica cómo funciona 3D Secure, en qué se diferencia la versión 2 de la versión 1, y cómo implementar 3DS2 a través de RoxPay.

Qué Es 3D Secure y Cómo Funciona

3D Secure (3DS) es un protocolo de autenticación basado en XML para transacciones sin tarjeta presente. Los tres dominios del nombre hacen referencia al dominio del comerciante, el dominio del adquirente y el dominio de interoperabilidad (la red del circuito de tarjetas y el banco emisor). Juntos, estas tres partes participan en verificar que la persona que inicia la transacción es el titular autorizado de la tarjeta.

Flujo de la transacción con 3DS:
El cliente introduce los datos de la tarjeta en el checkout y envía el pago. La pasarela del comerciante envía la transacción con una solicitud de autenticación 3DS. El circuito de tarjetas enruta la solicitud al Servidor de Control de Acceso del emisor de la tarjeta. El emisor realiza una evaluación de riesgo de la transacción. Si la evaluación de riesgo indica bajo riesgo (flujo sin fricción), la transacción se autentica sin interacción del cliente. Si el riesgo está por encima del umbral sin fricción, se pide al cliente que se autentique, típicamente aprobando una notificación push en su aplicación bancaria, introduciendo una contraseña de un solo uso, o proporcionando confirmación biométrica. El resultado de la autenticación (autenticada, intentada o fallida) se devuelve a la pasarela del comerciante, que lo incluye en la solicitud de autorización al adquirente.

El traslado de responsabilidad: Cuando una transacción es autenticada con éxito mediante 3DS, y el titular de la tarjeta la disputa posteriormente como fraudulenta, la responsabilidad del contracargo se traslada del comerciante al banco emisor. El banco emisor aprobó la transacción autenticada; no puede luego reclamar con éxito que fue no autorizada. Este traslado de responsabilidad es el principal beneficio comercial de 3DS para los comerciantes.

Para los comerciantes que operan una pasarela de pago de alto riesgo, implementar 3DS2 es particularmente importante porque las categorías de alto riesgo tienden a tener tasas elevadas de fraude y fraude amistoso, haciendo que la protección de responsabilidad sea comercialmente significativa.

3DS1 vs 3DS2: Qué Cambió y Por Qué Importa

La especificación original de 3D Secure (3DS1) se introdujo a principios de los años 2000. Si bien proporcionaba un mecanismo de traslado de responsabilidad, tenía graves problemas de usabilidad y conversión que los comerciantes experimentaban como abandono del carrito en el paso de autenticación. 3DS2 (EMV 3DS) fue desarrollado para abordar estos problemas.

Problemas de 3DS1:
3DS1 requería una redirección a la página de autenticación del emisor, que a menudo estaba mal diseñada y confundía a los clientes. El modelo de contraseña estática utilizado por muchos emisores (Verified by Visa, MasterCard SecureCode) era fácil de olvidar y creaba fricción en cada transacción. En dispositivos móviles, el flujo basado en redirección y ventanas emergentes era especialmente problemático. Muchos comerciantes desactivaron 3DS1 específicamente porque el paso de autenticación estaba causando más abandono de transacciones que las pérdidas por fraude que intentaban prevenir.

Mejoras de 3DS2:
3DS2 introduce un modelo enriquecido de compartición de datos. La pasarela del comerciante envía hasta 150 puntos de datos con la solicitud de autenticación, incluyendo huella digital del dispositivo, características del navegador, historial de pedidos y señales de comportamiento. El emisor usa estos datos para tomar una decisión de riesgo. Para las transacciones de bajo riesgo, el emisor puede otorgar una autenticación sin fricción, lo que significa que nunca se pide al cliente que haga nada y la transacción procede de forma transparente.

Métodos de autenticación en 3DS2: Cuando se requiere autenticación, 3DS2 admite métodos modernos: notificaciones push a una aplicación bancaria con confirmación biométrica, contraseñas de un solo uso por SMS y autenticación en la app sin redirección. Estos son significativamente menos disruptivos que la redirección pop-up de 3DS1.

PSD2 y Autenticación Fuerte del Cliente: La Directiva Revisada de Servicios de Pago de la UE (PSD2) exige la Autenticación Fuerte del Cliente (SCA) para la mayoría de las transacciones europeas sin tarjeta presente. 3DS2 es el mecanismo principal para el cumplimiento de SCA. Los emisores deben aplicar SCA a las transacciones que no califican para una exención. Los comerciantes que no admiten 3DS2 descubren que sus transacciones son rechazadas de forma suave por los emisores que requieren SCA pero no pueden completarla porque la pasarela no pasa datos de autenticación 3DS2.

Cómo 3D Secure Reduce la Responsabilidad de Contracargos para los Comerciantes

El traslado de responsabilidad proporcionado por la autenticación 3D Secure es el mecanismo por el cual los comerciantes reducen las pérdidas por contracargos en disputas de fraude.

Cómo funciona el traslado de responsabilidad en la práctica: Un cliente completa una compra y se autentica a través de 3DS2 (por ejemplo, aprobando una notificación push en su aplicación bancaria). La transacción se procesa y se entregan los bienes. Un mes después, el cliente contacta a su banco emisor afirmando que la transacción no fue autorizada. El banco inicia un contracargo bajo un código de razón de fraude (Visa 10.4, Mastercard 4853).

Cuando la pasarela del comerciante presenta el requerimiento, incluye el registro de autenticación 3DS2: el ID de Transacción de Autenticación (ATID), el estado de autenticación (autenticada) y el valor ECI que indica autenticación completa. Este registro demuestra que el propio banco emisor del titular de la tarjeta autenticó la transacción. En la práctica, esto resulta en la reversión del contracargo en la gran mayoría de los casos.

Transacciones que no se benefician del traslado de responsabilidad: No todos los resultados de 3DS2 proporcionan traslado de responsabilidad. Una transacción que pasa por el proceso de autenticación pero resulta en un estado de autenticación "intentada" (la tarjeta no admite autenticación completa) proporciona protección limitada en comparación con un resultado completamente autenticado. El traslado de responsabilidad se aplica con mayor fuerza a las transacciones con un resultado de autenticación exitoso y un valor ECI de 05 (Visa) o 02 (Mastercard).

Exenciones y responsabilidad: Ciertas exenciones de 3DS2 (transacciones de bajo valor por debajo de 30 euros, listados de beneficiarios de confianza, transacciones recurrentes) permiten que las transacciones procedan sin SCA. La posición de responsabilidad para las transacciones basadas en exenciones varía según el tipo de exención.

Cuándo Se Requiere 3D Secure y Cuándo Es Opcional

Bajo el mandato de Autenticación Fuerte del Cliente de PSD2, 3D Secure es obligatorio para la mayoría de las transacciones europeas sin tarjeta presente, pero una serie de exenciones y escenarios fuera de alcance definen cuándo no aplica SCA.

Cuándo se requiere 3DS (aplica SCA):
Todos los pagos estándar sin tarjeta presente iniciados por el cliente (transacciones iniciadas por el cliente, o CIT) por importes por encima del umbral de bajo valor están sujetos a SCA. La posición predeterminada es que se requiere SCA; las exenciones son las excepciones.

Exenciones que permiten transacciones sin 3DS:
Transacciones de bajo valor: Las transacciones por debajo de 30 euros pueden calificar para una exención de bajo valor. Sin embargo, los emisores rastrean los importes acumulados y los recuentos de transacciones; una vez que se han aplicado cinco exenciones de bajo valor consecutivas o el importe acumulado supera los 100 euros, se requiere SCA para la siguiente transacción.
Análisis de riesgo de transacción (TRA): Los emisores y adquirentes pueden aplicar exenciones de TRA a transacciones que evalúan como de bajo riesgo según los índices de referencia de tasas de fraude. Para aplicar una exención TRA a nivel del adquirente, el adquirente debe cumplir con umbrales específicos de tasa de fraude definidos por PSD2.
Transacciones recurrentes: El pago inicial en una serie recurrente requiere SCA. Las transacciones posteriores iniciadas por el comerciante (MIT) en el mismo mandato recurrente pueden proceder sin SCA, siempre que la transacción inicial se haya autenticado y las transacciones posteriores sigan el marco de credenciales almacenadas.
Beneficiario de confianza: Los titulares de tarjetas pueden añadir comerciantes a una lista blanca con su emisor, aplicando una exención de beneficiario de confianza a las transacciones futuras con ese comerciante.

Fuera del alcance de SCA: Las transacciones iniciadas por el comerciante sin interacción del cliente (MIT), las transacciones donde una parte está fuera del EEE (transacciones one-leg out) y las transacciones con tarjetas corporativas están fuera del alcance de PSD2 SCA en circunstancias específicas.

Implementar 3DS2 con RoxPay

La pasarela de pago de RoxPay admite 3DS2 de forma nativa. La implementación se gestiona dentro de la arquitectura de integración existente, sin necesidad de un proveedor 3DS separado ni un contrato adicional.

Enfoque de IU drop-in: Si usas la IU drop-in de RoxPay (entrada de tarjeta basada en JavaScript), 3DS2 se gestiona automáticamente. Cuando el emisor requiere autenticación, la librería gestiona la redirección al entorno de autenticación del emisor, maneja la respuesta y continúa el flujo de pago sin código adicional del lado del comerciante. Este es el camino más sencillo hacia el cumplimiento de 3DS2.

Enfoque de integración API: Para los comerciantes que usan una integración directa con API, los datos de autenticación 3DS2 se pasan a través de los parámetros de la intención de pago. La API devuelve el resultado de autenticación y la acción requerida para que el frontend del comerciante la maneje, siguiendo el flujo de desafío estándar de 3DS2. La documentación completa está disponible en app.roxpay.eu/api/v4/docs.

Optimización de la tasa sin fricción: RoxPay pasa el máximo de datos disponibles en la solicitud de autenticación 3DS2 para respaldar altas tasas sin fricción. La autenticación sin fricción significa que nunca se pide al cliente que confirme nada; el emisor aprueba la transacción en segundo plano. Cuanto mayor sea la tasa sin fricción, mejor será el impacto de conversión de 3DS2.

Pruebas en sandbox: El sandbox de RoxPay proporciona escenarios de prueba para cada resultado de 3DS2: autenticación sin fricción, autenticación con desafío, fallo de autenticación y tarjeta no inscrita. Prueba todos los escenarios antes de salir en vivo para asegurarte de que tu checkout maneja cada resultado correctamente.

Para iniciar tu solicitud en RoxPay y comenzar a probar 3DS2 en el sandbox, el registro tarda menos de diez minutos y las credenciales del sandbox se emiten inmediatamente. RoxPay está certificado PCI DSS Nivel 1 (QS83A47X629) y certificado ISO 27001.

Frequently Asked Questions

¿Reduce 3D Secure las tasas de conversión?

3DS2 con una implementación adecuada tiene un impacto mínimo en la conversión en comparación con 3DS1. El flujo de autenticación sin fricción, donde el emisor autentica la transacción en segundo plano sin acción del cliente, representa el 80-90% de las transacciones autenticadas para los comerciantes bien configurados. Las transacciones restantes que requieren un desafío (típicamente notificación push de la app bancaria u OTP) sí ven cierta caída, pero esto es significativamente menor que la caída experimentada con el modelo de redirección y contraseña estática de 3DS1.

¿Qué es el valor ECI en la autenticación 3DS?

El valor del Indicador de Comercio Electrónico (ECI) en una respuesta de autenticación 3DS indica el nivel de autenticación logrado. ECI 05 (Visa) o 02 (Mastercard) significa que se completó la autenticación completa y proporciona traslado de responsabilidad completo. ECI 06 o 01 significa que la tarjeta intentó la autenticación pero el emisor no la admitía, proporcionando traslado de responsabilidad limitado. ECI 07 significa que no se realizó autenticación; no aplica traslado de responsabilidad.

¿Qué pasa si un cliente falla la autenticación 3D Secure?

Si el cliente no completa el desafío 3DS2 (cancela el push de la app bancaria, introduce el OTP incorrecto o deja que la sesión expire), la autenticación falla y el pago no se procesa. Tu pasarela debe mostrar un mensaje de error claro y permitir al cliente volver a intentarlo o usar un método de pago diferente. La autenticación fallida no es un contracargo; la transacción simplemente no se autoriza.

Más información

Optimize your payments today

RoxPay admite 3DS2 nativo con optimización de tasa sin fricción, traslado de responsabilidad para transacciones autenticadas y pruebas completas en sandbox. Certificado PCI DSS Nivel 1, precios IC++ desde 0,45%.

Get started for free → Talk to an expert

✓ No monthly fixed costs · ✓ Activation in 24 hours · ✓ Dedicated technical support