> 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 only)

Use this flow to increase a digital card's assurance level 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 TSP. They are not provisioned to a device.

Merchants typically request token verification before a sensitive action or before they bind 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 app 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 that the end user is the cardholder. *This flow is not yet supported by Mastercard.*

### What D1 does

In both cases, D1 orchestrates the flow on behalf of the issuer. The issuer backend does not need an additional workflow.

The issuer backend only needs to return end user details when requested. D1 then selects the available ID\&V methods on behalf of the issuer.

{% 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 that usually receives initial approval because the card details are valid.
{% endhint %}

### Supported ID\&V methods

If the decision is `yellow`, **step-up authentication** is required. D1 adds the supported ID\&V methods to the decision returned to the payment network TSP.

D1 supports these methods:

* ID\&V using an OTP sent by SMS or email
* ID\&V through the issuer application. This can be 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 message. 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. For the TSP, the same considerations apply as for Tokenization. See [Integrate in-app ID\&V](/tokenization/integrate-in-app-id-and-v-for-xpay-wallets.md).
3. The issuer configuration defined during D1 onboarding includes:
   1. the supported ID\&V methods
   2. if the OBO option is enabled, the SMS and email templates
   3. if the OBO option is not enabled, an implementation of the `Deliver OTP` API

{% hint style="warning" %}
The OBO option must match the Tokenization configuration.

The ID\&V model used for Tokenization also applies to token verification.
{% endhint %}

### High-level flow

The following diagram shows the parties and the main steps in a token verification request:

<figure><img src="/files/lJUzQFbgeFg6SLRkHds0" alt=""><figcaption></figcaption></figure>

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

#### OTP verification by SMS or email

<figure><img src="/files/gIp5TpZ21YwKOkxNZg2T" alt=""><figcaption><p>OTP verification flow by SMS or email.</p></figcaption></figure>

#### Verification by issuer application

<figure><img src="/files/lkXaVDcCVoCFFKy7aSqF" alt=""><figcaption><p>Verification flow through the issuer application.</p></figcaption></figure>

Integration between the merchant application and the issuer application in step 9 is out of scope for Thales.

Use the same scheme guidance that applies to a Tokenization flow. For simplicity, see [Integrate in-app ID\&V](/tokenization/integrate-in-app-id-and-v-for-xpay-wallets.md). The only additional requirement is to handle the extra data that identifies the originating use case.

In particular:

* Visa adds the following data compared with a Tokenization flow:

<table><thead><tr><th width="211.727294921875">Field</th><th>Binding request</th><th>Cardholder verification request</th></tr></thead><tbody><tr><td><code>deviceID</code></td><td>ID assigned to the device</td><td>-</td></tr><tr><td><code>deviceIndex</code></td><td>Reference to the device</td><td>-</td></tr><tr><td><code>reasonCode</code></td><td><code>TOKEN_DEVICE_BINDING</code></td><td><code>CARDHOLDER_STEPUP</code></td></tr><tr><td><code>lifeCycleTraceID</code></td><td>Unique ID that tracks the request</td><td>Unique ID that tracks the request</td></tr></tbody></table>

* Mastercard adds the following data compared with a Tokenization flow:

<table><thead><tr><th width="257.1817626953125">Field</th><th width="275.9090576171875">Binding request</th><th>Cardholder verification request</th></tr></thead><tbody><tr><td><code>authenticationCorrelationId</code></td><td>Unique ID that tracks the request</td><td>Not applicable</td></tr></tbody></table>

### 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=<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.