Chip personalization

Understand how D1 produces EMV chip data during physical card 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).

If you need a profile not listed here, contact the Thales delivery team.

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.

Never send a clear PIN in D1 API requests.

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.

Send key indexes only. Do not send cryptographic key material in API requests.

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.

Treat tlvData as sensitive card data. Do not log it or expose it to the end user.

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.