Tanto 3DS1 como 3DS2 están disponibles para tu integración de Reservas de extremo a extremo de Actions Center. Puedes implementar cualquiera de estos dos protocolos (o ambos) en tu integración.
Tanto 3DS1 como 3DS2 cumplirán con el requisito de autenticación reforzada de clientes de la directiva PSD2, pero hay 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 están en el EEE).
- La implementación de 3DS2 requiere cambios en tu feed de comercios.
Cómo implementar 3DS2
Para implementar el protocolo 3DS2, debes agregar campos adicionales a tu
feed de comercios dentro del mensaje TokenizationConfig. Si todos los pagos van a la misma cuenta, repetirás el valor dentro de cada entrada del comercio. Si los pagos van a cuentas diferentes, los valores en
cada entrada del comercio deben 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 transacciones de prueba de 3DS2.payment_country_code: Es el país en el que se procesará la transacción, en formato ISO 3166-1 alpha-2.- Mensaje
CardNetworkParameters: Este mensaje se repite con los valores específicos para las diferentes redes (necesario solo 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 utilizado para procesar la tarjeta.acquirer_merchant_id: Es el identificador de comerciante que el adquirente le asigna al comercio para usarlo en la autorización de transacciones (de Visa y American Express).
Si agregas estos campos a tu feed de comercios, se incluirá un criptograma 3DS2 dentro del valor unparsed_payment_method_token que reciba tu servidor de reservas cada vez que se aplique la PSD2 a la transacción. Debes pasar el campo 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
Crearemos una solicitud CreateBooking
y, si determinas que se necesita el protocolo 3DS1 para la transacción, mostraremos un
Booking Failure en 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 que Actions Center compartirá con el proveedor de ACS si se proporcionan.
Luego, volveremos a enviar la solicitud CreateBooking original con el pa_response ubicado dentro del mensaje PaymentInformation. El campo pa_response contendrá la carga útil que nos envía un proveedor de ACS, y debes usarla para autorizar la transacción con tu procesador.
A continuación, se muestra un diagrama que describe el flujo de 3DS1:
