> 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 ### Overview Token binding starts when the token requestor sends a request to the TSP. The issuer gateway then sends **Request Device Binding** to the issuer backend. Compared with VTS, MDES provides extra data that can help the issuer backend make a decision: * `scoringInformation` * This field has the same meaning as in a Tokenization request. * Use it to refine the decision. * `recentAuthenticationInformation` * Use this field when recent end user authentication should influence the decision. {% hint style="warning" %} For MDES, `deviceBindingReference` in **Request Device Binding** is not the final reference. 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 section 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 (of course 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. ### 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 sequence diagram below shows the flow. ... The TSP verifies the OTP and notifies the relevant parties when verification succeeds. ### 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 [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). The TSP also 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. #### Trigger with a push message {% hint style="warning" %} This option is supported only by Mastercard. {% endhint %} The issuer triggers the issuer application through a push message. 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 trigger method, 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. ... {% hint style="warning" %} If 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 %} --- # 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.