Autenticación 3DS 2.0

¿Qué es la autenticación 3DS?

3D Secure (3DS) es un protocolo de autenticación diseñado para mejorar la seguridad de las transacciones online mediante la verificación de la identidad de los titulares de las tarjetas antes de que se procese un pago. Reduce el fraude y proporciona protección de responsabilidad a los comercios y emisores.

Al implementar la autenticación 3DS, puede añadir una capa adicional de seguridad a sus transacciones y reducir el riesgo de fraude al procesar pagos.

Comprendiendo el protocolo 3DS 2.x

El protocolo 3DS 2.x utiliza una autenticación basada en riesgos para determinar el método de verificación adecuado. El flujo de autenticación se determina dinámicamente en función de muchos factores, entre los que se incluyen:

Marca de la tarjeta y banco emisor
Infraestructura y capacidades de autenticación del emisor
Evaluación de riesgos realizada por el emisor de la tarjeta
Características de la transacción (importe, ubicación, dispositivo)
Historial de autenticación del cliente

Debe implementar su integración para gestionar cualquiera de los posibles escenarios que la API pueda devolver en función de estos factores externos.

Disponibilidad regional

Para obtener información detallada sobre la disponibilidad de la autenticación 3DS 2.0 por país y las marcas de tarjetas compatibles, consulte Core Cards - 3DS Authentication 2.0.

Para todas las transacciones dentro del Espacio Económico Europeo (EEE), la autenticación 3DS es obligatoria en cumplimiento de la Directiva Revisada de Servicios de Pago (PSD2) y los requisitos de Autenticación Reforzada de Cliente (SCA). Todos los pagos con tarjeta procesados en Europa deben autenticarse utilizando 3DS, a menos que se aplique una exención de SCA válida y sea aceptada por el emisor de la tarjeta. Para obtener más información sobre las exenciones de SCA y cómo aplicarlas, consulte la documentación de referencia de Impuestos y Regulaciones.

Cómo funciona 3DS

El proceso de autenticación 3DS comienza iniciando un flujo de inscripción (enrollment) para comprobar si la tarjeta está inscrita en un programa 3DS. La respuesta de la API indicará qué escenario se aplica a esa transacción específica en función de los factores externos mencionados anteriormente.

Posibles escenarios de autenticación

Su implementación debe estar preparada para gestionar cualquiera de los siguientes escenarios, según lo determinado por el campo status devuelto desde el endpoint enrollments-initial:

Escenario 1: Autenticación directa (Attempt o Authenticated)

La autenticación es completada inmediatamente por el emisor de la tarjeta sin requerir pasos adicionales.

El status se devuelve como Authenticated o Attempt.
Los datos de autenticación están disponibles de inmediato.

Este escenario suele ocurrir cuando la evaluación de riesgos del emisor determina que la transacción es de bajo riesgo y no se necesita verificación adicional. Sin embargo, si el status es ATTEMPT, usted es responsable de determinar si la autenticación está completa o si es necesario un desafío (challenge).

Escenario 2: Desafío después de la inscripción inicial

El emisor de la tarjeta requiere la autenticación inmediata del cliente sin procesamiento adicional.

El status se devuelve como Pending Challenge.
El comercio tiene dos opciones para la redirección:
redirect_html_template: Renderizar una plantilla HTML proporcionada directamente en la aplicación.
acs_redirect_form: Realizar una petición POST manual utilizando la action_url, creq y threeDSSessionData proporcionados en la respuesta. Este método es recomendado para comercios que desean evitar JavaScript externo y utilizar pantallas de transición personalizadas.
Después de la autenticación, se debe llamar al endpoint validations.
El endpoint continue no se utiliza en este flujo.

Escenario 3: Inscripción pendiente (Pending Enrollment Continue)

Se requiere procesamiento adicional antes de determinar si la autenticación está completa o si se necesita un desafío.

El status se devuelve como Pending Enrollment Continue.
Se debe llamar al endpoint enrollments-continue.
La respuesta de continue indicará entonces:
Finalización sin fricción (Frictionless): El status cambia a Authenticated o Attempt.
Desafío requerido: El status cambia a Pending Challenge. En este caso, el comercio puede optar nuevamente por redirigir al cliente utilizando la plantilla HTML proporcionada o el objeto ACS Direct Form.

Conclusión clave

Su integración debe ser lo suficientemente flexible como para gestionar los tres escenarios. El flujo está determinado por factores que escapan a su control, como la marca de la tarjeta, el banco emisor y sus algoritmos de evaluación de riesgos. Compruebe siempre el campo status en las respuestas de la API para determinar qué ruta está siguiendo la transacción actual.

Autenticación 3DS externa

En algunos casos, puede utilizar una solución 3DS externa de terceros para gestionar la autenticación fuera de la API de GetNet. Al utilizar este enfoque, la autenticación es realizada por el proveedor externo, y usted debe proporcionar los datos de autenticación resultantes al crear el pago a través de GetNet.

Al utilizar la autenticación 3DS externa, el proceso funciona de la siguiente manera:

El cliente completa la autenticación a través de su proveedor 3DS externo.
Usted recibe los datos de respuesta de autenticación del proveedor externo.
Usted incluye estos datos de autenticación al crear el pago a través de la API de pagos de GetNet.

Campos de autenticación requeridos

Al utilizar la autenticación 3DS externa, debe capturar y proporcionar los siguientes campos de su proveedor externo:

Campo	Descripción
tdsver	La versión del protocolo 3DS utilizada en la autenticación (por ejemplo, “1.0.2” o “2.2.0”)
xid	Un identificador de transacción único generado en el flujo 3DS, que vincula la autenticación con el pago
ucaf	Universal Cardholder Authentication Field - un valor criptográfico que demuestra que se completó la autenticación (utilizado en versiones anteriores de 3DS)
eci	Electronic Commerce Indicator - un código que indica el resultado y el nivel de la autenticación
tdsdsxid	Un identificador de transacción generado por el protocolo 3DS 2.x (equivalente a `ds_trans_id`)

Consideraciones importantes

Asegúrese de la integridad y autenticidad de los datos de autenticación recibidos del proveedor externo antes de enviarlos a GetNet.
Las transacciones pueden ser rechazadas por el emisor si los campos de autenticación faltan o no son válidos.
El proveedor externo debe ser compatible con las marcas de tarjetas y los países en los que opera.

Próximos pasos

Ahora que comprende cómo funciona la autenticación 3DS y los diferentes escenarios que su integración debe gestionar, puede:

Implementar la autenticación 3DS: Siga la guía Crear un pago con autenticación 3DS para obtener instrucciones paso a paso, ejemplos de código y mejores prácticas.
Revisar las referencias de la API: Consulte la documentación detallada de la API para conocer los parámetros de petición, los campos de respuesta y las especificaciones del endpoint: