Step 1 – capture card details

First, the end user provides the card details used for Tokenization.

Capture these details using one of these methods:

• Manual entry in the issuer application or digital wallet application

• Optical character recognition (OCR) from a picture of the physical card

• Card details imported from an existing Card-on-file (COF) record

A common approach is to start in the issuer application. This enrollment flow is often called push provisioning or in-app provisioning.

If TSH is configured to support a domestic scheme, check the details domestic scheme treatment.

Push provisioning from the issuer application

The diagram below shows the overall push provisioning flow for card details capture.

Push provisioning flow to capture card details.

In a push provisioning scenario, the Tokenization flow follows the standard “green flow”. It adds an initial step where the issuer application provides two elements to the token requestor (wallet provider), via an SDK or a mobile operating system API:

1. Encrypted card information The issuer application sends encrypted card data (typically the PAN and expiry date).

2. Authentication proof The issuer application sends an authentication proof for the token requestor or the payment network. This demonstrates that the issuer strongly authenticated the end user.

Encryption and authentication proof

• Encryption algorithm The encryption algorithm is specific to each token requestor. The corresponding specification is provided by the token requestor.

• Authentication proof algorithm The authentication proof format and algorithm are specific to each payment network (for example, VTS or MDES). The relevant specifications are provided by the payment network.

CVV2 handling in app-to-app flows

In app-to-app push provisioning flows (step 4 in the diagram), the issuer backend never receives the CVV2. The token requestor collects and handles the CVV2 according to payment network requirements.