> 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.md).

# Token verification

The token verification flow applies to tokens created for card-on-file (COF) or e-commerce use.

In this case, the token is usually created without additional verification beyond basic card validation. The token is stored by the TSP rather than provisioned to a device.

A merchant can trigger token verification to increase the trust level of a token.

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**

There are two token verification request types:

1. **Bind a token to a device or passkey**. Because the e-commerce token is cloud-based, binding lets the merchant use device capabilities to secure token transactions and limit token use to a specific device. This increases the trust level of the token.
2. **Request cardholder verification**. An end user logged in to a merchant app or website may perform sensitive actions, such as changing an email address or password. If the account has stored payment methods, the merchant can request cardholder verification to confirm that the end user is the cardholder (***NOTE**: <mark style="color:red;">this is not yet supported by Mastercard</mark>*).

In both cases, the issuer backend returns a decision, as it does for a tokenization request:

* `green`: approve
* `yellow`: approve with step-up authentication
* `red`: decline

The following table summarizes the effect of each decision for each request type:

| Decision                                       | Binding request                                                                                                                                                    | Cardholder verification request                                                                                                                               |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `green` — approve                              | The merchant associates the payment token with the device.                                                                                                         | The merchant treats the result as confirmation of the cardholder identity and approves the requested account change.                                          |
| `yellow` — approve with step-up authentication | The merchant presents the supported ID\&V methods to the end user. The merchant performs no association until it receives confirmation of the verification result. | The merchant presents the supported ID\&V methods to the end user. The merchant performs no action until it receives confirmation of the verification result. |
| `red` — decline                                | The merchant performs no association.                                                                                                                              | The merchant performs no action.                                                                                                                              |

If the decision is `yellow`, the issuer must provide the list of ID\&V methods that can authenticate the cardholder.

Across the payment networks, the issuer should support at least the ID\&V methods that are in common, to ease the integration:

| ID\&V method types | Visa                 | Mastercard           |
| ------------------ | -------------------- | -------------------- |
| `cell_phone`       | Same as tokenization | Same as tokenization |
| `email`            | Same as tokenization | Same as tokenization |
| `bank_app`         | Same as tokenization | Same as tokenization |


---

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