3D Secure 2 y SCA bajo PSD2: exenciones, traslado de responsabilidad y conversión

¿Qué es 3D Secure 2 y cómo se relaciona con la SCA?

La autenticación reforzada de cliente es una obligación legal: según PSD2, un pago iniciado online por el ordenante debe confirmarse con dos factores independientes, y el código de autenticación debe estar vinculado dinámicamente al importe y al beneficiario. 3D Secure 2 es el estándar técnico, mantenido por EMVCo, con el que las redes de tarjetas cumplen ese requisito. Los compradores lo conocen con marcas como Visa Secure, Mastercard Identity Check, American Express SafeKey y Cartes Bancaires FAST'R.

La primera versión de 3D Secure enviaba a todos los compradores a una página de contraseña del banco. La versión 2 intercambia más de 100 datos sobre el dispositivo, el pedido y la cuenta, de modo que el emisor puede aprobar la mayoría de los pagos sin mostrar nada y reservar un desafío, normalmente una confirmación en la app del banco, para los pagos de riesgo. También admite flujos nativos en aplicaciones, algo que el protocolo antiguo no permitía.

¿Cuándo es obligatoria la SCA y qué pagos quedan fuera de alcance?

La SCA se aplica a los pagos electrónicos iniciados por el ordenante cuando tanto el emisor como el adquirente están en el EEE; el Reino Unido aplica las mismas reglas mediante su propia versión de las normas técnicas. Para una tienda online de la UE esto abarca casi todos los primeros pagos con tarjeta, todas las compras puntuales y cualquier cambio en un mandato de tarjeta almacenada.

Varios tipos de operación quedan totalmente fuera de la obligación, lo que es distinto de una exención: no se exige legalmente autenticación, pero el emisor aún puede rechazar el pago. Marque correctamente estas operaciones en el mensaje de autorización, porque una marca errónea es una causa frecuente del rechazo blando «SCA required».

• Transacciones iniciadas por el comerciante (MIT): suscripciones de importe variable, cargos diferidos y no presentaciones, siempre que el mandato se haya establecido con SCA
• Pagos por correo y por teléfono (MOTO), en los que el comprador no introduce los datos de la tarjeta online
• Pagos «one-leg-out», en los que el emisor o el adquirente están fuera del EEE; la SCA se aplica en la medida de lo posible
• Pagos iniciados por el beneficiario a partir de un mandato de adeudo directo, como el adeudo directo SEPA

¿Qué exenciones de la SCA pueden usar los comercios?

Las exenciones son opcionales: pueden aplicarlas el adquirente o el emisor, y el emisor siempre tiene la última palabra. Si rechaza una exención, devuelve un rechazo blando (código de respuesta 1A en Visa, 65 en Mastercard) y el pago debe reintentarse con autenticación. La tabla resume las exenciones del Reglamento Delegado (UE) 2018/389 que importan para la venta online.

El análisis de riesgo de la operación (TRA) es la más valiosa para los comercios con poco fraude, porque cubre cestas de hasta 500 €. La tasa que cuenta es la del PSP que aplica la exención, calculada a 90 días, de modo que un adquirente con una cartera limpia puede solicitarla en su nombre.

¿Cómo funcionan el flujo sin fricción y el flujo con desafío?

El servidor 3DS del comercio, normalmente gestionado por el PSP, envía una solicitud de autenticación a través del servidor de directorio de la red de tarjetas al servidor de control de acceso del emisor. El emisor puntúa la solicitud con los datos del dispositivo, el pedido y la cuenta y responde en aproximadamente un segundo.

Si el riesgo es bajo, el pago se autentica sin fricción y el comprador no ve nada. En caso contrario, el emisor abre un desafío: una confirmación push en la app del banco, una comprobación biométrica o un código de un solo uso. En ambos casos, el resultado y un criptograma pasan a la autorización, de modo que el emisor puede ver que se realizó la SCA.

1. Recopilar datos El checkout reúne los datos del navegador o de la app, los datos de facturación y envío y el historial de la cuenta del comprador.
2. Autenticar El servidor 3DS envía la solicitud; el emisor responde sin fricción, con desafío o rechazada.
3. Autorizar El resultado de la autenticación y el criptograma viajan con la solicitud de autorización al emisor.

¿Qué es el traslado de responsabilidad de 3D Secure?

Cuando un pago se autentica correctamente con 3D Secure, la responsabilidad por los contracargos de fraude, como el código de motivo 10.4 de Visa o el 4837 de Mastercard, pasa del comercio al emisor. En la mayoría de los casos esto también se cumple cuando el comercio intentó autenticar pero el emisor no estaba disponible.

El traslado no cubre las disputas ajenas al fraude, como mercancía no recibida o distinta de lo descrito, y se pierde cuando el adquirente aplica una exención: se gana conversión, pero se conserva el riesgo de fraude. Por eso los comercios aplican la TRA de forma selectiva, por ejemplo a clientes recurrentes y cestas de bajo riesgo, y envían el resto a autenticación.

¿Cómo afecta 3D Secure 2 a la conversión del checkout?

Cada desafío añade un paso en el que el comprador puede abandonar o fallar, sobre todo cuando la app del banco está en otro dispositivo. La ABE y el BCE informaron en diciembre de 2025 de que los pagos con tarjeta autenticados con SCA siguen estando menos expuestos al fraude, de modo que el objetivo no es evitar la SCA, sino desafiar solo donde compensa.

La conversión mejora con datos completos en la solicitud de autenticación, marcas de transacción correctas, un SDK nativo en lugar de una webview, solicitudes de exención a través de un adquirente con baja tasa de fraude y un reintento inmediato con autenticación tras un rechazo blando. Mida por separado la tasa sin fricción, la tasa de éxito de los desafíos y la tasa de autorización por país del emisor; una cifra de aprobación agregada oculta dónde abandonan los compradores.

¿Cómo se añade 3D Secure 2 con OrsunPay?

OrsunPay es un servicio técnico que funciona sobre las cuentas de PSP y de adquirente del propio comercio. Con su checkout alojado, los datos de la tarjeta y el flujo de 3D Secure se ejecutan en la interfaz del propio PSP, por lo que la autenticación, las solicitudes de exención y las normas de responsabilidad son las de su contrato con ese PSP. El enrutamiento basado en riesgo y una integración con RiskCogs están en la hoja de ruta y no están disponibles hoy.