Vinculación del token
Normalmente, un solicitante de token, como un comerciante, inicia una solicitud de vinculación de token porque el usuario final está listo para pagar con un token. La vinculación de token restringe el uso del token y aumenta la confianza en su legitimidad.
D1 recibe la solicitud y orquesta el flujo de trabajo utilizando los datos registrados. El backend del emisor no requiere nuevas API. El nivel de implicación del backend del emisor depende del modelo de integración seleccionado por el emisor.
Como la vinculación de token implica un dispositivo, el emisor puede definir tipos de dispositivos no confiables durante la incorporación en D1. D1 utiliza estos datos para rechazar una solicitud de vinculación cuando el TSP proporciona la información del dispositivo requerida.
La siguiente tabla enumera la información que el emisor puede usar para definir dispositivos no confiables:
Tipos de dispositivos no confiables
El emisor puede seleccionar tipos de dispositivos en los que no confía. Por ejemplo, dispositivos de tipo RELOJ.
Fabricante del dispositivo
El emisor puede enumerar los fabricantes de dispositivos en los que no confía.
Fabricante del dispositivo - versión del SO
Si se conoce, el emisor puede especificar una versión del sistema operativo en la que no confía.
Fabricante del dispositivo - versión del firmware
Si se conoce, el emisor puede especificar una versión del firmware en la que no confía.
Sin reglas para dispositivos no confiables, D1 siempre requiere autenticación reforzada para cada solicitud de vinculación.
Diagramas de secuencia
Los siguientes diagramas de secuencia muestran el flujo completo orquestado por D1 y el nivel de participación del backend del emisor.
Si no se han definido dispositivos no confiables, o si ningún dispositivo coincide con las reglas definidas, D1 siempre realiza autenticación reforzada y proporciona la lista de métodos de ID&V disponibles.
Para conocer los requisitos previos de ID&V, consulte Requisitos previos para los métodos de ID&V.
Verificación OTP por SMS o correo electrónico
El siguiente diagrama de secuencia muestra el flujo cuando el usuario final elige OTP por SMS o correo electrónico para la verificación:
La Entregar método de autenticación reforzada en el paso 08 sigue correspondiendo al Entregar OTP API. Esta API entrega el método de ID&V seleccionado, que en este caso es un OTP.
Si el backend del emisor gestiona la entrega del OTP, debe implementar Entregar OTP API y usar el otp.reason campo para distinguir esta solicitud de una solicitud de tokenización. Puede usar deliveryChannel para determinar el tipo de mensaje:
otp.reason=VINCULACIÓN DE DISPOSITIVOdeliveryChannel=SMSoCORREO ELECTRÓNICO
Verificación mediante la aplicación del emisor
El siguiente diagrama de secuencia muestra el flujo cuando el usuario final elige la aplicación del emisor como método de verificación:
Como se describe en el Flujo de alto nivel sección, el backend del emisor debe gestionar la integración requerida en el paso [02]. Los datos compartidos dependen del TSP. En comparación con un flujo de tokenización, utilice el siguiente mapeo para rellenar StepupAuthenticationResult correctamente:
authenticationId
authenticationCorrelationId
lifeCycleTraceID
Verificación mediante la aplicación del emisor usando un disparador administrado por el emisor
El emisor puede admitir la verificación en la aplicación del emisor usando un mensaje PUSH. Esto evita depender de la aplicación del comerciante para activar la aplicación del emisor.
Esta opción solo se admite bajo estas condiciones:
El emisor admite tarjetas Mastercard. Solo Mastercard puede propagar este tipo de opción de ID&V al comerciante.
El emisor no depende del servicio D1 OBO para enviar mensajes al usuario final. En ese caso, Thales no puede enviar el mensaje PUSH en nombre del emisor.
El siguiente diagrama muestra este flujo:
La Entregar método de autenticación reforzada en el paso 04 sigue correspondiendo al Entregar OTP API. Esta API entrega el método de ID&V seleccionado, en este caso un mensaje PUSH. Para identificar este caso, el emisor debe comprobar los siguientes campos:
otp.reason=VINCULACIÓN DE DISPOSITIVOdeliveryChannel=PUSHdeviceInformation.deviceReferencedigitalCardId
Para informar del resultado a través de StepupAuthenticationResult, el emisor debe enviar el siguiente valor junto con digitalCardId:
authenticationId=deviceInformation.deviceReference
En este caso, no otp.value se proporciona.
El emisor es libre de gestionar el contenido y el formato del mensaje PUSH.
Última actualización
¿Te fue útil?