> 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/central-issuance/implement-central-issuance/card-order/chip-personalization.md). # Chip personalization

Chip personalization integration models (Issuer backend responsibilities vs. D1 responsibilities).

D1 supports EMV chip personalization for physical card personalization. Choose one of two integration models: * **Model 1 (recommended):** The **Issuer backend** sends minimal inputs. D1 computes the EMV dataset. * **Model 2:** The **Issuer backend** sends a prepared EMV dataset. D1 validates and loads it. ### Standard profiles D1 supports the following standard chip profiles: * **Visa product (global):** Dual-interface Visa debit/credit cards — VIS 1.6.3 and VCPS 2.2.4. * **Visa product (US only):** VIS 1.5.4 and VCPS 2.1.3. * **Mastercard product:** M/Chip Advance 1.2.3 (no data storage). {% hint style="info" %} If you need a profile not listed here, contact the Thales delivery team. {% endhint %} ### Choose an integration model Use **Model 1** if you want D1 to build the EMV tags and values from minimal inputs. Use **Model 2** if your **Issuer backend** must control the full EMV dataset (for example, when you generate EMV tags in your CMS). ### Model 1: D1 computes EMV data In this model, D1 computes the EMV data based on your raw inputs and the configuration set up in D1. #### Inputs used for personalization Required D1 API inputs: * `cardProductId`: Card product identifier configured during D1 onboarding. * `encryptedData.pan`: Primary Account Number (PAN). * `encryptedData.exp`: Expiry date, typically `YYMM`. * `paymentApplication.config`: Selected payment application configuration containing predefined EMV tags and values. * `paymentApplication.odaKeyIndex`: ODA key index used for the profile. * `paymentApplication.derivationKeyIndex`: Derivation key index used to select the EMV Master keys to be used for ICC Keys computation. Optional D1 API inputs: * `encryptedData.encodedName`: End user name, pre-encoded when required by your profile. If omitted, D1 attempts to derive it from `trackData.track1` (when present). * `encryptedData.paymentAccountReference`: Payment Account Reference (PAR), when applicable. * `encryptedData.panSequenceNumber`: PAN sequence number, when applicable. If omitted, D1 sets it to `00`. * `encryptedData.effectiveDate`: Card effective date, when applicable. If omitted, D1 sets it to the personalization date. * `encryptedData.pin`: PIN block to load on the chip. If omitted, D1 generates a random PIN (when configured). * `type` (Required): Encrypted PIN block format. Supported values: `ISO0`, `ISO0TK`, `ISO4`. * `encryptedPin` (Required): Encrypted PIN block in the format defined by `type`. * `kid` (Required): Transport-key version used to encrypt the PIN block. Conditional D1 API inputs: * `encryptedData.icvv`: Integrated card verification value (iCVV), when applicable. If omitted, D1 computes it using CVK. * `paymentApplication.cvKeyIndex`: CVK index used when computing `icvv`. {% hint style="warning" %} Never send a clear PIN in D1 API requests. {% endhint %} #### Configuration in D1 The following configuration is done during D1 onboarding: * Your card product is configured to use the appropriate **electrical profile** (Visa or Mastercard). * The key indexes you send (`paymentApplication.odaKeyIndex`, `paymentApplication.derivationKeyIndex`) are configured and available for your program/BIN. {% hint style="info" %} Send **key indexes only**. Do not send cryptographic key material in API requests. {% endhint %} ### Model 2: Issuer backend provides EMV data In this model, the Issuer backend performs EMV data preparation and sends the resulting chip dataset. D1 validates the data and loads it on the chip. #### Inputs used for personalization Required D1 API inputs: * `cardProductId`: Card product identifier configured during D1 onboarding. * `encryptedData.pan`: Primary Account Number (PAN). * `encryptedData.exp`: Expiry date, typically `YYMM`. * `encryptedData.tlvData`: Prepared EMV dataset in the format expected by your selected profile. * `appletAid`: Application identifier (AID). * `appletDataLength`: Application size. * `appletStartCode`: Application start code. * `tlvDataLength`: TLV data length. * `kekId`: Version of the key used to encrypt the dataset. * `macKey`: MAC key encrypted under the encryption key. * `tlvData`: EMV data elements in TLV format, encrypted by the KEK. * `mac`: MAC computed on the `tlvData` block before encryption. {% hint style="warning" %} Treat `tlvData` as sensitive card data. Do not log it or expose it to the end user. {% endhint %} #### Configuration in D1 * Your card product must still be configured with the correct standard profile. * D1 validation rules apply; invalid or inconsistent EMV data is rejected. --- # 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/central-issuance/implement-central-issuance/card-order/chip-personalization.md?ask= ``` 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.