India's RBI Card Tokenization Mandate: What Payment Operators Must Know

India's Reserve Bank of India (RBI) issued one of the most operationally disruptive payment mandates in recent years. From October 1, 2022, payment aggregators, payment gateways, and merchants were prohibited from storing raw card numbers (PANs) for card-on-file transactions — a regime the RBI calls Card-on-File Tokenization (CoFT). Any operator that had previously saved customer card details for one-click checkout or recurring billing was required to either delete the stored PANs or convert them to network tokens issued by Visa, Mastercard, or RuPay — a regime that shares the same goals as the broader network tokenisation movement transforming global PSP and infrastructure stacks.

The mandate affected every player in India's card payments stack — merchants, payment gateways, PSPs, and acquirers — and required coordinated implementation across Visa, Mastercard, and RuPay simultaneously. Three years post-implementation, the tokenization ecosystem has stabilized, but operators still encounter compliance gaps, recurring payment edge cases, and integration complexity that this guide addresses directly.

What Changed: The Pre- and Post-Mandate Landscape

Before October 2022, card-on-file storage in India worked as it did globally: a merchant or gateway stored the full 16-digit PAN, expiry date, and (for non-3DS flows) cardholder name in their own database. One-click checkout worked by retrieving the stored PAN and submitting it in a new transaction. This model had obvious security implications — a data breach at any merchant exposed raw card data.

The RBI's Card-on-File Tokenisation (CoFT) circular (RBI/2021-22/96, "Permitting Card-on-File Tokenisation (CoFT) Services," September 7, 2021) changed this fundamentally, following two prior extensions of the original deadline as the industry flagged readiness gaps. The regulation prohibits:

• Payment aggregators from storing PANs after the transaction is complete
• Merchants from storing PANs at any point in the transaction flow
• Payment gateways from storing PANs except transiently during the authorization request — a constraint that interacts directly with the 3DS2 authentication tax operators face on card-not-present flows

The permitted alternative is network tokenization: the raw PAN is replaced by a token (a surrogate value) that is specific to the card network, the merchant (or merchant category), and the device/channel. The token is useless outside the specific context for which it was issued.

How Network Tokenization Works in India

Network tokenization in India follows the global token requestor model used by Visa and Mastercard, adapted to include RuPay (National Payments Corporation of India's domestic network).

The key entities:

• Token Requestor (TR): The entity requesting and using the token — in practice, the payment aggregator or gateway (e.g., Razorpay, PayU, Cashfree, CCAvenue). A Token Requestor ID must be registered with each card network.
• Token Service Provider (TSP): The card network itself (Visa Token Service, Mastercard Digital Enablement Service, RuPay Token Hub). The TSP maintains the mapping between the token and the underlying PAN.
• Issuer: The cardholder's bank, which must approve token issuance. The issuer's approval — typically via a one-time OTP or cardholder consent — is required to create a token.

The tokenization flow for a card-on-file use case:

1. Customer enters card details for the first time at checkout
2. The payment aggregator transmits the PAN to the card network's TSP via a tokenization request
3. The TSP returns a token (typically 16 digits, formatted to look like a PAN) specific to that aggregator-merchant pair
4. The aggregator stores the token, not the PAN
5. On subsequent transactions, the aggregator submits the token in the PAN field of the authorization request
6. The card network detokenizes (maps token → PAN) before passing the authorization to the issuer
7. The issuer sees the real PAN and processes the authorization normally

The token is merchant-scoped: a token issued for merchant A cannot be used at merchant B. This limits the blast radius of a compromise — a stolen token from one merchant has no value elsewhere.

Tokenization Across Networks

Each network maintains its own token vault and issues tokens independently:

• Visa Token Service (VTS): Visa-issued tokens for Visa cards
• Mastercard Digital Enablement Service (MDES): Mastercard-issued tokens for Mastercard cards
• RuPay Token Hub: NPCI-operated token service for RuPay cards

For operators, this means separate Token Requestor registrations with each network. A payment aggregator processing Visa, Mastercard, and RuPay transactions needs three TR registrations, three API integrations with the respective TSPs, and three token storage systems (or a unified internal mapping table). Major payment aggregators (Razorpay, PayU, Juspay) have handled this abstraction for operators who use their services — operators integrating directly with acquiring banks need to build or license this infrastructure themselves.

Guest Checkout Under a No-Raw-PAN Regime

Guest checkout is never named in most India tokenisation writeups, and it's the case operators get wrong first. CoFT prohibits storage, not transient use — a one-time transaction where the customer enters a PAN, the aggregator passes it through to authorization, and nothing is persisted afterward is not itself restricted. A pure guest purchase, never saved, works essentially as it does anywhere else.

The friction concentrates at the exact moment an operator tries to convert a guest into a returning customer. Offering "save this card for next time" mid-checkout means initiating a full tokenisation request — PAN to the TSP, issuer AFA validation, token returned — before that token exists to save anything. For a first-time, no-account guest, that's an OTP interruption inserted into the one flow segment most sensitive to friction. Two consequences follow directly:

• No silent 1-click for anonymous returning guests. Without an account, there's no reliable place to store a reference to the token between visits, so most implementations either force account creation to persist the token or re-collect the PAN on every guest visit — tokenisation buys nothing for a guest who never authenticates a save.
• Guest recurring signup can't skip AFA. A "guest" who wants to start a subscription still has to complete e-mandate registration, which requires AFA by definition. There's no compliant path to defer that authentication for an anonymous user — the operator either collects enough identity to register the mandate now, or blocks recurring signup for true guests entirely.

The practical design implication: treat "guest checkout" and "save this card" as two separate product decisions in India, not one toggle. The first is close to unaffected by CoFT; the second imports the full tokenisation-and-AFA cost regardless of account status.

Device Tokenisation vs Merchant CoF Tokenisation

The two are frequently conflated because both replace a PAN with a token issued by the same networks — but they're different models, registered under different circulars, with different lifecycles and different support paths.

Merchant CoF tokenisation — everything described above — is initiated by a payment aggregator or gateway acting as Token Requestor, scoped to a specific TR-merchant pairing, and used for online card-not-present flows: checkout, one-click, recurring billing. It's governed by RBI/2021-22/96 and is the version every PA-integrated operator deals with directly.

Device tokenisation runs on a separate track. It's initiated by the cardholder adding a card to a wallet — Google Pay, Samsung Pay, or an issuer's own app — and the resulting token is bound to that physical device, used for contactless/NFC tap and QR payments at point of sale or in-app. RBI's original January 2019 circular permitted this for mobile phones and tablets; a later extension (RBI/2021-22/92, August 2021) widened eligible devices to laptops, desktops, wearables, and IoT devices. The Token Requestor here is the wallet provider or issuer, not the merchant's PA — an operator accepting Google Pay tap-to-pay at POS is not integrating tokenisation directly; the wallet handles the entire provisioning-to-authorization chain.

The distinction matters operationally in two places:

1. Provisioning trigger. Merchant CoF tokens are created when a customer opts to save a card at a specific merchant's checkout. Device tokens are created when a customer adds a card to their phone's wallet — an action with no merchant in the loop at all, potentially completed long before that customer ever transacts with you.
2. Support triage. "My saved card stopped working" means something different depending on which token type failed. A merchant CoF token issue is fixable through the PA's re-tokenisation flow. A device token issue — the card was removed from the wallet, the phone was replaced, the wallet provider suspended it — is entirely outside the merchant's or PA's control; there is nothing to re-tokenise on the merchant side. Support scripts that don't ask "did you mean the card saved on our checkout, or the card in your phone's wallet?" will misroute a meaningful share of these tickets.

Most CNP web and app operators only ever touch merchant CoF tokens directly. Device tokenisation is worth understanding as the reason a customer's "same card" behaves inconsistently across your online checkout and their in-store tap — not as infrastructure you need to build.

Token Lifecycle: Provisioning to Deletion

A token isn't a static value issued once and forgotten. Four lifecycle events determine whether a stored credential keeps authorizing:

Provisioning. The flow described above — PAN submitted, issuer AFA validation, token returned, bound to the TR-merchant pair (and to the device, for device tokens). Nothing authorizes until this completes; a charge attempted against a token still mid-provisioning fails at the TSP before it reaches the issuer.

Update on reissue. When a card is reissued — expiry, or replacement after loss or fraud — the underlying PAN changes. Visa and Mastercard can propagate that change to every token mapped to the old PAN automatically, via a token-notification service, if the Token Requestor is subscribed to those lifecycle callbacks. If it isn't, the token doesn't error out visibly — it simply stops resolving to a live PAN, and the next charge against it fails at the issuer with no signal distinguishing it from any other decline.

Suspension. If a cardholder reports a card lost or stolen, the issuer suspends the underlying PAN — and every token mapped to it, across every merchant that token was ever issued to, stops authorizing simultaneously. This happens entirely outside the merchant's system; from the PA's side it's indistinguishable from a routine issuer decline.

Deletion. RBI's September 2021 circular requires the Token Requestor to give the cardholder a visible list of every merchant where their card is tokenised, with a de-registration control. Separately, the issuer must offer the same view-and-delete capability through its own channels — mobile app, internet banking, IVR, branch — independent of the merchant. That second path is the one operators miss: a customer can kill a merchant's token entirely through their bank, with no notice to the merchant until the next charge fails. Design monitoring around decline concentration on a single token or mandate, not around an event you'll be notified of.

Detokenisation: Who Can, and When

This is the structural feature that separates CoFT from a typical PSP vault model, and it's central to why recurring billing, refunds, and PSP migration all behave differently in India than elsewhere.

Only the network's Token Service Provider can reverse a token back to the underlying PAN — never the payment aggregator, the gateway, or the merchant — and only at the instant it's routing an authorization, refund, or chargeback request to the issuer. No intermediary in the chain is permitted to hold detokenisation capability at any other time.

Contrast this with the PSP-vault model documented in network tokens vs PSP tokens: in most markets, the PSP itself is the vault owner and can look up or rotate the underlying card for support, refund-to-a-different-instrument, or PSP-migration purposes. In India, no party downstream of the network is allowed to hold PAN data post-authorization at all, so there's no equivalent internal "look up the card" capability anywhere in the PA's stack. Three practical consequences:

• A support agent cannot pull a customer's card number to key a manual or offline charge.
• A refund cannot be redirected to a different card as a self-service option — see refunds below.
• A PSP migration cannot bootstrap from an exported card file, because no PAN file exists to export.

Impact on Recurring Payments: The E-Mandate Framework

The RBI's authorization framework for recurring card transactions — the e-mandate regime — predates the tokenization mandate but interacts with it critically. Understanding both together is essential for operators running subscription billing or EMI (equated monthly installment) products in India.

The e-mandate framework requires:

• First transaction: Always requires cardholder authentication (AFA — Additional Factor of Authentication, in practice OTP)
• Recurring transactions up to INR 15,000 (~$180 USD): Can proceed without per-transaction AFA, but require a pre-registered mandate
• Recurring transactions above INR 15,000: Require AFA at each transaction — except for specific categories (mutual fund SIPs, insurance premiums, and credit card bill payments), where the no-AFA ceiling is INR 1,00,000 (1 lakh)
• Pre-debit notification: the issuer must notify the cardholder at least 24 hours before each recurring debit. The aggregator initiates the recurring authorization; the issuer is responsible for the notification

As of April 21, 2026, these requirements sit in one consolidated instrument — RBI's Digital Payments – E-Mandate Framework, 2026 (RBI/DPSS/2026-27/396) — which folds eight prior circulars issued between August 2019 and August 2024 (including the original RBI/2019-20/193) into a single Master Direction. The consolidation reconfirmed both AFA thresholds and the 24-hour notification window unchanged; if you're working from an older citation to the 2019-20 circular, update the reference, not the numbers.

Post-tokenization, the mandate must be registered against the token, not the raw PAN — which means mandate continuity depends entirely on the token lifecycle behavior described above. If a customer's card is re-issued and your aggregator isn't subscribed to token-notification callbacks, the mandate doesn't get an error; the next debit simply fails.

E-Mandate Registration in Practice

For a SaaS operator or subscription platform running recurring billing in India:

1. At initial signup, customer enters card details
2. The aggregator tokenizes the card (as above) and registers a mandate with the issuer via the e-mandate API
3. Issuer sends OTP to cardholder for mandate authentication; cardholder approves
4. Mandate is registered: the aggregator has a token + mandate ID for future charges
5. For each billing cycle, the aggregator initiates the debit; the issuer is responsible for sending the pre-debit notification to the cardholder at least 24 hours in advance
6. On the billing date, the aggregator submits a recurring authorization using the token and mandate ID
7. For amounts above INR 15,000, the issuer blocks the transaction until the cardholder authenticates

The 24-hour pre-debit notification requirement is operationally significant. Operators cannot simply charge a stored card at midnight on the billing date — they must initiate the notification pipeline the previous day. Aggregators expose this as a mandatory parameter in their recurring charge API.

Failure and Fallback Handling for Tokenised Transactions

Most India tokenisation writeups stop at the happy path. Tokenised transactions fail for reasons that don't exist in a raw-PAN world, and — with one exception — RBI's circulars specify consumer-facing obligations (notify the cardholder, allow de-registration) without mandating a merchant-facing reason-code taxonomy for any of them. From the aggregator's side, most of these look like an ordinary issuer decline unless you've built monitoring specifically to separate them out:

The general decline-code taxonomy and retry-cap mechanics still apply underneath these India-specific triggers — see PaymentBrief's guide to merchant-initiated transactions for how to classify hard versus soft declines and how scheme retry limits work. The additions above are the layer specific to a tokenised, no-PAN-storage regime: several of them are not visible in a standard decline response at all, which is why decline-pattern monitoring — not the API error code — is how most operators actually catch them.

Refunds and Retries on Tokenised Transactions

Refunds on a tokenised transaction route back through the same token and transaction reference used for the original charge — the network detokenises for the refund exactly as it did for the authorization, resolving to the same issuer and PAN it always did. Because the PA never held the PAN, "refund to a different card" cannot be a self-service option in an India checkout; that request has to go through the customer's bank as a manual exception, and product copy or support scripts implying otherwise will create real disputes.

Two related failure modes worth designing around explicitly:

• Refund against a de-registered or expired token. If the underlying token has since been de-registered, or invalidated by a reissue your aggregator didn't catch, there's no live token left to reference for the refund. The reversal becomes a manual, bank-initiated process — materially slower than an automated PSP refund, and worth flagging proactively on time-sensitive disputes rather than letting the customer discover the delay.
• Retry discipline for failed recurring debits. Not every tokenised-transaction failure is safe to retry. Issuer-capacity or insufficient-funds declines can be retried within scheme retry caps. A token-invalid or AFA-required failure cannot — blind retry wastes attempts and can trip velocity controls; it needs re-registration or an on-session authentication step instead. Classify before retrying, the same discipline MIT retry logic requires generally, with the CoFT-specific failure modes above added to the classification.

Compliance Requirements for Payment Aggregators

Tokenisation compliance and Payment Aggregator authorization are two separate tracks that get bundled together in most operator research — worth pulling apart, since only one of them changed recently.

Tokenisation compliance (this article's subject) applies regardless of PA category: any entity acting as Token Requestor must register per card network, cannot store PANs beyond the transaction moment, and is subject to an annual system audit and storage audit confirming no residual PAN storage. This obligation sits on top of PA/PG authorization, not inside it — holding a PA license doesn't substitute for TR registration, and TR registration doesn't substitute for a PA license where one is required.

PA/PG authorization itself — who needs to be licensed, the three categories, net worth, escrow — was restructured by RBI in September 2025 into a single consolidated Direction (RBI/DPSS/2025-26/141) that replaced the framework this article previously cited. That's licensing detail this article no longer duplicates: see PaymentBrief's PA licensing guide for the current net worth bar, the PA-Online/PA-Cross Border/PA-Physical split, and the 2025 migration deadlines. The short version relevant here — a Payment Gateway (technology only, no settlement) still typically operates under a PA's authorization rather than holding its own, and still carries the same tokenisation compliance burden as a full PA.

Foreign operators collecting Indian card payments via a cross-border acquiring arrangement (e.g., a foreign merchant processed via Stripe US or Adyen Netherlands) sit outside CoFT's direct scope where no PAN is stored inside India — but card networks apply their own tokenisation requirements globally regardless, and authorization rates on tokenised transactions run measurably higher than raw-PAN for Indian-issued cards, so there's little reason to skip it even where it isn't strictly mandated. Operators actually collecting on behalf of Indian merchants cross-border (PA-CB) face a separate, India-specific authorization and FX-routing regime — covered in the licensing guide above, not here.

Practical Integration Steps

For operators building or auditing their India card processing stack — particularly those who also accept UPI as a payment method — the following steps apply:

Step 1: Confirm Token Requestor status If using a payment aggregator (Razorpay, PayU, Cashfree, Juspay), confirm they hold active Token Requestor IDs with Visa, Mastercard, and RuPay. Obtain confirmation in writing — TR registration can lapse if volume thresholds are not met.

Step 2: Audit existing card storage Run a scan of your database for any PAN-format strings (16-digit sequences matching Luhn algorithm). If any exist and post-date the October 2022 mandate, this is a compliance gap. Engage your PA to convert to tokens immediately.

Step 3: Implement tokenization APIs in checkout Your checkout flow should never return or log a raw PAN. Aggregator SDKs (Razorpay's Checkout.js, PayU's PayU.js) handle tokenization client-side before any data touches your servers. If you built a custom integration that passes card numbers to your server before forwarding to the acquirer, this architecture must change.

Step 4: Implement e-mandate registration for recurring flows If you run subscriptions or EMI products in India, map your recurring charge logic to the e-mandate framework. Test the 24-hour pre-debit notification flow explicitly — this is the most common compliance gap among subscription operators entering India.

Step 5: Build token lifecycle management Implement handling for token invalidation events. Your aggregator should expose webhook callbacks for card re-issuance or token expiry. When received, trigger a re-tokenization request at the next customer interaction.

Step 6: Decide guest checkout policy explicitly Separate "one-time guest purchase" (largely unaffected by CoFT) from "save this card" (requires full tokenisation and AFA regardless of account status) as distinct product flows. Don't let a generic "would you like to save this card?" prompt fire for anonymous guests without a plan for where the resulting token gets stored between visits.

Portability: What Happens When You Change PSPs

PaymentBrief's network-tokens-vs-PSP-tokens portability breakdown covers the general trade-off between scheme-issued and processor-issued tokens. India's CoFT model sits at the harder end of that spectrum, for a reason specific to the no-PAN-storage rule: a merchant CoF token is scoped to the Token Requestor ID that created it, not just the merchant ID, and there's no PAN anywhere in the outgoing PA's system for anyone to bootstrap a migration from. Elsewhere, a PSP switch can sometimes lean on scheme-level re-tokenisation without raw PAN access; in India, that path depends entirely on whether the outgoing and incoming PA coordinate a bulk TR-to-TR re-mapping directly with the network — a service some aggregators offer for a fee, not a default capability. Absent that coordination, switching PAs means re-registering the entire stored-card base under the new TR, with fresh AFA for every customer — closer to a full re-authorisation campaign than a lift-and-shift. Budget for this before signing with a new PA if you're carrying a large tokenised base.

What This Means for Operators

India's tokenization mandate is now mature enough that compliance is table stakes — acquirers and card networks will reject authorizations from non-compliant integrations. The operational burden has shifted from "how do we comply?" to "how do we maintain compliance as the infrastructure evolves?"

The recurring payments edge case is where most operators encounter ongoing friction. The e-mandate registration flow, the pre-debit notification requirement, and the INR 15,000 AFA threshold create a more complex recurring billing architecture than most markets require. Operators who underinvest in this architecture see elevated decline rates on recurring charges and customer churn from failed payments.

RuPay-specific tokenization remains the least mature part of the ecosystem operationally, even as RuPay's absolute card count is large — Jan Dhan Yojana financial inclusion accounts and government-mandated issuance have made RuPay debit cards especially common among lower-income and rural customer segments, independent of RuPay's smaller and more contested share of premium and credit-card spend. Operators with meaningful reach into those segments will encounter RuPay CoF tokenisation as often as Visa/Mastercard, on infrastructure that several PAs still treat as an afterthought. Confirm that your PA has active RuPay TR registration in writing, not just Visa and Mastercard — NPCI does not publish a reachable public TR-status page, so "confirmed by the network directly" isn't an option here the way it is for Visa/Mastercard.

Card-on-file tokenisation, device tokenisation, and the e-mandate framework are three interlocking regimes, not one — and for 2026, all three are the compliance reality every India card operator has to build around, with the operational edges covered above (guest checkout, lifecycle, detokenisation, failure handling, portability) doing more damage to conversion and support load than the headline PAN-storage prohibition itself.