62. Tokenisation

‘Who will save the card’ has been the burning question since RBI issued PA/PG guidelines in Mar’20. As per the guidelines, Payment Aggregators (PAs) and merchants cannot store or vault the cards. Few PAs interpreted the guidelines as per their own convenience… Few decided to vault cards with acquiring banks and one PA wanted to vault cards with ACS provider.

Finally, on 7th Sept 2021, RBI clarified its guidelines about card… And the way forward is Tokenization. [Note: Deadline for tokenization is extended from initial 31-Dec-2021 to 30-Jun-2022 to 30-Sep-22]

Tokenization is not new… not even to us in India. RBI has drafted the first guidelines on Tokenization in Jan’19. Yes, long ago.

Basics:

Before we cover Tokenization, let’s cover some basics about Card on File/card vault/save card (For details, please read this article)

Save Card/Card Vault is a useful feature where the user can save a card (by giving consent: Explicit or implicit) by completing a successful transaction. And the customer doesn’t have to take the trouble of entering the card number for subsequent transactions (Shown below).

Illustration: Save Card transaction

Entities that can save cards: Any company who is PCI-DSS compliant can save the card.

• Merchant
• Payment Aggregator (Either have merchant wise card vault or generic card vault that can be shown across merchants)
• Wrapper (e.g. Juspay)
• Payment Containers (E.g. PhonePe, AmazonPay)

Card on file has its own special value among the payments ecosystem participants as shown below:

For long time, the save card was working fine. Then why did the RBI want to change it? Ans: Customer data safety (standard answer).

Yes, it does make sense to safeguard customer’s data from bad actors, both within and outside the payment ecosystem. Also, card compromise incidents (Here and Here) might have strengthened RBI’s belief that the existing mechanism is not sufficient.

Back to main topic — Tokenization

“Tokenization is the process of replacing a card’s primary account number (PAN) — the 16-digit number on the plastic card — with a unique alternate card number, or “token.” Tokens can be used for mobile point-of-sale transactions, in-app purchases or online purchases.” (Source: MasterCard)

Tokenization provides a secure and safe way of doing transactions and thus, lower fraudulent transactions.

Types of Tokenization:

We are more interested in Card on File Tokenization (CoFT) as it has a bigger impact on the entire ecosystem.

Here are guidelines of CoFT.

Participants:

• Token Issuance Platform: Usually card networks who work with issuing banks to provide platform
• Token Requestor: Entities that are certified (CERT and PCI-DSS) to integrate with Token Issuance Platform. These entities can be Acquiring Banks, Payment Aggregators, Payment Containers, Wrapper and merchants (yes, a merchant can be TR if it makes sense to that effort)

Transaction:

That won’t change much except that the customer has to provide explicit consent for tokenization. A merchant/PA cannot force or take it implicitly.

Illustration: Tokensation

If a customer doesn’t prefer to be part of this tokenization process, he/she can still do regular transactions by entering a 16 digit card number.

Impact:

If you are a merchant, then you will have to think about the same strategy that you thought while opting for the ‘save card’ feature.

1. Become Token Requestor: Yes, it is hard work but you will be agnostic to any PA or acquiring bank
2. Use one Payment Aggregator: Then you are locked in with that PA (as Tokens are bound with card, merchant and Token Requestor ie. your PA)
3. Wrapper: User wrapper (e.g. Juspay) but overall your cost will be higher

Interesting Cases:

A. Payment Containers:

PhonePe allows its users to save cards (implicit consent case) and users can make payments using those cards either on PhonePe App (e.g. Bill payment) or even at merchants (e.g. Swiggy or Urban Company).

RBI guidelines mentions that tokenization should be binding among cardholder, merchant and token requester. And initiation for tokenization should be done by the merchant.

• If I am doing a transaction on Swiggy using a card on PhonePe , does PhonePe become a merchant or Swiggy?
• Can PhonePe do generic Tokenization of cards on its platform that can be used on any merchant (internal as well as external)?

B. Payment Aggregator’s common card vault:

Payment Aggregators (RazorPay, CC Avenue) offer a generic card vault where customers can vault cards one time and can be accessed on any merchant (just validate OTP to retrieve stored cards). As per the guidelines, this model is not allowed. So can payment aggregators continue with such generic features?

C. Instant Refunds

Few of the PAs offer ‘instant refund’ on selected credit cards (scheme and banks). These PAs either (a) have integration with selected issuing banks or (b) simply use IMPS/NEFT to push the funds to the credit card.

Both scenarios involve, using 16 digit card number… with new guidelines, PAs cannot see 16 digit card number so ‘instant refund’ solutions that are based on IMPS/NEFT cannot be done.

D. Credit Card Repayment:

Credit card repayment Apps (Cred, Amazon) use IMPS and NEFT rails to push funds to 16 digit card numbers. (Basically, a card number is like a bank account number and every issuer has an IFSC). But RBI guidelines explicitly forbids viewing/using 16 digits card numbers. So how will they push funds using IMPS/NEFT?

Visa Direct and Master Money Send can be alternative options but these rails are expensive as well as have longer TAT for fund credit.

So these credit card repayment companies have to reinvent their model.

Card networks announced their readiness for Tokenisation. Few PAs & Wrapper are also ready with a solution. If we have to go by the experience of mandate on cards, I was expecting a lot of last moment confusions. (wait for it….)

RBI’s extension of 6 months has given some breathing space to all participants (card networks, issuing banks, Payment aggregators and merchant). If I have to go by typical human behaviour, the ecosystem participants will use this breathing space to breathe and then start rushing up things only couple of weeks for deadline.

But meanwhile, there are other confusions to deal with: There are merchants who were already started migrating cards to tokenisation… but now, they will have to maintain two flows — one with tokenisation and one on earlier flow until all cards are moved to tokenisation… uff… such a messy thing to deal with…

But again, what is the point if ‘digital payments’ are not complex, dynamic and messy!