> 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/classic-tokenization/es/casos-de-uso/postinscripcion/verificacion-del-token/vinculacion-del-token.md).

# Vinculación del token

El enlace del token comienza cuando el solicitante del token envía una solicitud al TSP.

La pasarela del emisor recibe la solicitud del TSP y luego envía **Solicitar enlace del dispositivo** al backend del emisor.

{% hint style="warning" %}
Para **MDES,** el `deviceBindingReference` en el **Solicitar enlace del dispositivo** no representa la referencia final asociada a los datos de enlace.

MDES envía la referencia final `deviceBindingReference` solo en la notificación de éxito después de la verificación del titular de la tarjeta.
{% endhint %}

El siguiente diagrama de secuencia muestra el flujo de extremo a extremo.

*<mark style="color:$warning;">\<diagrama de secuencia></mark>*

Si el emisor devuelve **aprobar con autenticación reforzada**, use las secciones siguientes para el método de ID\&V seleccionado.

{% hint style="info" %}
**Información**

Si el emisor responde al **Solicitar enlace del dispositivo** con una aprobación con autenticación reforzada, pero sin proporcionar la lista de métodos de ID\&V que admite, la pasarela del emisor llamará al backend del emisor con la API **Obtener lista de métodos IDnV** para recuperarla.

Para evitar esto, devuelva sistemáticamente la lista de métodos de ID\&V si la decisión es pasar a autenticación reforzada.
{% endhint %}

Después de completar todas las interacciones, la pasarela del emisor envía una **Notificar cambio de tarjeta virtual** notificación con:

* `acción` para la confirmación realizada:
  * `DEVICE_BOUND`
  * `DEVICE_UNBOUND`
* `deviceBindingReference`, que es la referencia única de vinculación entre el token y el dispositivo (si el enlace fue exitoso).
* `authenticatorInfo`, que contiene detalles sobre el método que se usará para autenticar al titular de la tarjeta en las transacciones posteriores. Estos datos también se enviarán en la solicitud de autorización de la transacción de pago (***NOTA**: esto solo es compatible con Mastercard*).

{% hint style="warning" %}
Después de que un enlace de token se complete correctamente, el emisor puede desvincular posteriormente el token del dispositivo.

<mark style="color:$warning;">Esta opción solo está disponible para tokens de Visa.</mark>

Llame a **Actualizar estado de la tarjeta** con:

* `virtualCardId` establecido en el ID del token de destino
* `deviceBindingReference` establecido en la referencia de vinculación almacenada
* `acción` establecido en `UNBIND_DEVICE`
  {% endhint %}

## Verificar con un OTP

El TSP genera el OTP.

La pasarela del emisor lo reenvía a través de **Enviar OTP**, como en el flujo de tokenización.

Use `otpMethodId` para identificar el método seleccionado y preparar el mensaje y el canal correctos.

El TSP verifica el OTP y notifica a las partes correspondientes cuando la verificación se realiza correctamente.

El siguiente diagrama de secuencia muestra el flujo.

*<mark style="color:$warning;">\<diagrama de secuencia></mark>*

## Verificar en la aplicación del emisor

En este flujo, el emisor verifica al usuario final en la aplicación del emisor.

Puede activar la aplicación del emisor de dos maneras.

### Activar desde la aplicación del solicitante del token

Este enfoque coincide con el flujo de tokenización utilizado para la activación del token.

La interacción es la misma que ya se describe en [Integrar la aplicación del emisor con la cartera](/classic-tokenization/es/casos-de-uso/inscripcion-de-tarjetas/flujo-generico-de-inscripcion/paso-5-activar-el-token/opcion-c-activar-en-la-aplicacion-del-emisor/integrar-la-aplicacion-del-emisor-con-la-billetera.md) con la diferencia de que el TSP envía datos adicionales que el emisor debe analizar para identificar el contexto del enlace del token:

* **Visa**
  * `deviceID`
  * `deviceIndex`
  * `lifeCycleTraceID`
  * `reasonCode` = `TOKEN_DEVICE_BINDING`
* **Mastercard**
  * `authenticationCorrelationId`

Estos campos son específicos de la verificación posterior a la tokenización. No se superponen con la verificación clásica de tokenización.

### Activar con un mensaje push

El emisor activa la aplicación del emisor mediante un mensaje push.

{% hint style="warning" %}
Esta opción solo es compatible con **Mastercard** y solo se aplica a la **autenticación posterior a la tokenización**. Esencialmente, al proporcionar la lista de métodos de ID\&V, el emisor aún debe proporcionar un método del tipo `bank_app`  y asignar al `valor` = PUSH\_NOTIFICATION.&#x20;

Si se selecciona el método, el emisor puede enviar un mensaje push que abre la aplicación del emisor.
{% endhint %}

Si el usuario final selecciona este método, la pasarela del emisor envía el ID del método a través de **Enviar OTP** sin un valor de OTP.

MDES no genera un OTP para este flujo.

Use `otpMethodId` para identificar el método y construir el mensaje push.

### Informar el resultado de la verificación

Independientemente del método de activación utilizado para interactuar con la aplicación, el emisor debe informar el resultado al TSP a través de **Actualizar estado de la tarjeta**.

Envíe estos valores:

* `virtualCardId` =
  * Visa: `tokenReferenceID`
  * Mastercard: `tokenUniqueReference`
* `deviceBindingReference` =
  * Para Visa, use `deviceIndex`
  * Para Mastercard, use `authenticationCorrelationId`
* `acción` =
  * `APPROVE_DEVICE_BINDING` cuando la verificación del titular de la tarjeta se realice correctamente
  * `UNBIND_DEVICE` cuando la verificación del titular de la tarjeta falle

El siguiente diagrama de secuencia muestra el flujo completo.

*<mark style="color:$warning;">\<diagrama de secuencia></mark>*

## Verificar mediante 3DS

Esto solo es compatible con Visa.

Si el emisor quiere dar soporte a este método, se debe configurar adecuadamente en VTS.


---

# 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/classic-tokenization/es/casos-de-uso/postinscripcion/verificacion-del-token/vinculacion-del-token.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.
