> 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/manage-cards/card-issuance-models.md).

# Card issuance models

## Card issuance models

D1 supports two card issuance models:

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

Once the card exists in D1—either through creation or registration—you can use D1 card services such as Tokenization, Push Provisioning, and Secure Card Display. You can also configure D1 to participate in payment authorization according to the authorization workflow defined on the card product:

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

### Prerequisites

Before you create or register a card in D1, make sure that:

* A **card product** is configured in D1 with the help of the Thales delivery team. The card product is identified by a unique `cardProductId`.
* The **end user** who owns the card is registered in D1.

### Card creation model

In the card creation model:

* D1 is responsible for creating the card.
* D1 allocates the PAN, expiry date, and other card attributes.
* D1 can optionally synchronize the card credentials with the issuer's CMS.

Choose this model when you want D1 to own the full card creation process while keeping your CMS synchronized.

### Card registration model

In the card registration model:

* The issuer's CMS is responsible for creating the card.
* The issuer then registers the existing card in D1 through the registration APIs.
* D1 stores the card credentials received from the issuer.

Choose this model when your CMS remains the system of record for cards and D1 acts as the digital enablement.

### Account configuration

As part of card creation or registration, D1 needs to know the list of accounts linked to the card whenever D1 is expected to perform fund checks during authorization (for example, in the **authorization orchestration** workflow). D1 uses these accounts to query the Core Banking System (CBS) for available funds.

Each account is defined by the following elements:

* **`default`**: Set to `true` if this is the default account for the 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 CBS.
* **`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:

```
GET https://docs.payments.thalescloud.io/click-to-pay/get-started/manage-cards/card-issuance-models.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.