Welcome to our new developer portal! Use the "Ask" button to chat with our AI Agent.
For the complete documentation index, see llms.txt. This page is also available as Markdown.

Gestionar el desafío OOB

Resumen

El servicio 3DS activa el flujo de desafío OOB cuando una transacción es desafiada y el usuario final tiene un autenticador registrado en la aplicación del emisor.

Experiencia del usuario

Flujo

Resumen del flujo de desafío OOB - paso 1.
Resumen del flujo de desafío OOB - paso 2.

Diagrama de secuencia – Flujo de backend

Los diagramas a continuación muestran la secuencia de extremo a extremo para un flujo de desafío OOB.

Requisitos previos

  • Los productos de tarjeta están configurados en el backend de D1 y en el servidor de directorio de la red de pagos.

  • El usuario final y la tarjeta están registrados en el backend de D1.

  • Se registró un autenticador en el dispositivo.

  • El SDK de D1 está inicializado.

  • La aplicación del emisor tiene configuradas las notificaciones push.


1 – AReq/ARes y primer CReq/CRes

AReq/ARes y CReq/CRes inicial.

2 – CReq/CRes y desafío OOB del emisor

CReq/CRes y desafío OOB del emisor.

Para obtener detalles de implementación del SDK, consulte flujo del SDK.

3 – CReq/CRes final y notificación

CReq/CRes final y notificación.

Diagrama de secuencia – Flujo del SDK

La secuencia a continuación muestra cómo la aplicación del emisor utiliza el SDK de D1 para completar el desafío OOB.

1 - La aplicación del emisor obtiene el desafío FIDO a través del SDK de D1

La aplicación del emisor obtiene el desafío FIDO a través del SDK de D1.

2 - El SDK de D1 autentica al usuario final

El SDK de D1 autentica al usuario final.

Para las notificaciones push, consulte configuración de notificaciones push.

Datos de confirmación de la transacción

La siguiente tabla describe los datos de la transacción que el SDK de D1 proporciona a la aplicación del emisor para fines de visualización.

Nombre del parámetro
Descripción

acsTransId

Un identificador de transacción universalmente único asignado por ACS para identificar una sola transacción.

purchaseDate

Fecha y hora de la compra, expresadas en formato de hora UTC.

purchaseExponent

Unidades menores de la moneda según lo especificado en el exponente de moneda ISO 4217.

threeDSRequestorAppURL

La aplicación solicitante de 3DS declara su URL dentro del mensaje CReq para que la aplicación de autenticación pueda llamar a la aplicación solicitante de 3DS una vez completada la autenticación OOB. Úselo para redirigir al usuario final de vuelta a la aplicación del comercio.

purchaseCurrency

La moneda en la que se expresa el importe de la compra en formato ISO 4217.

merchantName

El nombre del comercio asignado por el adquirente o la red de pagos.

purchaseAmount

El importe en unidades menores de la moneda, sin decimales.

Integración del SDK de D1

  • Llamar a login no es necesario como requisito previo para este caso de uso.

  • Si la aplicación del emisor no recibe una solicitud de verificación mediante notificación push, puede obtener la solicitud llamando al SDK de D1 fetchAuthnRequest API.

  • El SDK utiliza autenticación biométrica fuerte. Si hay varios métodos biométricos disponibles (por ejemplo, Face ID y huella dactilar), el sistema operativo administra la interfaz de usuario.

El siguiente ejemplo muestra cómo la aplicación del emisor usa threeDSRequestorAppURL de los datos de confirmación de la transacción para devolver al usuario final a la aplicación del comercio.

Integración del backend del emisor

Se notifica al backend del emisor al final del flujo de procesamiento a través de la Notificar operación de tarjeta 3DS API.

Última actualización

¿Te fue útil?