3D Secure

Que es 3DS ?

3DS es un protocolo de seguridad diseñado para proteger transacciones en línea mediante la autenticación del titular de la tarjeta antes de que se realice la compra, reduciendo así el riesgo de fraude.

3DS es un mecanismo de protección contra fraudes para comerciantes que mejora la seguridad al aceptar pagos con tarjeta de crédito.

3DS permite a los bancos emisores verificar a los titulares de las tarjetas de crédito durante el proceso de transacción. Esto ayuda a proteger a los titulares de tarjetas contra el fraude y transfiere la responsabilidad a los comerciantes.

3DS agrega una capa adicional de seguridad a las transacciones con tarjetas de crédito y débito en línea.

3DS significa "tres dominios seguros", donde:

1. El primer dominio es el emisor de la tarjeta.
2. El segundo dominio es el minorista que recibe el pago.
3. El tercero dominio es la plataforma de infraestructura 3DS que actúa como un tercero seguro tanto para el consumidor como para el minorista.

Por lo general, durante el pago, el titular de la tarjeta accede a una página de autenticación en el sitio web de su banco e ingresa una contraseña asociada con la tarjeta o un código enviado a su teléfono.

Cuando el titular de una tarjeta se autentica exitosamente, la responsabilidad del fraude pasa del comerciante al titular de la tarjeta, lo que significa que el comerciante no es responsable de dichos pagos.

Como funciona 3DS?

1. El proceso de pago del comerciante recopila información del cliente, como información de facturación, envío y tarjeta, y envía los datos para la autorización de pago.
2. El proveedor de servicios de pago de Deuna o del comerciante determina si se debe requerir 3DS para el pago.
3. Si se requiere 3DS, el cliente es redirigido automáticamente al sitio web de su banco para autenticar el pago. En ese momento, el banco puede determinar autenticar el pago sin requerir más información o puede pedirle al cliente que autentique el pago ingresando un código único enviado por el banco. Proporcionar más información del cliente, como facturación y envío, aumenta la probabilidad de que el banco autentique automáticamente el pago en lugar de exigir al cliente que proporcione un código único enviado por el banco.
4. Después de la autenticación, el cliente es redirigido automáticamente al sitio web del comerciante, momento en el que se completa el pago.

El siguiente diagrama muestra cómo se realiza el pago con 3DS.

1. El comprador hace clic en un botón en el sitio del comerciante para pagar una compra.
2. El sitio web del comerciante muestra la caja de Deuna.
3. El comprador ingresa las credenciales de la tarjeta de crédito y envía el pago.
4. El sistema Deuna se comunica con las asociaciones de tarjetas (Visa/MasterCard/Otras) para autorizar el pago.
5. Las asociaciones de tarjetas se comunican con el banco emisor de la tarjeta.
6. El banco emisor de la tarjeta solicita 3DS junto con una URL para que el comprador la utilice para autenticar el pago y envía una OTP directamente al comprador.
7. Las asociaciones de tarjetas transmiten esa solicitud a Deuna junto con la URL.
8. El sistema Deuna devuelve la URL a la caja de Deuna junto con las instrucciones para autenticar el pago.
9. El pago de Deuna utiliza la URL para mostrar la página de autenticación del banco sin tener que salir del sitio web del comprador.
10. El comprador autentica el pago utilizando la OTP que el banco envió directamente al comprador.
11. El control se devuelve a la UX de pago de Deuna.
12. El proceso de pago de Deuna luego se comunica con el sistema de Deuna para completar el pago y proporciona la prueba de autenticación.
13. El sistema Deuna revisa la información y se comunica con las asociaciones de tarjetas para completar el pago proporcionando la prueba de autenticación.
14. Las asociaciones de tarjetas completan el pago con el banco emisor proporcionando la información del banco emisor.

MPI 3DS de DEUNA

3DS MPI (3D Secure Merchant Plugin Interface) es una solución de DEUNA que proporciona un servicio de autenticación 3D Secure independiente de los procesadores de pago. Esta funcionalidad permite a los comercios utilizar un único proveedor de 3DS a través de múltiples adquirentes, simplificando la integración y mejorando la experiencia del usuario.

Beneficios

• Integración unificada: Un solo punto de integración para 3DS a través de múltiples adquirentes
• Experiencia consistente: Proporciona una experiencia de usuario coherente para la autenticación 3DS
• Mayor conversión: Optimización del flujo de autenticación para mejorar las tasas de conversión
• Compatibilidad amplia: Funciona con procesadores que aceptan valores 3DS generados externamente

📘

Con nuestro 3DS MPI se puede transaccionar ya sea por una integración directa al API, utilizando el payment widget, o el payment link.

Flujo general con el MPI 3DS de DEUNA

Acerca del proceso de recolección de data

Con el fin de lograr una experiencia más fluida y sin fricción para el usuario, recolectamos data de su navegador y dispositivo para tomar una decisión más certera sobre el envío de un challenge al usuario o no. De manera específica, recolectamos la siguiente data:

• La profundidad de color de la pantalla del usuario (color depth)
• La propiedad de "javaEnabled" del navegador del usuario
• El lenguaje de la UI del navegador del usuario
• Dimensiones de la pantalla
• Zona horaria del usuario
• El valor de "user agent" del navegador

Consideraciones al utilizar el MPI 3DS de DEUNA

• La configuración del MPI 3DS es específica por adquirente.
• Para transacciones que fallan por motivos ajenos a 3DS, podría ser necesario reiniciar el proceso de autenticación.

Lista de procesadores que soportan nuestro 3DS MPI

• Unlimit
• Adyen
• Amex
• BAZ
• MIT Bulk
• Cybersource
• Kushki

Lista de monedas y países soportados por nuestro 3DS MPI

El 3DS MPI de DEUNA es compatible con la mayoría de las divisas o monedas. No obstante, le recomendamos que confirme la compatibilidad con su divisa específica con su punto de contacto de DEUNA durante el proceso de integración.

📘

La configuración de 3DS MPI para una nueva moneda suele durar aproximadamente una semana. Asegúrese de planificar en consecuencia para evitar retrasos en su calendario de puesta en marcha.

Redes de tarjetas soportadas por nuestro 3DS MPI

El MPI 3DS de DEUNA soporta las principales marcas de tarjetas: mastercard, visa, y american express. Para asegurar compatibilidad con otras marcas, confírmelo con su punto de contacto de DEUNA durante el proceso de integración

Cómo implementar 3DS

Configuración de 3DS por PSP desde el admin DEUNA:

1. Ir a la sección de Conexiones en el admin:

   

   
   

2. Seleccionar el procesador a activar, ingresar las credenciales respectivas, marcar la casilla de Activa métodos de seguridad y dar click en conectar. En caso de que se quiera utilizar el MPI 3DS de DEUNA, se debe seleccionar "Habilita 3DS DEUNA", de lo contrario se selecciona "Habilita 3DS + nombre de procesador".

   

   
   

3. Para validar si un PSP tiene 3DS activo se debe ingresar en la sección de conexiones activas y dar click en los 3 puntos en la parte superior derecha de cada PSP, en la sección editar, esta desplegara una pantalla con el detalle:

   

   

Configuración con MPI 3DS de DEUNA

Para utilizar 3DS MPI, los comercios deben proporcionar información específica para cada adquirente:

• Número de afiliación (Merchant ID): Este es el identificador del comercio registrado en el adquirente que se usará para procesar con esta conexión.
• BIN de adquiriente (Acquirer's BIN) configurado por el comercio: Número de identificación bancaria (BIN), emitido por el banco o el procesador del comerciante.
• Nombre del comercio
• MCC (Merchant Category Code): Ejemplo de dónde obtener el valor: https://www.mastercard.us/content/dam/public/mastercardcom/na/global-site/documents/quick-reference-booklet-merchant.pdf
• URL del comercio
• País donde opera el comercio

Como realizar un pago con 3D-Secure

Genera un pago:

1. Para crear un pago puedes usar los siguientes dos flujos:
   1. Flujo en dos pasos:
      1. Crear una orden
      2. Crear un pago asociado a esa orden
   2. Flujo en un solo paso

En la respuesta del pago vas a poder evidenciar los siguientes campos que son los necesarios para saber que dicho cobro requiere que el usuario final se autentique:

Los campos importantes a considerar son:

• El estado de la orden (order.status) estará en pending pues no ha sido pagada aún.
• El estado del pago (payment.data.status) va a ser pending_3ds. Este estado indica que se está en la espera de la autenticación por parte del tarjehabiente.
• Para los casos tipo de autenticación tipo challenge (el usuario debe tomar una acción durante la autenticación) o semi-frictionless (el usuario se le presenta el flujo de 3DS pero no necesitar tomar una acción), la propiedad payment.data.next_action.authorization_3ds.url contendrá la URL de la página web que se le debe presentar al comprador.Para fines de compatibilidad con integraciones anteriores, también se podrá encontrar en el campo payment.data.uthorization_3ds.url_challenge. En caso que el comercio tenga una integración con DEUNA vía API (Direct API), el comercio es el responsable de redirigir al usuario a esa página o en caso de mobile abrir dicha página en un webView. En caso de que la integración sea por API(Direct API) y no se quiera gestionar la redirección, se puede utilizar el widget [InitNextAction](https://docs.deuna.com/reference/next-action-web) que maneja el flujo de manera fluida.

📘

Dependiendo del proveedor de pagos y/o MPI la URL debe ser abierta en una pestaña completamente nueva y no en un iFrame. Consulta a DEUNA para que te indique según el proveedor que vayas a usar.

Si usas el widget .initNextAction() y el proveedor de pagos o MPI soporta el uso de iFrame, pidele a DEUNA que te configure el InitNextAction Widget para que se renderize como iFrame en vez de requerir redirección.

• En caso el comercio esté integrado con alguno de los widgets de DEUNA, los widgets serán los responsables del redireccionamiento o renderización del iFrame y la interpretación de cuando se requiere el flujo de 3DS.
• Para los casos tipo frictionless (el banco emisor autentica al usuario sin ningún tipo de acción o redirección), se obtendrá estados processed o denied en el pago (payment.data.status) sin haber previamente recibido el pending_3ds. Esto se debe a que en las transacciones de tipo frictionless, el banco basado en los datos proporcionados durante la petición de compra pudo determinar que él usuario es auténtico y de está forma no solicita un paso adicional de verificación para la operación, continuando así con el flujo normal.

Response de ejemplo

{
    "order": {
        "order_id": "75029759-4a64-42cd-b0b6-9f12777707b7",
        "currency": "USD",
        "total_amount": 3150,
        // ...
        "status": "pending", // status of the order will be "pending"
        "payment": {
            "data": {
             		// ...
                "method_type": "credit_card",
                "id": "75029759-4a64-42cd-b0b6-9f12777707b7",
                "processor": "kushki",
                "status": "pending_3ds", // note here the payment status
                "authorization_3ds": {
                    "version": "3DS2",
                    "url_challenge": "https://api.stg.deuna.io/transactions/view_challenge?token=01HC0XG8GA2GH5G684QW572507"
                }
            }
        }
    }
}

Renderizar el url_challenge

Página del banco / franquicia

Una vez se termine la autenticación, DEUNA ofrece que el comercio sea redirijido a unos callback_urls establecidos por el comercio o a una página default.

• Uso de callback_urls: el comercio puede configurar los callbacks en:
  • Para el purchase V1: enviar los callback_urls en el siguiente campo:
    • specific_fields.callbacks
  • Para el purchase V2: enviar los callback_urls en el siguiente campo:
    • callback_urls
  • En caso se está usando uno de los widgets: en este caso como el comercio solo es encargado de crear la orden, se pueden pasar los callback_urls en el siguiente campo:
    • Comunicarse con DEUNA para que le indiquemos que campo usar.
• Uso de página default de DEUNA: en caso el comercio no haga uso de los callback_urls posterior a la autenticación, el comprador será redirijido a la siguiente página web default.

📝

Dependiendo del banco emisor se obtienen páginas de challenge distintas, pero el flujo de redireccionamiento sigue siendo el mismo.

📘

Una vez que se abre el challenge, este tiene una duración máxima de 10min. Este tiempo es establecido por la especificación EMVCo 3DS (sección 5.5 Timeouts).

Consultar estado final del pago

DEUNA dispone de dos maneras para que el comercio puede conocer el estado final del pago posterior a la autenticación de 3DS.

1. Hacer un long polling del API Get Order
2. Escuchar los webhooks de DEUNA

DEUNA recomienda que se implementen ambos procesos, ya que en caso que el servidor del comercio tenga intermitencia y no pueda escuchar los webhooks, con el long polling puede recuperarse luego de la intermitencia.

3D-Secure Sin Fricción (Frictionless)

En estos casos el Usuario (Portador de la tarjeta) no se le solicitará ningún tipo de verificación de autenticación al momento de realizar el pago, dado que el ACS (Access Control Server) ha validado la autenticidad del usuario con los datos proporcionados en la compra.

Esto provee una experiencia más fluida al Usuario, aumentando así la tasa de aprobación de pagos y disminuyendo el Fraude de esta forma los usuarios se sentirán más seguros al momento de realizar compras en el Comercio.

Para ejecutar una compra con 3D-Secure Frictionless exitosa se debe recolectar cierta información con respecto al Usuario tales como, full BillingAddress(Código postal, linea 1, linea 2, ciudad, estado/provincia, teléfono, email, etc), huella del dispositivo (Fingerprint), dirección IP, detalles del navegador y demás información relevante sobre el Usuario.

Response de ejemplo

{
  "order": {
    "order_id": "75029759-4a64-42cd-b0b6-9f12777707b7",
    "currency": "USD",
    "total_amount": 3150,
    // ...
    "status": "succeeded",
    "payment": {
      "data": {
        // ...
        "method_type": "credit_card",
        "id": "75029759-4a64-42cd-b0b6-9f12777707b7",
        "processor": "kushki",
        "status": "processed"
      }
    }
  }
}

Stripe Radar Quality Excellent

Nuestra integración está diseñada para cumplir con los estándares de excelencia de Stripe (Radar Quality Excellent) en la gestión y prevención de fraude, pero para lograr tal excelencia se necesita enviar la información necesaria la cual es:

• Radar session :
  En nuestros Widgets (Checkout, Payment, Vault, etc) se envían automáticamente.
  Via API, se debe mandar en la siguiente propiedad:
  
  

  Purchase V1Purchase V2

  {
    //...
    "device_id": "{{DEVICE_ID}}"
    //...
  }
  

  {
    //...
    "anti_fraud_info": {
      "session_id": "{{SESSION_ID}}"
    }
    //...
  }
  

• Customer signals
  Para esto debemos proporcionar la información completa del usuario:
  
  

  Purchase V1Purchase V2

  {
    //...
    "email": "{{USER_EMAIL}}",
    "credit_card": {
      "expiry_month": "11",
      "expiry_year": "29",
      "card_number": "4111111111111111",
      "card_holder": "Elon Musk",
      "card_holder_dni": "1234567891",
      "zip": "12345",
      "city": "Ibarra",
      "address1": "Avenida Mariano Acosta & Obispo Alejandro Pasquel Monge, Ibarra, Ecuador",
      "state": "Quito",
      "phone": "+59123456789",
      "country": "Ecuador",
      "card_cvv": "123"
    }
    //...
  }
  

  {
  	//...
    "payer_info": {
      "email": "{{USER_EMAIL}}"
    },
    "credit_info": {
      "expiry_month": "11",
      "expiry_year": "29",
      "card_number": "4111111111111111",
      "card_holder": "Elon Musk",
      "card_holder_dni": "1234567891",
      "zip": "12345",
      "city": "Ibarra",
      "address1": "Avenida Mariano Acosta & Obispo Alejandro Pasquel Monge, Ibarra, Ecuador",
      "state": "Quito",
      "phone": "+59123456789",
      "country": "Ecuador",
      "card_cvv": "123"
    }
    //...
  }
  

Como probar el flujo de 3DS en el ambiente de sandbox?

Consulte la documentación de su proveedor de servicios de pago para localizar las tarjetas de prueba y los montos necesarios para activar 3DS y utilizarlas con su implementación para probar 3DS con DEUNA.

Errores

Al momento de realizar el proceso de autenticación con el MPI 3DS de DEUNA, distintos errores pueden tener lugar. Para los casos particulares donde un pago falle por un error específico del flujo de 3DS, se obtendrá uno de estos errores: