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

# Click to Pay concepts

## Click to Pay concepts

This page explains the core Click to Pay concepts and how the D1 Click to Pay service supports issuer-driven enrolment and profile management.

### Click to Pay profile

A Click to Pay profile is the set of data that uniquely identifies the end user (cardholder) and the set of data that identifies their card or cards.

In particular, a Click to Pay profile contains:

* End user details (cardholder):
  * First name
  * Middle name
  * Last name
  * Phone number
  * Email address
  * Language
* Card details:
  * PAN
  * Expiration date
  * Cardholder name
  * Billing address

<figure><img src="/files/2hYq9rccVSbVFj7bOXyg" alt="Click to Pay profile data"><figcaption><p>Example of Click to Pay profile data elements.</p></figcaption></figure>

{% hint style="info" %}
With the exception of the middle name, **all** the data above is **mandatory** to register a profile in a Click to Pay directory.
{% endhint %}

All profile data is stored in the payment network directory. An agreement must be in place between the payment network and the issuer for the processing of this data.

Thales is not involved in this agreement, as the D1 platform does not store the personal data of the end user for Click to Pay profiles.

### Enrolment and checkout

Two main use cases must be considered by participants in a Click to Pay programme:

{% stepper %}
{% step %}
**Enrolment**

Enrolment is the process of creating a Click to Pay profile for the end user in the Click to Pay directory and creating a digital card at the payment network.

The **D1 Click to Pay** service focuses exclusively on the **enrolment** use case.

The **D1 Click to Pay** service exposes the D1 API that allows issuers to enrol and manage end users and cards for Visa and Mastercard.

In particular, the following services are exposed:

* [Enrolment](/click-to-pay/implement-click-to-pay-issuers/enroll-cards-in-click-to-pay.md): enrol an end user profile in the Click to Pay directory.
* [View profile](/click-to-pay/implement-click-to-pay-issuers/retrieve-click-to-pay-profiles.md): retrieve the profile details stored in Click to Pay.
* [Update profile](/click-to-pay/implement-click-to-pay-issuers/update-click-to-pay-profiles.md): update an end user profile.
* [Opt-out](/click-to-pay/implement-click-to-pay-issuers/opt-out-cards-from-click-to-pay.md): delete a card from Click to Pay. This is a definitive operation, but the issuer can re‑enrol the card at a later stage.
  {% endstep %}

{% step %}
**Checkout**

Checkout is the process that allows a merchant to retrieve a Click to Pay profile, present the available payment options (payment credentials) to the end user, and let the end user select a payment option to finalise the purchase.

During checkout, if a profile cannot be identified, the merchant can perform enrolment in parallel with the purchase, since the required data matches the data needed to create a Click to Pay profile.

Even though combined enrolment and checkout are possible, EMVCo considers enrolment a standalone event so it can be managed independently from the checkout process.
{% endstep %}
{% endstepper %}

<figure><img src="/files/wjVpPwRahcEXlLGKqLGP" alt="Enrolment and checkout flows"><figcaption><p>High-level Click to Pay enrolment and checkout flows.</p></figcaption></figure>

{% hint style="info" %}
The Click to Pay directories of the different payment networks are **not** synchronised.

An end user may have cards with different payment networks and, as a result, separate profiles in each Click to Pay directory (for example, one in Visa and one in Mastercard).

If required, it is the issuer’s responsibility to keep **end user details** consistent across profiles stored in the different payment network directories.
{% endhint %}

### User experience

Thanks to systematic **enrolment** performed by the issuer for each end user and each card, payment networks aim to significantly improve the user experience and adoption of Click to Pay.

On the merchant side, integration with Click to Pay is simplified. The merchant or payment service provider (PSP) focuses on retrieving the Click to Pay profile associated with an end user (profile details and payment credentials):

<figure><img src="/files/31FUrrjs0QN8Hj7kuiQ2" alt="Merchant retrieves Click to Pay profile"><figcaption><p>Merchant or PSP retrieves the end user’s Click to Pay profile and payment credentials.</p></figcaption></figure>

Once the Click to Pay profile is retrieved, the merchant can display the information, let the end user select the card to use for the purchase, confirm and reuse the billing address for shipping, and proceed with checkout:

<figure><img src="/files/XGGmtKOIm2GLNN3oiQXy" alt="Checkout with Click to Pay cards"><figcaption><p>Example checkout where the end user selects a card from their Click to Pay profile.</p></figcaption></figure>

On the issuer side, Click to Pay can be managed as a **card product feature**. The issuer can handle "automatic consent" by updating the terms and conditions of the card product, similar to how NFC features are already managed.

<figure><img src="/files/XugEdJpX8LjNnMglbgio" alt="Issuer manages Click to Pay as a card feature"><figcaption><p>Issuer manages Click to Pay as part of the card product’s features and terms.</p></figcaption></figure>

The end user can opt out at any time and later opt back in.

This behaviour should be clearly described in the Click to Pay information provided to the end user, ideally with screenshots showing how to manage Click to Pay settings in the issuer application or on the bank website. This reassures the end user that they are not "trapped" in any unwanted service.

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


---

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