> 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/home/card-creation-and-management/get-started/d1-concepts.md).

# D1 concepts

D1 supports multiple data model configurations. This page defines the core entities and identifiers you use across D1.

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

## End user

An **end user** is a person who owns one or more cards. The end user is the issuer’s customer.

{% hint style="info" %}
In the D1 API, an end user maps to the `consumer` resource.
{% endhint %}

In D1, an end user is identified by a `consumerId` that is:

* Used across the D1 API, D1 SDK, and D1 portal.
* Defined by the issuer and unique within D1.

D1 does not create end users. The issuer registers each end user in D1 to create cards and links to them.

The `consumer` resource stores end user details such as email address, first name, postal address, etc...

## Card

A card is always linked to exactly one end user. An end user can have multiple cards.

In the D1 API and D1 SDK, a card is identified by a `cardId`. The identifier is defined by the D1 at card creation time.

The `cardId` has no direct link to the PAN. It is not cardholder data for PCI DSS scoping.

D1 supports two major card form factor:

* **Physical card**
* **Virtual card**

The same user can hold one or several physical card and virtual card..

### Physical card

A physical card supports e-commerce and in-store payments.

### Virtual card

A virtual card supports e-commerce payments exclusively. You can display it in the issuer application.

A virtual card contains a PAN, CSC (or CVV2), and expiry date.&#x20;

D1 lets the issuer application display these values securely so the end user can pay online.

A virtual card can exist without a physical card.

### Card issuance model

D1 handle the **Card creation** by allocating the PAN, expiry date, and other credentials.&#x20;

D1 can optionally synchronize these credentials with the issuer’s CMS upon adhock integration.

Once the card exists in D1, the card can be activated for :

* Tokenization,&#x20;
* Wallet push provisioning (Google Pay, Apple Pay), Click to Pay
* Payment Authorization,&#x20;
* 3DS flow
* Fraud Verification
* Clearing Processing
* Dispute and chargeback management&#x20;

Before you create a card, make sure that:

* A **card product** is configured in D1 during D1 onboarding with the Thales delivery team.
* The **end user** is registered in D1.

## Digital card

In D1, a digital card is an EMV token. It is created through Tokenization initiated by a token requestor (for example, xPay Wallets or an e-commerce merchant). Payment network TSPs (for example, MDES or VTS) orchestrate the process.

The original card can be virtual or physical. D1 supports Tokenization and LCM from the issuer backend or issuer application.

In the D1 API, a digital card is identified by a `digitalCardId`. The payment network defines this identifier. D1 returns it to the issuer.

## Card product

In D1, every card is linked to a card product.&#x20;

A card product defines:

<figure><img src="/files/2sFb9nDvOcu5XqjrulB1" alt=""><figcaption></figcaption></figure>

You define card products during D1 onboarding with the Thales delivery team.

Each card product is identified by a unique `cardProductId`.

For more advanced card product, Thales offer ad hock configuration service to extends existing blueprint card product profile.

## Account

An account is identified in D1 by an account identifier (for example, n`umber`) that is:

* Used across the D1 API, D1 SDK, and D1 portal.
* Defined by the issuer and unique within D1.

D1 supports multiple card-to-account models:

* A card can link to one or more accounts.
* An account can link to multiple cards.

D1 does not create accounts. The issuer provides the `number`  at the card creation time.

During payment authorization, D1 uses these links to select the account to check funds against. Selection can depend on criteria such as the account currency, mcc, etc...&#x20;

D1 can use these accounts to query the Ledger Management System for available funds.

Each account is defined by the following elements:

* **`default`**: Set to `true` if this is the default account for the given card.
* **`type`**: The account type. D1 supports `CHECKING` and `SAVING`.
* **`number`**: The account number that D1 uses to reference the account when checking funds with the Ledger Management System.
* **`currencyCode`**: The currency of the account.


---

# 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/home/card-creation-and-management/get-started/d1-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.