Card on File Tokenization (CoFT)

Problem Statement:

As a customer, whenever you saved your card in the early days, merchants used to save this data in an encrypted format and use it whenever you visited the merchant website again. But in the past, there have been many instances of data theft.

Solution:

RBI proposed a solution to tokenize card details so that the original card information cannot be used. RBI mandated that no one apart from the issuer and card network can store the data. Not only this, they also required all existing card details to be deleted.

Who can Create the Token:

It is formally referred to as the TSP (Token Service Provider). A TSP can either be the card network (Visa, Mastercard, Amex, Diners, etc.) or the issuer. The most commonly used TSP currently is the card network.

Storing of the Card Details (Original PAN):

Apart from the card network and the issuer, no one in the payment chain is allowed to store the original card number (PAN).

Token Provisioning:

You visited Amazon.in (the merchant website) and are currently on the payment page. 

If you choose to make the payment using your credit card, you will see a checkbox labelled "𝘚𝘢𝘷𝘦 𝘊𝘢𝘳𝘥 𝘢𝘴 𝘱𝘦𝘳 𝘙𝘉𝘐 𝘨𝘶𝘪𝘥𝘦𝘭𝘪𝘯𝘦𝘴." As soon as you give your consent, the token provisioning process begins.

Suppose Amazon.in has integrated a payment gateway such as Paytm, Razorpay, or Juspay. In that case, these payment gateways (PAs) or payment aggregators (PAs) can act as the Token Requester (TR).

Who is Token Requester? The Payment Gateway or Payment Aggregator integrated with Amazon.in which orchestrates the full payment lifecycle for Amazon (the merchant).

TR Token Requestor will send a Token Provisioning request to the TSP. 

The token service provider, which is also the Card Network, sends a message and required details to the card issuer who decides to either approve the tokenization, ask for additional authentication or declines the request.

The token service provider and the card issuer work together to complete any additional cardholder authentication. This might include sending you a one-time passcode, or OTP.

All of this happens in seconds and is mostly invisible to you.

Once the tokenization request is approved, and following any further authentication checks, the token service provider stores the card data and keeps it up to date (even if certain card details change, like the expiration date when you receive a new card), provides the merchant with a Unique Identifier to be stored against the Saved Card.

Stepwise Flow:

1/ You visited Amazon.in (the merchant website) and are currently on the payment page. 

2/ If you choose to make the payment using your credit card, you will see a checkbox labeled "𝘚𝘢𝘷𝘦 𝘊𝘢𝘳𝘥 𝘢𝘴 𝘱𝘦𝘳 𝘙𝘉𝘐 𝘨𝘶𝘪𝘥𝘦𝘭𝘪𝘯𝘦𝘴." As soon as you give your consent, the token provisioning process begins.

3/ Suppose Amazon.in has integrated a payment gateway such as Paytm, Razorpay, or Juspay. In that case, these payment gateways (PAs) or payment aggregators (PAs) can act as the Token Requester (TR).

4/ TR will send a Token Provisioning request to the TSP. 

5/ The TSP will create the token. (To create and activate the token, a request is sent to the issuer for card verification and authentication.) The authentication takes place using the 3D Secure method. To learn more about 3D Secure, read this article: 3D Secure Transaction Flow

6/ Once the token is activated, the TSP returns a unique identifier to the TR.

7/ TR sends this unique identifier to the merchant, and the merchant stores this unique identifier in a file at a secure location.

This is called Card on File Tokenization (COFT). To learn how it differs from Guest Checkout, visit the article below.

[a] LinkedIn: LinkedIn Post on Guest Checkout - Alt ID

[b] Blog Article: Guest Checkout - Alt ID Blog

Now lets understand the Transaction flow using COFT

Token Retrieval

Now, this is the flow of Token Retrieval.

When Token will be retrieved? When you attempt to make a purchase using your saved card as a returning customer or in the first time when you clicked on the checkbox and at the same time you continued to make the purchase.

Remember, merchant stored a unique identifier against your saved card in previous slide.

The same Unique Identifier will be used here to retrieve the token from the Token Service Provider. Otherwise you say, how Token Service Provider will come to know which token they need to send back, because merchant cant send the actual Card Number or PAN.

This is why Unique Identifier was needed.

Once Token Service Provider identifies the Unique Identifier, they return the Token and Cryptogram to the Merchant via Token Requestor. Why Cryptogram? To maintain the integrity, Token Service Provider wrap this Token detail with a Cryptogram.

This way, merchant now have the Token and a unique Cryptogram.

Stepwise Flow:

1/ As soon as you select one of the saved cards on the amazon.in website, the merchant will locate the unique identifier stored against it.

2/ This Unique identifier is sent to the TR for the Token Details.

3/ Now the TR will request to TSP for the Token details.

4/ TSP will retrieve the Token details and sends to TR. But Token Details will not travel alone. To maintain the integrity, TSP wrap this Token detail with a Cryptogram (TAVV).

5/ This Token details with the Cryptogram reaches to the Merchant. Now the Payment Gateway associated with the Merchant will initiate the Authorization Flow using the Token Detail and Cryptogram.

Authorization Flow using Token Detail and Cryptogram:

[a] Now the usual Token flow will take place.

[b] I have intentionally skipped the Authentication flow to make the article simpler. To learn more about Authentication flow, please visit Authentication Flow

Now, Token and Cryptogram travels to the Card Network via Acquirer.

The Token gets decrypted by the Card Network and a clear PAN and Cryptogram is sent to the Issuer for the Authorization.

Issuer validates the PAN and the Cryptogram and decides whether the Auth request to be Approved or Declined.

In either of the case, Clear PAN travels back to the Card network which again replaced by the token and reach to the Merchant via Acquirer and Payment Gateway. 

Stepwise Flow:

1/ Merchant to PG (Request)

- Token + Cryptogram will travel

2/ PG to Acquirer (Request)

- Token + Cryptogram will travel

3/ Acquirer to Card Network (Request)

- Token + Cryptogram will travel

- Based on the Token range, the Acquirer will forward a request to the Card Network

4/ Card Network to Issuer (Request)

- Detokenization will happen

- Using the Cryptogram the sanity and integrity of the ISO message will be verified by the Network

- Token will be replaced with the Clear PAN and Clear PAN will travel to the Issuer

- Authorization request will be sent to the Issuer

5/ Issuer to Card Network (Response)

- Clear PAN will be sent to the Network along with the Issuer decisions

6/ Card Network to Acquirer (Response)

- Token will sent to the Acquirer along with the Issuer's decision

7/ Acquirer to Payment Gateway (Response)

- Token will be sent to PG, who will ultimately pass the info to the Merchant along with the Transaction Authorization result Approved or Declined.  

Disclaimer:

• The process flow diagrams included in this blog are original creations by the author, Neeraj Singh. Any reproduction or use of these diagrams requires prior permission from the author.
• Mentions and images of Amazon, Visa, Discover are the property of their respective organizations and have been sourced from Google search. All rights to these trademarks and logos belong to their respective organizations.