Home

Descripción general

3DS Server

Descripción general#

Para realizar transacciones de autenticación 3DS 2.0, se requiere la integración con una aplicación 3DS Server, como la que proporciona Software Express. Esta aplicación se comunica con la marca de la tarjeta y el emisor para autentificar al titular de la tarjeta, reduciendo las incidencias de fraude y permitiendo los pagos con tarjeta de débito. Es independiente de la aplicación de pago, y el integrador deberá llevar a cabo y gestionar la orquestación en su aplicación.

Este modelo requiere un mayor esfuerzo de integración (necesidad de integración de API), pero permite una mayor flexibilidad en el flujo de pago (gestión por parte de la tienda), y el pago en la caja es realizado por la propia tienda.

El protocolo 3DS 2.0 se diferencia de su versión 1.0 en la posibilidad de permitir la autenticación sin fricción, es decir, un proceso que no requiere interacciones adicionales por parte del comprador.

Esta documentación se centra en las interacciones con 3DS Server. Para más información sobre los demás componentes del flujo, consulte los documentos oficiales de la EMVCo.

Y para saber más sobre estas nomenclaturas (Bin, Software Express, Carat, e-Sitef) Leer más

Comunicación#

Para realizar una transacción de Servicio Web, toda la comunicación se realizará a través de HTTPS/SSL. Es importante que el servidor comercial admita al menos una codificación de 128 bits. El servidor de la tienda debe realizar llamadas a direcciones específicas para las transacciones REST.

Cada servicio debe ser llamado utilizando la URL base concatenada del recurso deseado (ver el capítulo relativo al servicio a consumir). El método HTTP (GET, POST o PUT) indica la acción esperada sobre el recurso elegido. A continuación se muestran las URLs base del Servidor 3DS:

URL base de Producción:

https://3ds.softwareexpress.com.br/

URL Base de homologación:

https://mpi-homolog.softwareexpress.com.br/3ds-server/

Todas las llamadas realizadas a los servicios serán contestadas sincrónica.

Atención:

Nunca utilice la IP en lugar del dominio 3ds.softwareexpress.com.br. La IP puede cambiar en cualquier momento y sin previo aviso, por lo que es importante utilizar el dominio para acceder al servidor 3DS.

Durante la validación de la tarjeta, es posible que se devuelva el código de error 305, lo que indica que la tarjeta no está dentro del rango de tarjetas admitidas para la autenticación 3DS 2.0 por parte del emisor, lo que impide llevar a cabo el proceso de autenticación. La decisión de cancelar la transacción o continuar con el pago sin utilizar el 3DS corresponde al Solicitante 3DS.

Importante:

Además de los parámetros de retorno del servicio descritos en esta especificación, 3DS Server puede devolver otros parámetros sin previo aviso.

Es importante que la aplicación esté preparada para recibir los parámetros desconocidos, además de los ya especificados, y que simplemente los ignore.

Flujos#

El protocolo 3DS 2.0 conta con 2 principales flujos:

  • Sin fricciones: toda la autenticación se realiza sin requerir interacciones adicionales por parte del comprador.
  • Challenge (desafío): la información recogida por el emisor no es suficiente para autentificar al titular de la tarjeta. Por lo tanto, el comprador debe proporcionar más datos, directamente en el sitio web del emisor.

Glosario:

  • 3DS Requestor: Tienda o gateway (como el Portal Carat)
  • DS: Directory Server; representa la marca de la tarjeta
  • ACS: Access Control Server; representa el emisor
  • AReq: Authentication Request, conforme el protocolo 3DS 2.0
  • ARes: Authentication Response, conforme el protocolo 3DS 2.0
  • CReq: Challenge Request, conforme el protocolo 3DS 2.0
  • CRes: Challenge Response, conforme el protocolo 3DS 2.0
  • RReq: Results Request, conforme el protocolo 3DS 2.0
  • RRes: Results Response, conforme el protocolo 3DS 2.0

Flujo Frictionless#

  1. 3DS Requestor crea la transacción de autenticación en el servidor 3DS pasando el número de tarjeta del comprador y el ID de la marca de la tarjeta de crédito.
  2. 3DS Server valida si la tarjeta recibida puede ser autentificada por la marca de la tarjeta indicada. Si es positivo, devuelve la ID de la transacción 3DS Server (three_ds_server.trans_id) y el 3DS Method URL (three_ds_method_url) correspondiente a la tarjeta.
  3. El 3DS Method URL debe ser exibido en el navegador del comprador en un frame "invisible" de 1 pixel.
  4. Esto permitirá a la ACS recoger directamente la información del dispositivo del titular de la tarjeta.
  5. 3DS Requestor envía información para realizar la autenticación.
  6. 3DS Server genera un AReq y lo envía al DS, que lo propaga al ACS. El resultado de la autentificación vuelve al Servidor 3DS como contenido del ARes.
  7. Si la autenticación es exitosa, el estado (campo three_ds_server.status) con valor Y, el ECI (campo eci) y el CAVV (campo authentication.value) y el reference_id (campo ds.transId), que debe enviarse al comprador.

Recomendación:

Para mejorar el rendimiento y permitir que la información se recopile en segundo plano, recomendamos realizar los pasos 1 y 4 inmediatamente después de llenar la tarjeta en lugar de esperar a hacerlo todo de una vez.

Flujo sin fricciones con autorización de pago.#

Atención:

En el flujo Frictionless, durante el paso 1 de la autenticación en el servicio de creación de la transacción en el 3DS Server, se devuelve el reference_id (ID de la transacción ds.trans_id). En el retorno del servicio de autenticación en el 3DS Server, se devuelve el campo eci (Indicador de Comercio Electrónico) y el campo authentication.value (CAVV). Es responsabilidad de la aplicación del comerciante guardar esta información y transmitirla al servicio de ejecución del pago en el paso 2 que se muestra arriba.

  • En el paso 2 de la autorización, la aplicación del comerciante crea la transacción en Carat proporcionando información como el código de la tienda, el número de cuotas y el código de pedido, y recibe como respuesta un NIT (Número Identificador de Transacción). Más información.
  • Con la información obtenida del servicio de creación de la transacción en Carat, la aplicación del comerciante procede a consumir el servicio de ejecución del pago, proporcionando el NIT, los datos de la tarjeta del comprador, el ECI (campo eci) y el CAVV (campo authentication.value), y el reference_id (ID de la transacción 3DS Server ds.trans_id). En caso de éxito, el estado de la transacción de pago cambiará a CONF (confirmado). Más información.

Flujo Challenge#

Los pasos 1 a 6 son los mismos que en el flujo frictionless.

  1. Devolverá el estado (campo three_ds_server.status) con el valor C y la URL del reto rellenada (campo acs.url) y el reference_id (campo ds.transId), este último campo debe ser enviado al adquirente.
  2. 3DS Requestor prepara el CReq para que el navegador del comprador lo envíe a la URL del desafío.
  3. ACS muestra su pantalla de desafío para que el comprador proporcione más información. Tenga en cuenta que pueden ser necesarias varias interacciones para completar este proceso.
  4. El ACS envía la RReq al DS, que a su vez se propaga al 3DS Server. Esta llamada es una notificación que informa del resultado de la autentificación.
  5. ACS envía los CRes al solicitante de 3DS en su URL dada en el paso 5 (campo notification_url). Este objeto contiene el ID de la transacción de 3DS Server.
  6. El solicitante 3DS consulta la transacción del servidor 3DS para obtener el resultado de la autenticación.
  7. 3DS Server devuelve la información de su transacción.

Flujo Challenge con autorización de pago.#

Atención:

En el flujo Challenge, durante el paso 1 de la autenticación en el servicio de creación de la transacción en el 3DS Server, se devuelve el reference_id (ID de la transacción ds.trans_id). Después del desafío, es necesario realizar una consulta en el servicio de consulta del 3DS Server para obtener la información de la autenticación, devolviendo el campo ECI (Indicador de Comercio Electrónico) y el campo authentication.value (CAVV). Corresponde a la aplicación del comerciante almacenar esta información y transmitirla al servicio responsable de la ejecución del pago.

  • En el paso 2 de la autenticación, la aplicación del comerciante crea la transacción en Carat proporcionando información como el código de la tienda, el número de cuotas y el código de pedido, y recibe como respuesta un NIT (Número Identificador de Transacción). Más información.
  • Con la información obtenida del servicio de creación de la transacción en Carat, la aplicación del comerciante procede a consumir el servicio de ejecución del pago, proporcionando el NIT, los datos de la tarjeta del comprador, el ECI (campo eci) y el CAVV (campo authentication.value), y el reference_id (ID de la transacción 3DS Server ds.trans_id). En caso de éxito, el estado de la transacción de pago cambiará a CON (confirmado). Más información.