> 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/get-started/overview.md).

# Overview

D1 orchestrates the **Tokenization** flows with payment network **TSPs** on behalf of the issuer, simplifying the integration effort of the issuer towards the different TSPs available in the market.

The orchestration is possible thanks to the fact that the issuer registers the consumers and cards data in D1, see the following sections for details.

### Which payment networks supports D1?

D1 supports Tokenization through the TSPs of the following payment networks:

* American Express
* Mastercard
* Visa

### What is Tokenization?

**Tokenization** is defined by [EMVCo](https://www.emvco.com/emv-technologies/payment-tokenisation/). It replaces a card’s **PAN** (also called the **FPAN**) with a payment token (a **DPAN**) for use in a digital channel.

A Tokenization flow is always initiated by a **token requestor**—for example:

* **xPay Wallets** (such as Apple Pay, Google Pay, and Samsung Pay)
* An e-commerce merchant

### Tokenization flow

Tokenization in D1 is split into three main steps:

{% stepper %}
{% step %}

### Check card eligibility

D1 verifies that the card is eligible for Tokenization.

A card is eligible when the issuer has provided the required card-product metadata (such as card artwork and terms and conditions) to the payment network TSP.

To support this check, the issuer must provide D1 with the mapping between:

* The card product **BIN** range
* The card product identifier used by the payment network TSP

For details, see [Check card eligibility](/tokenization/implement-tokenization/check-card-eligibility.md).
{% endstep %}

{% step %}

### Process the Tokenization request

If the card is eligible, D1 decides whether to approve or decline the Tokenization request.

D1 evaluates data from:

* The card and end-user data available in D1 (or retrieved from your issuer backend, depending on your integration model)
* The token requestor (device and wallet signals provided through the TSP)

Depending on the outcome, D1 can:

* Approve
* Decline
* Approve with **step-up authentication**

For details, see [Processing the decision](/tokenization/implement-tokenization/card-tokenization-request/processing-the-decision.md).
{% endstep %}

{% step %}

### Complete Tokenization

Based on the decision, the payment network TSP provisions the **DPAN** (digital card) to the token requestor.

* For an approval, the digital card can be activated and used.
* For a decline, no digital card is provisioned.
* For step-up authentication, the end user must complete an additional authentication step before activation.

In all cases, D1 notifies the issuer backend with the Tokenization outcome.

For details, see [Processing the response](/tokenization/implement-tokenization/card-tokenization-request/processing-the-response.md).
{% endstep %}
{% endstepper %}

### After Tokenization

After Tokenization completes, the issuer can perform additional operations, including:

* Retrieve Tokenization data (for example, digital card credentials and token requestor characteristics). See [Tokenization data retrieval](/tokenization/implement-tokenization/post-tokenization-requests/retrieve-tokenization-data.md).
* Perform **LCM** operations on digital cards (for example, suspend, resume, or delete). See [Digital card life cycle](/tokenization/implement-tokenization/post-tokenization-requests/life-cycle-management/digital-card-life-cycle.md).

{% hint style="info" %}
Tokenization is a server-to-server solution that uses the **D1 API**.

If your step-up authentication includes an in-app flow, you can optionally use the **D1 SDK** in the issuer application. See [In-app authentication backend](/tokenization/implement-tokenization/card-tokenization-request/processing-the-response/approve-with-step-up-authentication/in-app-authentication-with-issuer-backend.md).
{% endhint %}

### Example end-user experience

The following example shows an end-user experience for Tokenization with approval and **OTP** step-up authentication:

<figure><img src="/files/c0T1QbVkyMRvjTs1BqNj" 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/tokenization/get-started/overview.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.