> 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/3d-secure/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="/spaces/62lLFDcmLCeqqwmy4Fee/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 and links them to cards.

The `consumer` resource stores end user details such as email address and first name.

## 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 issuer defines this identifier.

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

D1 supports two card types:

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

You can have both types for the same end user.

### Physical card

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

### Virtual card

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

A virtual card contains a PAN, CSC (or CVV2), and expiry date. 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 supports two issuance models:

* **Card creation model**: D1 creates the card and allocates the PAN, expiry date, and other credentials. D1 can optionally synchronize these credentials with the issuer’s CMS.
* **Card registration model**: The issuer creates the card in its CMS and then registers the existing card and credentials in D1.

Once the card exists in D1, you can use D1 services such as Tokenization, Push Provisioning, and Secure Card Display. You can also configure D1 to participate in payment authorization based on the workflow configured on the card product:

* **Authorization orchestration**: D1 orchestrates the complete authorization process.
* **Transaction control**: D1 performs a subset of authorization checks.
* **No authorization mode**: D1 does not participate in authorization.

Before you create or register 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. A card product defines:

* Card type (virtual or physical)
* PAN range
* Default settings and characteristics

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

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

## Account

An account is identified in D1 by an account identifier (for example, `accountNumber`) 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 registers account links when creating cards.

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. D1 can use these accounts to query the Core Banking system (CBS) for available funds.


---

# 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:

```
GET https://docs.payments.thalescloud.io/3d-secure/get-started/d1-concepts.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.