Verificación de token para comercio electrónico

Use este flujo para aumentar la confianza en una tarjeta digital después de Tokenización.

Se aplica a tokens utilizados para casos de uso de tarjeta almacenada (COF) y comercio electrónico. A diferencia de los tokens de pago por proximidad, estos tokens se almacenan en el TSP de la red de pagos. No se aprovisionan a un dispositivo.

Los comercios suelen solicitar la verificación del token antes de una acción sensible. También pueden solicitarla antes de vincular un token a un dispositivo o clave de acceso.

Flujos de red de pago compatibles

Visa y Mastercard admiten este flujo con diferentes nombres:

• Visa: Cloud Token Framework (CTF)

• Mastercard: Autenticación posterior a la tokenización para tarjeta almacenada segura y Click to Pay

Tipos de solicitud de verificación

Hay dos tipos de solicitud de verificación de token:

1. Vincular un token a un dispositivo o clave de acceso. Debido a que el token está basado en la nube, la vinculación permite al comercio usar las capacidades del dispositivo para asegurar las transacciones con token y restringir el uso del token a un dispositivo específico. La vinculación aumenta la confianza porque requiere la verificación del titular de la tarjeta en el dispositivo de destino. El mismo token puede vincularse a varios dispositivos, pero cada dispositivo normalmente requiere verificación del titular de la tarjeta.

2. Solicitar verificación del titular de la tarjeta. Un usuario final que ha iniciado sesión en una aplicación o sitio web del comercio puede realizar una acción sensible, como cambiar una dirección de correo electrónico o una contraseña. Si la cuenta almacena métodos de pago, el comercio puede solicitar la verificación del titular de la tarjeta para confirmar la identidad del usuario final. Si el comercio no puede vincular el token, puede solicitar periódicamente la verificación del titular de la tarjeta en el momento del pago para aumentar la confianza. Mastercard aún no admite este flujo.

Qué hace D1

En ambos casos, D1 orquesta el flujo en nombre del emisor. El backend del emisor no necesita implementar un flujo de trabajo adicional.

El backend del emisor solo necesita devolver los datos del usuario final cuando D1 se los solicite. Luego, D1 selecciona en nombre del emisor los métodos de ID&V disponibles, según las preferencias definidas durante la incorporación de D1.

Obligaciones del emisor

Independientemente del modelo de integración seleccionado, el emisor debe proporcionar los datos del usuario final y mantenerlos actualizados.

D1 usa estos datos para elaborar la lista de métodos de ID&V.

Resultados de la decisión

Para cada solicitud, D1 devuelve el valor de decisión esperado por el TSP de la red de pago:

• verde: aprobar

• amarillo: aprobar con autenticación reforzada

• rojo: denegar

D1 gestiona la decisión en nombre del emisor.

D1 no devuelve verde para estas solicitudes. Este proceso aumenta el nivel de garantía de un token de comercio electrónico. La aprobación inicial se basa solo en datos válidos de la tarjeta, como el PAN y la fecha de vencimiento. Los actores maliciosos pueden capturar estos datos. Por lo tanto, si los datos de la tarjeta quedan expuestos, la creación del token puede ser ilegítima.

Métodos de ID&V compatibles

Como de costumbre, cuando la decisión es amarillo, autenticación reforzada se requiere. D1 añade los métodos de ID&V compatibles a la decisión que devuelve al TSP de la red de pago.

D1 admite estos métodos:

• ID&V con un OTP enviado por SMS o correo electrónico

• ID&V a través de la aplicación del emisor. Esto se logra de dos maneras:

  • La aplicación del comercio activa la aplicación del emisor, como en un flujo estándar de Tokenización. Consulte Autenticación en la aplicación.

  • El emisor activa su propia aplicación mediante una notificación push. Esto solo es compatible con Mastercard.

Requisitos previos para los métodos de ID&V

El emisor debe cumplir estos requisitos previos para que D1 pueda gestionar los métodos de ID&V disponibles:

1. Los datos de contacto del usuario final están disponibles.

2. La información de la aplicación del emisor está configurada. Los mismos requisitos de Tokenización se aplican al TSP. Consulte Integrar ID&V en la aplicación.

3. La configuración establecida durante la incorporación de D1 incluye:

   1. Métodos de ID&V compatibles.

   2. Plantillas de SMS y correo electrónico, cuando la opción OBO está habilitada.

   3. Una implementación de la Entregar OTP API, cuando la opción OBO no está habilitada.

La opción OBO no puede habilitarse para un caso de uso específico. Por ejemplo, no puede habilitarse para solicitudes posteriores a la Tokenización y deshabilitarse para solicitudes de Tokenización.

Experiencia de usuario

Recorrido del usuario final cuando se selecciona un OTP para la verificación:

Recorrido del usuario final cuando se selecciona la aplicación del emisor como método de verificación:

Flujo general

El siguiente diagrama muestra las partes y los pasos principales en una solicitud de verificación de token:

Flujo general de verificación de token.

Según la selección del usuario final, la verificación usa un OTP o la aplicación del emisor.

Verificación de OTP mediante SMS o correo electrónico

Flujo de verificación de OTP por SMS o correo electrónico.

Verificación mediante la aplicación del emisor

Flujo de verificación a través de la aplicación del emisor.

La integración entre la aplicación del comercio y la aplicación del emisor en el paso 9 está fuera del alcance de Thales.

Use la misma guía de la red de pago que para un flujo de Tokenización. Consulte Integrar ID&V en la aplicación. Gestione los datos adicionales que añaden las redes de pago para identificar el caso de uso de origen.

En particular:

• Visa añade los siguientes datos en comparación con una verificación para un flujo de Tokenización:

Campo	Solicitud de vinculación	Solicitud de verificación del titular de la tarjeta
deviceID	ID asignado al dispositivo	-
deviceIndex	Referencia al dispositivo	-
reasonCode	TOKEN_DEVICE_BINDING	CARDHOLDER_STEPUP
lifeCycleTraceID	ID único que rastrea la solicitud	ID único que rastrea la solicitud

• Mastercard añade los siguientes datos en comparación con una verificación para un flujo de Tokenización:

Campo	Solicitud de vinculación	Solicitud de verificación del titular de la tarjeta
authenticationCorrelationId	ID único que rastrea la solicitud	No aplica

Siguientes pasos

• Para la vinculación del dispositivo, consulte Vinculación del token.

• Para la verificación del titular de la tarjeta, consulte Flujo de verificación del titular de la tarjeta.