> For the complete documentation index, see [llms.txt](https://docs.payments.thalescloud.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.payments.thalescloud.io/tokenization/es/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only.md).

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

{% hint style="info" %}
**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.
{% endhint %}

### 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

{% hint style="info" %}
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.
{% endhint %}

### 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](/tokenization/es/implement-tokenization/card-tokenization-request/processing-the-response/approve-with-step-up-authentication/in-app-authentication-with-issuer-backend.md).
  * 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](/tokenization/es/integrate-in-app-id-and-v-for-xpay-wallets.md).
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.

{% hint style="warning" %}
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.
{% endhint %}

### Experiencia de usuario

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

<figure><img src="https://3386638856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW6dljaTEEzefPQILRFB7%2Fuploads%2Fmy3A75mIfu4dD40MV49x%2FToken%20Verification%20-%20OTP.png?alt=media&amp;token=be15ce54-d20f-4cf7-b24f-961f13aa284e" alt=""><figcaption></figcaption></figure>

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

<figure><img src="https://3386638856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW6dljaTEEzefPQILRFB7%2Fuploads%2Fe6oT5WOJWXOqL4Qrxg3l%2FToken%20Verification%20-%20Issuer%20App.png?alt=media&amp;token=41722da4-ac58-459c-a26e-2c9f0b846871" alt=""><figcaption></figcaption></figure>

### Flujo general

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

<figure><img src="https://3386638856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW6dljaTEEzefPQILRFB7%2Fuploads%2FaJxlCqaUgfF81P9drWtD%2FHigh-level%20flow.png?alt=media&amp;token=024a2c5d-be70-4e16-96c3-4a1425936ec9" alt=""><figcaption><p>Flujo general de verificación de token.</p></figcaption></figure>

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

<figure><img src="https://3386638856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW6dljaTEEzefPQILRFB7%2Fuploads%2FKmRLNY5jZTUJsnADQMGs%2FOTP%20verification%20by%20SMS%20or%20email.png?alt=media&amp;token=a673c42b-3d54-44b8-baa7-0c4816f4295c" alt=""><figcaption><p>Flujo de verificación de OTP por SMS o correo electrónico.</p></figcaption></figure>

#### Verificación mediante la aplicación del emisor

<figure><img src="https://3386638856-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FW6dljaTEEzefPQILRFB7%2Fuploads%2FQ0BeMYhZQUxhppq1Jeen%2FVerification%20by%20issuer%20application.png?alt=media&amp;token=d8edbb50-c2ba-4629-8884-a1ccf7d324d6" alt=""><figcaption><p>Flujo de verificación a través de la aplicación del emisor.</p></figcaption></figure>

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](/tokenization/es/integrate-in-app-id-and-v-for-xpay-wallets.md). 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:

<table><thead><tr><th width="211.727294921875">Campo</th><th>Solicitud de vinculación</th><th>Solicitud de verificación del titular de la tarjeta</th></tr></thead><tbody><tr><td><code>deviceID</code></td><td>ID asignado al dispositivo</td><td>-</td></tr><tr><td><code>deviceIndex</code></td><td>Referencia al dispositivo</td><td>-</td></tr><tr><td><code>reasonCode</code></td><td><code>TOKEN_DEVICE_BINDING</code></td><td><code>CARDHOLDER_STEPUP</code></td></tr><tr><td><code>lifeCycleTraceID</code></td><td>ID único que rastrea la solicitud</td><td>ID único que rastrea la solicitud</td></tr></tbody></table>

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

<table><thead><tr><th width="257.1817626953125">Campo</th><th width="275.9090576171875">Solicitud de vinculación</th><th>Solicitud de verificación del titular de la tarjeta</th></tr></thead><tbody><tr><td><code>authenticationCorrelationId</code></td><td>ID único que rastrea la solicitud</td><td>No aplica</td></tr></tbody></table>

### Siguientes pasos

* Para la vinculación del dispositivo, consulte [Vinculación del token](/tokenization/es/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only/device-binding-flow.md).
* Para la verificación del titular de la tarjeta, consulte [Flujo de verificación del titular de la tarjeta](/tokenization/es/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only/cardholder-verification-flow.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.payments.thalescloud.io/tokenization/es/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.