> 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/cardholder-verification-flow.md).

# Cardholder verification flow

The merchant triggers this flow when the end user requests a sensitive operation that may use the associated payment instruments.

For example, this flow can apply when the end user updates details such as an email address. The email address can serve as a unique ID when the end user logs in to the merchant website.

D1 receives the request through the corresponding TSP and manages the flow. The issuer backend does not need new APIs or workflows.

For these requests, D1 systematically requires step-up authentication and returns the list of ID\&V methods that the issuer supports.

The following sections provide detailed diagrams.

### Sequence diagrams

The following sequence diagrams show the full flow orchestrated by D1 and the level of involvement of the issuer backend.

{% hint style="warning" %}
This use case is not yet supported by Mastercard.
{% endhint %}

<figure><img src="/files/4iLqQDuV90Ftgn4K2GrQ" alt=""><figcaption><p>Overview of the cardholder verification flow.</p></figcaption></figure>

For ID\&V method prerequisites, see [Prerequisites for ID\&V methods](/tokenization/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only.md#prerequisites-for-id-and-v-methods).

#### OTP verification by SMS or email

The following sequence diagram depicts the flow when the end user chooses SMS or email OTP as the verification method:

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

If the issuer backend manages OTP delivery, it can use the `otp.reason` field to distinguish this request from a Tokenization request. It can use `deliveryChannel` to determine the message type:

* `otp.reason` = `CARDHOLDER-VERIFICATION`
* `deliveryChannel` = `SMS` or `EMAIL`

#### Verification by the issuer application

The following sequence diagram depicts the flow when the end user selects the issuer application as the verification method:

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

As described in the [High-level flow](/tokenization/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only.md#high-level-flow) section, the issuer backend must account for the integration required in step `[02]`. The shared data depends on the TSP. Compared with a Tokenization flow, use the following mapping to populate `StepupAuthenticationResult` correctly:

<table><thead><tr><th width="228.45458984375">D1</th><th>Visa</th></tr></thead><tbody><tr><td><code>authenticationId</code></td><td><code>lifeCycleTraceID</code></td></tr></tbody></table>

{% hint style="info" %}
**Unsuccessful result**

`StepupAuthenticationResult` supports a `failed` verification result for forward compatibility. However, Visa does not provide a dedicated interface to report an unsuccessful result.

If verification fails, Visa recommends suspending the token.

Suspending the token might cause the end user to contact customer service or lead the merchant to delete the token.
{% 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/tokenization/implement-tokenization/post-tokenization-requests/update-the-digital-card-assurance-method-e-commerce-only/cardholder-verification-flow.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.
