> 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/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only.md). # Token verification for e-commerce Use this flow to increase trust in a digital card after **Tokenization**. It applies to tokens used for card-on-file (COF) and e-commerce use cases. Unlike proximity-payment tokens, these tokens are stored by the payment network's TSP. They are not provisioned to a device. Merchants typically request token verification before a sensitive action. They can also request it before binding a token to a device or passkey. ### Supported payment network flows Visa and Mastercard support this flow under different names: * Visa: **Cloud Token Framework (CTF)** * Mastercard: **Post-Tokenization Authentication for Secure Card on File and Click to Pay** ### Verification request types There are two token verification request types: 1. **Bind a token to a device or passkey**. Because the token is cloud-based, binding lets the merchant use device capabilities to secure token transactions and restrict token use to a specific device. Binding increases trust because it requires cardholder verification on the target device. The same token can be bound to multiple devices, but each device usually requires cardholder verification. 2. **Request cardholder verification**. An end user logged in to a merchant application or website may perform a sensitive action, such as changing an email address or password. If the account stores payment methods, the merchant can request cardholder verification to confirm the end user's identity. If the merchant cannot bind the token, it can periodically request cardholder verification at checkout to increase trust. *Mastercard does not yet support this flow.* ### What D1 does In both cases, D1 orchestrates the flow on behalf of the issuer. The issuer backend does not need to implement an additional workflow. The issuer backend only needs to return end user details when D1 requests them. D1 then selects the available ID\&V methods on behalf of the issuer, according to preferences defined during D1 onboarding. {% hint style="info" %} **Issuer obligations** Regardless of the selected integration model, the issuer must provide end user details and keep them accurate. D1 uses this data to build the list of ID\&V methods. {% endhint %} ### Decision outcomes For each request, D1 returns the decision value expected by the payment network TSP: * `green`: approve * `yellow`: approve with **step-up authentication** * `red`: decline {% hint style="info" %} D1 manages the decision on behalf of the issuer. D1 does not return `green` for these requests. This process increases the assurance level of an e-commerce token. The initial approval relies only on valid card details, such as the PAN and expiration date. Malicious actors can capture these details. Therefore, if card details are exposed, token creation may be illegitimate. {% endhint %} ### Supported ID\&V methods As usual, when the decision is `yellow`, **step-up authentication** is required. D1 adds the supported ID\&V methods to the decision it returns to the payment network TSP. D1 supports these methods: * ID\&V with an OTP sent by SMS or email * ID\&V through the issuer application. This is achieved in two ways: * The merchant application triggers the issuer application, as in a standard Tokenization flow. See [In-app authentication](/tokenization/implement-tokenization/card-tokenization-request/processing-the-response/approve-with-step-up-authentication/in-app-authentication-with-issuer-backend.md). * The issuer triggers its own application through a push notification. This is only supported by Mastercard. ### Prerequisites for ID\&V methods The issuer must meet these prerequisites so D1 can manage the available ID\&V methods: 1. End user contact details are available. 2. Issuer application information is configured. The same Tokenization requirements apply to the TSP. See [Integrate in-app ID\&V](/tokenization/integrate-in-app-id-and-v-for-xpay-wallets.md). 3. The configuration established during D1 onboarding includes: 1. Supported ID\&V methods. 2. SMS and email templates, when the OBO option is enabled. 3. An implementation of the `Deliver OTP` API, when the OBO option is not enabled. {% hint style="warning" %} The OBO option cannot be enabled for a specific use case. For example, it cannot be enabled for post-Tokenization requests and disabled for Tokenization requests. {% endhint %} ### User experience End user journey when an OTP is selected for verification:
End user journey when the issuer application is selected as the verification method:
### High-level flow The following diagram shows the parties and the main steps in a token verification request:

High-level token verification flow.

Depending on the end user's selection, verification uses an OTP or the issuer application. #### OTP verification using SMS or email

OTP verification flow by SMS or email.

#### Verification by issuer application

Verification flow through the issuer application.

The integration between the merchant application and issuer application in step 9 is outside Thales' scope. Use the same payment network guidance as for a Tokenization flow. See [Integrate in-app ID\&V](/tokenization/integrate-in-app-id-and-v-for-xpay-wallets.md). Handle the additional data that payment networks add to identify the originating use case. In particular: * Visa adds the following data compared to a verification for a Tokenization flow:
FieldBinding requestCardholder verification request
deviceIDID assigned to the device-
deviceIndexReference to the device-
reasonCodeTOKEN_DEVICE_BINDINGCARDHOLDER_STEPUP
lifeCycleTraceIDUnique ID that tracks the requestUnique ID that tracks the request
* Mastercard adds the following data compared to a verification for a Tokenization flow:
FieldBinding requestCardholder verification request
authenticationCorrelationIdUnique ID that tracks the requestNot applicable
### Next steps * For device binding, see [Token binding](/tokenization/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only/device-binding-flow.md). * For cardholder verification, see [Cardholder verification flow](/tokenization/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/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only.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.