> 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/click-to-pay/get-started/overview/click-to-pay-ux-examples.md).
# Click to Pay UX examples
This page provides Click to Pay UX examples to help you design issuer journeys that correctly integrate the D1 API and Click to Pay scheme APIs.
These examples are not exhaustive. They highlight common, recommended flows that you can adapt to your issuer application and online banking website.
For technical details, see [Implement Click to Pay](/click-to-pay/implement-click-to-pay-issuers.md).
## Design checklist
Use this checklist when designing Click to Pay experiences in your issuer application or online banking website:
* **Make the value clear.** Explain how Click to Pay improves checkout (for example, faster checkout and less data entry) before asking the end user to enroll.
* **Offer consistent entry points.** Provide enrollment entry points from new card onboarding, existing card management, and card settings, not only from campaign banners.
* **Reuse existing authentication.** Use your standard SCA and ID\&V methods and avoid introducing new authentication mechanisms just for Click to Pay.
* **Keep flows short.** Minimize the number of screens and required fields. Collect only the data required by Click to Pay and your regulatory context.
* **Handle missing data gracefully.** If data is missing, guide the end user to complete it in a single, well-structured flow before calling the enrollment API.
* **Be transparent about opt-out.** Clearly explain how to opt out and what happens to Click to Pay data, and offer a simple way to re-enroll.
* **Support accessibility and localization.** Use clear language, readable contrast, and localized copy for all Click to Pay messages and consent screens.
## When to use each flow
Use the flows on this page in the following situations:
* **Click to Pay enrollment during new card request**: when the end user is requesting or activating a new card and you want to offer Click to Pay as part of the onboarding experience.
* **Request missing end-user details before Click to Pay enrollment**: when the end user's existing card is eligible for Click to Pay but mandatory data (for example, email address or mobile phone number) is missing or incomplete.
* **Update Click to Pay profile details**: when the end user wants to change details that affect their Click to Pay profile, such as contact details or billing address, typically from card or profile settings.
* **Click to Pay opt-out**: when the end user wants to stop using Click to Pay for a given card or profile, or when you must provide an opt-out mechanism for compliance or support reasons.
## Click to Pay enrollment during new card request
When an end user requests a new card, it is an ideal moment to collect the data required to enroll the card in Click to Pay. For technical integration details, see [Enroll cards in Click to Pay](/click-to-pay/implement-click-to-pay-issuers/enroll-cards-in-click-to-pay.md).
{% stepper %}
{% step %}
#### Collect end-user details and T\&Cs
* Display fields to collect all Click to Pay–required details during the new-card request flow (for example, email address and mobile phone number).
* If any details are missing, require the end user to provide them in the issuer application or online banking website.
* Display the latest terms and conditions, including Click to Pay–specific terms, and capture explicit acceptance.
{% endstep %}
{% step %}
#### Authenticate the end user
* After collecting required data and T\&Cs acceptance, authenticate the end user (for example, using SCA via your usual ID\&V method).
{% endstep %}
{% step %}
#### Call the Click to Pay enrollment API
* Once the data is collected and the end user is authenticated, call the [Click to Pay enrol API](/click-to-pay/integrate-the-d1-api/d1-api-summary.md).
* The payment network then creates the Click to Pay digital card, and the end user can use the card at merchants that support Click to Pay.
**Notes**
* If you prefer to enroll the card only after the physical card is activated, call the API after the end user activates the card.
{% endstep %}
{% endstepper %}
## Request missing end-user details before Click to Pay enrollment
For existing cards, you can call the Click to Pay enrollment API as soon as all required end-user details are available. If some details are missing, collect them in the issuer application or online banking website before enrolling the card. For implementation options, see [Enroll cards in Click to Pay](/click-to-pay/implement-click-to-pay-issuers/enroll-cards-in-click-to-pay.md).
{% stepper %}
{% step %}
#### Notify the end user and request missing data
* Notify the end user (for example, with a push notification or in-app banner) and prompt them to provide the missing Click to Pay–required data.
{% endstep %}
{% step %}
#### Authenticate and enroll
* After the end user confirms the details and successfully authenticates, call the [Click to Pay enrol API](/click-to-pay/integrate-the-d1-api/d1-api-summary.md).
{% endstep %}
{% step %}
#### Manage terms and conditions
* If updated terms and conditions are required, display them and capture acceptance in the same flow, immediately after collecting the missing details.
{% endstep %}
{% endstepper %}
## Update Click to Pay profile details
End users may need to update details linked to their Click to Pay profile. You do not need to store all details locally: you can use the Click to Pay view profiles API to retrieve the full data held by the payment network. For the full API flows, see [Retrieve Click to Pay profiles](/click-to-pay/implement-click-to-pay-issuers/retrieve-click-to-pay-profiles.md) and [Update Click to Pay profiles](/click-to-pay/implement-click-to-pay-issuers/update-click-to-pay-profiles.md).
{% stepper %}
{% step %}
#### Retrieve the existing profile
* Use the [Click to Pay get consumer profiles API](/click-to-pay/integrate-the-d1-api/d1-api-summary.md) to retrieve the end user's full profile and display the relevant details in the issuer application or online banking website.
{% endstep %}
{% step %}
#### Allow the end user to edit details
* Allow the end user to update the necessary fields in your experience (for example, email address or billing address).
* After the end user approves the changes and successfully authenticates, call the relevant update APIs.
APIs to use:
* Click to Pay update consumer ([API summary](/click-to-pay/integrate-the-d1-api/d1-api-summary.md))
* Click to Pay update card ([API summary](/click-to-pay/integrate-the-d1-api/d1-api-summary.md))
{% endstep %}
{% endstepper %}
## Click to Pay opt-out
End users must be able to opt out of Click to Pay at any time via the issuer application or online banking website. For technical details, see [Click to Pay opt-out API](/click-to-pay/integrate-the-d1-api/d1-api-summary.md).
{% stepper %}
{% step %}
#### Offer an opt-out option
* Provide a clear opt-out option in the issuer application or online banking website, and ask the end user to confirm the action.
{% endstep %}
{% step %}
#### Authenticate and call the opt-out API
* After confirmation and successful authentication, call the [Click to Pay opt-out API](/click-to-pay/integrate-the-d1-api/d1-api-summary.md) to send the request to the payment network.
{% endstep %}
{% step %}
#### Define the post–opt-out experience
* After opt-out, you may still display the previously provided Click to Pay details in a read-only state.
* Optionally, provide a simple way for the end user to opt back in and re-enroll the card in Click to Pay.
{% endstep %}
{% endstepper %}
---
# 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/click-to-pay/get-started/overview/click-to-pay-ux-examples.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.