Card tokenisation · saved cards
Saved cards, without anyone keeping the card number
In India, merchants and payment providers can't store customers' card numbers. Saved cards still work, because the card is replaced by a token that only the card network or issuer can turn back into a card. Here's how that works and what it changes for you.
•••• •••• •••• 4821
Token service provider: the card network or the card's issuer
Stored at merchant A
tkn_7Q2M…A91X- token
- last four: 4821
- issuer: Example Bank
- card number
Stored at merchant B
tkn_K80D…3LPZ- a different token
- last four: 4821
- card number
Why card numbers left merchants' servers
Saved cards used to mean a merchant, or its payment provider, kept the card number on file. Every such database was a target, and a breach at one merchant exposed cards that worked everywhere.
RBI's card-on-file tokenisation rules changed that. No entity in the card payment chain other than card issuers and card networks may store the actual card data. Merchants may keep only limited data for tracking and reconciliation: the last four digits of the card and the issuer's name. Everything else a saved card needs is done with a token.
Who does what
- Token service provider
- Turns card details into a token, and back again when a payment needs it. RBI permits card networks and card issuers to do this, each only for the cards issued by or affiliated to them.
- Token requestor
- Asks for a token on the customer's behalf, often the payment provider or a large merchant. It may or may not be the merchant itself.
- Merchant
- Where the card is saved. For a marketplace, the marketplace counts as the merchant.
- Card issuer
- The customer's bank. It validates the consent, shows the customer where their card is tokenised and lets them remove it.
Saving a card: consent, then a token
- 1
Offer, don't assume. The customer chooses to save their card. Tokenisation needs their explicit consent.
- 2
Authenticate. The card issuer validates that consent with an additional factor of authentication. When the customer is paying at the same time, one authentication can cover both.
- 3
Token issued. The token service provider creates a token unique to this card, this token requestor and this merchant.
- 4
Keep only what's allowed. You store the token reference, the last four digits and the issuer's name, enough to show “Card ending 4821” and to reconcile.
Paying with a saved card
When a returning customer picks “Card ending 4821”, the token is sent for payment, and the token service provider checks that the request really comes from the merchant and token requestor the token belongs to, and passes the payment to the issuer.
A saved card removes typing, not security. Domestic online card payments still need two factors of authentication under RBI's authentication directions, so the customer usually still confirms the payment. Recurring charges under a registered e-mandate are among the exemptions, which is why subscriptions can renew quietly. See the subscription payments guide.
What you may keep, and what you may not
| Data | May a merchant store it? |
|---|---|
| Token reference | Yes |
| Last four digits of the card | Yes, for tracking and reconciliation |
| Card issuer's name | Yes, for tracking and reconciliation |
| Full card number and other actual card data | No: card issuers and networks only |
From RBI's circular on card-on-file tokenisation (7 Sep 2021). Storage of the limited data must follow applicable security standards.
When the card changes, or the customer changes their mind
Card renewed or replaced
The issuer must ask the customer for explicit consent before linking the new card to merchants where the old one was saved.
Customer removes it at your end
You must offer a way to de-register the token, for example “Remove card” in their account.
Customer removes it at the bank
The issuer lets customers see every merchant where the card is tokenised and remove any of them, by app, internet banking, phone or branch.
Either way, the next charge on that token will fail. For subscriptions, ask the customer to save a card again before the renewal date.
Two kinds of token you'll hear about
Tokenisation in India began with devices. RBI first allowed card networks to tokenise cards on mobile phones and tablets, then extended it to laptops, desktops, wearables such as watches and bands, and other connected devices. That's what sits behind paying by tapping a phone or a watch.
Card-on-file tokenisation extended the same idea to cards saved with merchants, and also let card issuers act as token service providers alongside the networks. Both kinds replace the card number with a token; they differ in where the token lives.
| Device token | Card-on-file token | |
|---|---|---|
| Lives on | The customer's phone, watch or other device | With the merchant or its payment provider |
| Used for | Tapping to pay in shops, in-app payments on that device | Saved cards at checkout, recurring charges |
| Unique to | The card and the device | The card, the token requestor and the merchant |
| Removed by | The customer, in the device's wallet or settings | The customer at the merchant, or through the issuer |
Refunds and disputes on tokenised payments
A payment made with a token is an ordinary card payment underneath, so refunds and chargebacks work the usual way: a refund goes back to the card the token stands for, and a dispute raised by the cardholder follows the card network's process. You don't need the card number for either.
Where tokens help is identification. When a customer calls about a charge, the last four digits and the issuer's name are enough to find it, and they're exactly what you're allowed to keep. See the refunds guide for the rest.
A merchant's checklist
- Card numbers never touch your servers, logs, spreadsheets or support tickets.
- Saving a card is the customer's explicit choice, never pre-ticked.
- “Remove card” is easy to find in the customer's account.
- Support agents search by last four digits and issuer, never ask for the full number.
- Subscriptions warn customers before a charge if their saved card was removed.
- Old stored card data, if any ever existed in your systems, has been purged.
What tokenisation changes for your business
Subscriptions. Recurring card charges run on the token, so they stay with the provider through which the token and mandate were set up. Moving them to another provider isn't a switch you flip.
Returning customers. Faster checkout, because card details aren't typed again, but authentication still applies. See one-click checkout.
Reconciliation and support. Use the last four digits and issuer name to find a payment when a customer calls, never the full number.
Your security scope. Not holding card numbers takes a large class of breach off your hands. You still protect the token references and customer data.
Which token types Peneu supports, and which provider acts as token requestor for your cards, is confirmed during onboarding.
Card tokenisation questions
Can saved cards move with me if I change payment provider?
Not simply. A token is tied to the card, the token requestor and the merchant, so a change of token requestor can mean customers' cards need saving again. Plan provider changes with that in mind, especially for subscriptions.
What is card tokenisation?
Card tokenisation replaces a card's number with a token, a substitute value that can be used to pay but is useless if stolen. For saved cards (card-on-file), only the card networks and card issuers may store the actual card number; merchants and payment providers keep the token instead.
Can a merchant store my card number?
No. Under RBI's card-on-file tokenisation rules, no entity in the card payment chain other than card issuers and card networks may store the actual card data. Merchants may keep limited data for tracking and reconciliation: the last four digits of the card and the issuer's name.
Do I have to agree before my card is tokenised?
Yes. Tokenisation needs the cardholder's explicit consent, validated with an additional factor of authentication by the card issuer. If you're paying at the same time, that authentication can cover both the payment and the tokenisation.
Is the token the same everywhere I shop?
No. A token is unique to the combination of the card, the token requestor and the merchant. The same card saved at two merchants has two different tokens, so a token leaked from one merchant can't be used at another.
What happens to saved cards when my card is renewed or replaced?
Your card issuer has to ask for your explicit consent before linking the new card to the merchants where the old one was saved. If you don't give it, you'll need to save the new card again at those merchants.
How do I remove a saved card?
Merchants must offer an option to de-register a token. Your card issuer must also let you see the merchants where your card is tokenised and remove any of them, through its app, internet banking, phone banking or branch.
Does a saved card mean no OTP?
Not necessarily. A saved card spares the customer from typing card details, but domestic online card payments still need two factors of authentication under RBI's rules. Recurring charges under a registered e-mandate are among the exemptions.
Does Peneu support saved cards?
Card tokenisation is provided by the card networks and issuers through payment providers. Which token types are available through your Peneu setup, and which provider requests them, is confirmed during onboarding.
Official sources
- RBI — Tokenisation: Permitting Card-on-File Tokenisation (CoFT) Services (7 Sep 2021)Who may store card data, limited data merchants may keep, consent with AFA, token uniqueness, de-registration, reissued cards.
- RBI — Authentication mechanisms for digital payment transactions Directions, 2025 (25 Sep 2025)Two factors of authentication for domestic digital payments, with listed exemptions including recurring e-mandate transactions after the first.
Last reviewed . Examples, amounts and screens marked illustrative are not Peneu figures.