Conceptos de D1

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

End user

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

In the D1 API, an end user maps to the consumer resource.

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.