Tokenization is the next big change that is here to transform online card payments in India. How big you ask? Recall the massive shift that happened in offline transactions when cards were mandated to have EMV chips instead of a magnetic strip? The objective of these shifts remains the same — to prevent fraud from happening in payments.
Card Tokenization is the process of replacing the sensitive static card number (PAN) with a merchant scoped reference called Token. Tokenization helps in strengthening security as customer card numbers no longer need to pass through various payment entities that help process a transaction. The scoping of a token to a single merchant further reduces the risk and impact of fraudulent activity.
These tokens can be used for online transactions (e-comm) as well as offline transactions(NFC). For now, we will focus on online transactions:
Types of E-comm Tokenization
Tokenization can be done either at a Device level or at a Server level.
Device Side Tokenisation
Device side tokenization binds tokens to a device and thus the tokens generated can only be used for repeat transactions on that particular device. So say a user tokenizes their card on Swiggy, the token generated will be specific to that device and to Swiggy.
Device side tokenization is used by payment solutions like Apple Pay and Google Pay, which are primarily app-based payment options. For merchants to implement Device Side Tokenization, they require a certified SDK provided by Networks or an approved 3rd party Token Requestor — TSP
Server-side or Card on File Tokenization (CoFT)
CoFT involves generating tokens that are not unique to any device — they are only mapped to the merchant.
For eg: A card tokenized on Swiggy can be used across any of the Swiggy platforms (Desktop, Android, Mweb, etc). Unlike Device side tokenization, CoFT can be implemented by integrating APIs provided by either the Networks, Issuers, or Token requestors
In general, CoFT is the preferable mode of tokenization given it allows interoperability of tokens among different platforms
The New RBI PA/PG Guidelines
The RBI PA/PG guideline prohibits merchants/PAs or any other entity in the acquiring eco-system from storing customer card-related information, thereby making the existing saved card experience, as well as the flows that rely on the whole or partial card number, defunct.
The Card Tokenization framework, specifically Network and Issuer Tokenization, is the RBI’s recommended way forward to retain these experiences.
Network or Issuer tokenization refers to the tokenization of cards at the Network and Issuer ends respectively. Legally, only these entities will be allowed to store the customer PAN and will be responsible for issuing tokens for each PAN.
For eg: If you have an HDFC Visa card, the only two entities that can store this card number and provide a token for the same, are either Visa or HDFC.
How does the solution work?
Network or Issuers provide a Token issuance platform where eligible entities called “Token Requestors” can facilitate the generation of tokens as well as the processing of tokens in the subsequent transactions.
TR or Token requestor entities need to integrate and get certified with these token platforms, to provide this solution to end merchants. Merchants can also become certified TRs by undergoing certification. Being a TR also involves undergoing periodic audits by a CERT in addition to being PCI compliant.
Impact on Merchants
For most e-commerce merchants, over 75% of returning customers save their cards for a seamless checkout experience wherein they only enter their CVV and proceed to complete their transactions. This not only serves as a delightful checkout experience but also improves the conversion and success rates for merchants by 7–8%.
A merchant today enables such experiences by saving their customer cards, either on their own platform(if PCI L1 compliant) or on PCI L1 certified partner platforms who can store these cards on their behalf. Going forward, a merchant will have to enable tokenization and use these tokens to continue offering a similar seamless checkout experience for their customers.
Impact on Customers
The impact of the regulatory changes on a customer from a user experience standpoint is minimal. Let us take a look at each flow in detail:
First Transaction (Converting the Card to a Token)
The first transaction for a user on a Merchant who has enabled Tokenization is largely the same, except that the user will have to give explicit consent to the Merchant to tokenize their cards before proceeding with their OTP-based transaction. This consent would be taken even if the user adds their 16 digit card and opts in to save their card for future transactions
Repeat Transaction (Token-based transaction)
The following transactions after a card is tokenized, again, largely remain unchanged. The only minor difference to the user is that their 16 digit card number will now only have their last 4 digits visible — the remaining will be masked.
For a customer who chooses not to tokenize their cards, he/she would have to enter their card details each time they transact on the merchants’ platform.
Juspay’s role in the Tokenization ecosystem
Juspay is a certified Token requestor with all major networks and enables merchants to offer tokenization solutions to their customers. Merchants can integrate with Juspay to generate tokens and process token-based transactions through the PA/PGs of their choice. Alongside the experience of the saved card via Tokenization, Juspay has also built solutions to support all flows that depend on customer card numbers like EMI, Offers, Native OTP, 1-click, etc.
Juspay continues to be a key contributor in building a relevant Tokenization solution for the Indian market by working closely with major networks and partners in the ecosystem for over a year.
For a TLDR version, watch this video that covers why, what and how Tokenization works.
If your business is unsure about dealing with the new RBI guidelines, let Juspay take charge of your payment experience now! Contact us at email@example.com for more details on our Tokenization solution.
- Who is a Token Requestor?
Token Requestors are entities certified by networks that can integrate with networks and provide services like Token Issuance, Token Retrieval, and Token Lifecycle-related activities.
2. Who can become a Token Requestor?
A Token requestor can be a merchant or a third party who can provide this service on behalf of networks to merchants.
3. Does a merchant need to integrate with networks to provide this for their users?
Merchants can do this but unless it is a core part of the product it is cumbersome and costly to integrate, manage and keep up with changing protocols and guidelines of tokenization with each network. Merchants can use third-party service providers as they can do this at scale and provide a scalable solution that fits their requirements.
4. Do Merchants need to be PCI compliant to offer tokenization to their customers?
At Juspay we have designed our solution such that merchants do not need PCI compliance to offer tokenization to their end customer
5. How will token-based transactions work?
Token transaction processing from a merchants perspective remains the same if they use Juspay for Payment platform. For non Juspay merchants, merchants need to upgrade their PA/PG integrations to process transactions via tokens. At Juspay we are working with our PA partners to ensure seamless integration of new APIs of Payment Aggregators and Gateways.
6. Will a customer be charged extra if they choose to tokenize their cards?
As per RBI regulation, no charges should be recovered from the customer for availing this service.
7. How can a merchant integrate with Juspay?
Please contact your KAM or write to firstname.lastname@example.org. We have multiple integration interfaces like SDK, APIs and you can choose the most suitable option for you.