> 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/posterior-a-la-inscripcion/verificacion-del-token/vinculacion-del-token.md).
# Vinculación del token
La vinculación 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 vinculación del dispositivo** al backend del emisor.
{% hint style="warning" %}
Para **MDES,** el `deviceBindingReference` en el **Solicitar vinculación del dispositivo** no representa la referencia final asociada a los datos de vinculación.
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 diagrama de secuencia a continuación muestra el flujo de extremo a extremo.
Si el emisor devuelve **aprobar con autenticación reforzada**, utilice las secciones a continuación para el método de ID\&V seleccionado.
{% hint style="info" %}
**Información**
Si el emisor responde a la **Solicitar vinculación del dispositivo** con una aprobación con autenticación reforzada pero sin proporcionar la lista de métodos de ID\&V compatibles, la pasarela del emisor llamará al backend del emisor con la API **Obtener la lista de métodos de IDnV** para recuperarla.
Para evitar esto, devuelva sistemáticamente la lista de métodos de ID\&V si la decisión es aplicar autenticación reforzada.
{% endhint %}
Una vez completadas 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 la vinculación fue exitosa).
* `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 una vinculación de token se realice correctamente, el emisor puede desvincular posteriormente el token del dispositivo.
Esta opción solo está disponible para tokens de Visa.
Llamar 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.
Usar `otpMethodId` para identificar el método seleccionado y preparar el mensaje y canal correctos.
El TSP verifica el OTP y notifica a las partes correspondientes cuando la verificación tiene éxito.
El diagrama de secuencia a continuación muestra el flujo.
## 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 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 la ya descrita por [Integrar la aplicación del emisor con la billetera](/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-cartera.md) con la diferencia de que el TSP envía datos adicionales que el emisor debe analizar para identificar el contexto de vinculación 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 hay superposición 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 se aplica solo a la **autenticación posterior a la tokenización**. Esencialmente, al proporcionar la lista de métodos de ID\&V, el emisor debe proporcionar también un método del tipo `bank_app` y asignar al `valor` = PUSH\_NOTIFICATION.
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.
Usar `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 tiene éxito
* `UNBIND_DEVICE` cuando la verificación del titular de la tarjeta falla
El diagrama de secuencia a continuación muestra el flujo completo.
## Verificar mediante 3DS
Esto solo es compatible con Visa.
Si el emisor desea admitir este método, debe configurarse adecuadamente en VTS. Esto no se gestiona mediante API.
---
# 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/posterior-a-la-inscripcion/verificacion-del-token/vinculacion-del-token.md?ask=&goal=
```
`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.