> 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/use-cases/post-enrolment/token-verification/token-binding.md).
# Token binding
Token binding starts when the token requestor sends a request to the TSP.
The issuer gateway receives the request from the TSP and then sends **Request Device Binding** to the issuer backend.
{% hint style="warning" %}
For **MDES,** the `deviceBindingReference` in the **Request Device Binding** does not represent the final reference associated to the bind data.
MDES sends the final `deviceBindingReference` only in the success notification after cardholder verification.
{% endhint %}
The sequence diagram below shows the end-to-end flow.
If the issuer returns **approve with step-up authentication**, use the sections below for the selected ID\&V method.
{% hint style="info" %}
**Information**
If the issuer responds to the **Request Device Binding** with an approve with step-up but without providing the list of ID\&V methods to support, the issuer gateway will call the issuer backend with the API **Get IDnV Method List** to retrieve it.
To avoid this, systematically return the list of ID\&V methods if the decision is to step-up.
{% endhint %}
After all interactions are complete, the issuer gateway sends a **Notify Virtual Card Change** notification with:
* `action` for the confirmation performed:
* `DEVICE_BOUND`
* `DEVICE_UNBOUND`
* `deviceBindingReference`, which is the unique binding reference between the token and the device (if the bind was successful).
* `authenticatorInfo`, which contains details about the method that will be used to authenticate the cardholder for the subsequent transactions. This data will be also sent in the authorization request of the payment transaction (***NOTE**: this is supported only by Mastercard*).
{% hint style="warning" %}
After a token binding succeeds, the issuer can later unbind the token from the device.
This option is available only for Visa tokens.
Call **Update Card State** with:
* `virtualCardId` set to the target token ID
* `deviceBindingReference` set to the stored binding reference
* `action` set to `UNBIND_DEVICE`
{% endhint %}
## Verify with an OTP
The TSP generates the OTP.
The issuer gateway forwards it through **Send OTP**, as in the Tokenization flow.
Use `otpMethodId` to identify the selected method and prepare the correct message and channel.
The TSP verifies the OTP and notifies the relevant parties when verification succeeds.
The sequence diagram below shows the flow.
## Verify in the issuer application
In this flow, the issuer verifies the end user in the issuer application.
You can trigger the issuer application in two ways.
### Trigger from the token requestor application
This approach matches the Tokenization flow used for token activation.
The interaction is the same as described already by [Integrate issuer application with wallet](/classic-tokenization/use-cases/card-enrolment/generic-enrollment-flow/step-5-activate-the-token/option-c-activate-in-the-issuer-application/integrate-issuer-application-with-wallet.md) with the difference that the TSP sends additional data that the issuer must parse to identify the token binding context:
* **Visa**
* `deviceID`
* `deviceIndex`
* `lifeCycleTraceID`
* `reasonCode` = `TOKEN_DEVICE_BINDING`
* **Mastercard**
* `authenticationCorrelationId`
These fields are specific to post-Tokenization verification. There is no overlap with the classic tokenization verification.
### Trigger with a push message
The issuer triggers the issuer application through a push message.
{% hint style="warning" %}
This option is supported only by **Mastercard** and it applies only to the **post-tokenization authentication**. Essentially, when providing the list of ID\&V methods, the issuer must provide still a method of the type `bank_app` and assign to the `value` = PUSH\_NOTIFICATION.
If the method is selected, the issuer can send a push message that opens the issuer application.
{% endhint %}
If the end user selects this method, the issuer gateway sends the method ID through **Send OTP** without an OTP value.
MDES does not generate an OTP for this flow.
Use `otpMethodId` to identify the method and build the push message.
### Report the verification result
Regardless of the triggering method used to interact with the application, the issuer must report the result to the TSP through **Update Card State**.
Send these values:
* `virtualCardId` =
* Visa: `tokenReferenceID`
* Mastercard: `tokenUniqueReference`
* `deviceBindingReference` =
* For Visa, use `deviceIndex`
* For Mastercard, use `authenticationCorrelationId`
* `action` =
* `APPROVE_DEVICE_BINDING` when cardholder verification succeeds
* `UNBIND_DEVICE` when cardholder verification fails
The sequence diagram below shows the full flow.
## Verify by 3DS
This is supported only by Visa.
If the issuer wants support this method, a proper configuration must be set on VTS. This is not managed through 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/use-cases/post-enrolment/token-verification/token-binding.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.