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

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.

Because ID\&V is performed in real time, do not use customer service as an ID\&V method. Mastercard does not support this method.

Across payment networks, the issuer should support the following ID\&V methods when available:

| ID\&V method types | Visa                 | Mastercard                                            |
| ------------------ | -------------------- | ----------------------------------------------------- |
| `cell_phone`       | Same as tokenization | Same as tokenization                                  |
| `email`            | Same as tokenization | Same as tokenization                                  |
| `push`             | Not applicable       | See details below                                     |
| `bank_app`         | Same as tokenization | Same as tokenization + push trigger mode is available |

Mastercard supports two additional methods that apply only to post-tokenization authentication:

* `push`: The issuer sends an OTP in a push message that opens the issuer application. The issuer must add this new type in the list of ID\&V methods to use in case of step-up. 
* `bank_app`: The issuer can send a push message that opens the issuer application. No OTP is generated. To support this method, the issuer must add the type `bank_app` in the list of ID\&V methods to use and then assign to the `value` = PUSH\_NOTIFICATION.

These methods improve the interaction between the merchant and the end user.


---

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