Tanto 3DS1 como 3DS2 están disponibles para la integración de extremo a extremo de las citas del Centro de acciones. Puedes implementar una de ellas (o ambas) para tu integración.
Tanto 3DS1 como 3DS2 cumplirán con el requisito de autenticación reforzada de clientes de PSD2, pero existen algunas diferencias clave:
- 3DS1: Puedes decidir activar 3DS1 para una transacción cuando detectas indicadores de que el cargo es fraudulento.
- La implementación de 3DS1 requiere cambios en tu servidor de reservas.
- 3DS2: 3DS2 solo se usará para transacciones en las que se aplique la directiva PSD2 (el banco adquirente y el banco del cliente se encuentran en el EEE).
- La implementación de 3DS2 requiere cambios en tu feed de comercios.
Cómo implementar 3DS2
Para implementar 3DS2, debes agregar campos adicionales a tu
feed de comercios en el mensaje TokenizationConfig. Si
todos los pagos se realizan a la misma cuenta, repetirás el valor en cada
entrada del comercio. Si los pagos se destinan a diferentes cuentas, los valores en
cada entrada del comercio deberán corresponder a la cuenta que adquiere los fondos
dentro de la transacción.
Cambios en el feed de comercios
merchant_of_record_name: Es el nombre del comerciante oficial. Este nombre visible para el usuario se mostrará en las verificaciones de 3DS2.payment_country_code: Es el país en el que se procesará la transacción, en formato ISO 3166-1 alfa-2.- Mensaje
CardNetworkParameters: Este mensaje se repite con los valores específicos para diferentes redes (solo se requiere para Visa y American Express)card_network: Es la red (Visa, American Express) a la que se aplican estos valores.acquirer_bin: Es el número de identificación bancaria del banco adquirente que se usa para procesar la tarjeta.acquirer_merchant_id: Es el identificador de comerciante que el adquirente asigna al comercio para su uso en la autorización de transacciones (para transacciones Visa y American Express).
Si agregas estos campos a tu feed de comercios, recibirás un criptograma
3DS2 en el campo unparsed_payment_method_token que reciba
tu servidor de reservas cada vez que se aplique la directiva PSD2 a la transacción. Debes pasar el unparsed_payment_method_token y su criptograma incorporado a tu socio de procesamiento de acuerdo con su especificación.
Cómo implementar 3DS1
Cambios en el servidor de reservas
Haremos una solicitud CreateBooking y, si determinas que se necesita 3DS1 para la transacción, se mostrará un Booking Failure desde tu método CreateBooking y especificaremos PAYMENT_REQUIRES_3DS1 como la causa. En esa respuesta de error, también deberás especificar el mensaje ThreeDS1Parameters dentro del mensaje PaymentFailureInformation:
acs_url: Es la URL desde la que se carga un formulario que se le presentará al usuario para la autenticación.pa_req= Es una solicitud PaymentAuthentication. Se publicará en el formulario ACSUrl.transaction_id= Es un identificador que usa el proveedor de ACS. Se publicará en el formulario ACSUrl.md_merchant_data: Son los datos del Centro de acciones que se compartirán con el proveedor de ACS, si se proporcionan.
Luego, reenviaremos la solicitud CreateBooking original con el pa_response ubicado en el mensaje PaymentInformation. El campo pa_response contendrá la carga útil que nos muestra un proveedor de ACS, y deberás usarla para autorizar la transacción con tu procesador.
A continuación, se muestra un diagrama que describe el flujo de 3DS1:
