Demystifying Card Tokenisation


Picture this: you’re in the mood for some online shopping, ready to splurge on that outfit you’ve been eyeing for weeks. But then, you hit the dreaded checkout page, and the excitement fades away as you painstakingly enter your card details for what feels like the hundredth time. Talk about killing the vibe! It’s no wonder that many shoppers abandon their carts when faced with this tedious process. What if we tell you that Card Tokenization simplifies this entire tedious process and emplifies the checkout experience of your customers.

What is Tokenisation

Card Tokenization is a process to convert your 16 digit card number to a unique, irreversible, merchant scoped token. According to RBI, no entity in the card transaction or payment chain can store card details except for the card issuer and payment networks. Hence, tokenisation is an alternative and compliant way of saving the card in the form of unique token which is usually issued by the card networks. Card information is not stored now. Instead, the token is stored which is passed to the card networks to identify the unique card.

What does merchant scoped mean?

Let’s say you tokenize your card with Amazon. The token that is generated for Amazon wouldn’t work with any other merchant. And this token has an expiry and a lifecycle like a card.

With card tokenisation, you can say goodbye to the hassle of entering your card details every time you shop online. Instead, you only need to enter the CVV (those three digits in the magnetic strip) to make your purchase. These tokens can be used for online transactions (e-comm) as well as offline transactions(NFC). It’s convenient, it’s secure, and it’s the robust future of online shopping.

Tokenisation emerges as a savior for both consumers and businesses. With tokenisation enabled on your platform, you will be able to nudge customers to save their cards (in form of tokens). As the need to re-enter card detail is eliminated, this enables a seamless, convenient and secure checkout process with lesser cart abandonments.


Types of E-comm Tokenization

Card Tokenization can be done either at a Device level or at a Server level.

1. 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

2. 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: Need for Card Tokenisation

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.

The Tokenisation Process Flow

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 of Tokenisation

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 tokenization, 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.
Tokenized Card UX

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.

The Juspay Tokenisation

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 Tokenization.png

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.

If your business is unsure about dealing with the new RBI guidelines, let Juspay take charge of your payment experience now! Contact us at for more details on our Tokenization solution.

FAQs About Card Tokenisation

1. 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. What are the benefits of Juspay token-based transactions?
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 We have multiple integration interfaces like SDK, APIs and you can choose the most suitable option for you.