Documentación

Realizar un pago 3DS

Suggest Edits

Realizar un pago con 3DS

1. 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

2. Usa la respuesta de pago

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"
                }
            }
        }
    }
}

3. Renderizar el url_challenge

Página del banco / franquicia

4. Redirige al usuario

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).

5. Consulta el 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.

Data de integración

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

La 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:

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

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

Customer signals

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

{
  //...
  "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"
  }
  //...
}

Probar 3DS en ambiente sandbox

Si quieres probar 3DS en modo prueba de DEUNA, consulta la documentación de su proveedor de servicios de pago para localizar

  • Tarjetas de prueba.
  • Montos de prueba necesarios para activar 3DS .

📘

Utiliza la información de prueba con su implementación para probar 3DS con DEUNA

Códigs de error

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:

Código de errorMotivo de rechazo
DEUNA_3DS.FAILED_CHALLENGE_AUTHENTICATIONthe cardholder challenge failed
DEUNA_3DS.UNAVAILABLE_CHALLENGE_AUTHENTICATIONcardholder authentication is rejected without a challenge by the issuer
DEUNA_3DS.UNABLE_ISSUERIssuer unable to perform authentication
DEUNA_3DS.ENROLLMENT_CHECK_ERRORa system error prevented authentication when checking enrollment
DEUNA_3DS.AUTHENTICATION_NOT_AVAILABLE_WHEN_CHECKING_ENROLLMENTa system error prevented authentication when checking enrollment
DEUNA_3DS.ENROLLMENT_CHECK_TIMEOUTan error occurred while attempting to check if the cardholder is part of an authentication program
DEUNA_3DS.UNSUCCESSFUL_FRICTIONLESS_AUTHENTICATIONauthentication without a challenge by the card issuer failed
DEUNA_3DS.STAND_IN_FRICTIONLESS_AUTHENTICATION_ATTEMPTEDcardholder is enrolled in 3-D Secure but the card issuer does not support 3-D Secure
DEUNA_3DS.UNAVAILABLE_FRICTIONLESS_AUTHENTICATIONauthentication is unavailable
DEUNA_3DS.REJECTED_FRICTIONLESS_AUTHENTICATIONcardholder authentication is rejected without a challenge by the issuer
DEUNA_3DS.TIME_EXPIREDthe time for the user to complete the 3DS authentication flow has expired

Updated 2 days ago