The rule is short and absolute. From 1 October 2022, no entity in the card payment chain other than card issuers and card networks may store card-on-file data. That covers merchants, payment aggregators, gateways and anyone else in the flow. If your product holds a card number to make the next purchase easier, it is not a convenience feature — it is non-compliant, and it is a category of finding that ends conversations with any regulated partner.
What you may keep is deliberately minimal: limited reference information such as the last four digits and the issuing bank's name, which is what lets you display a saved card as ending 1234 without holding anything sensitive. Everything needed to actually charge the card lives with the network. This is why saved-card interfaces in Indian products look the way they do, and why a product ported from another market usually needs its payment data model rebuilt rather than adjusted.
Tokens are issued by the card network with the issuer's consent, on request from a token requestor — which is the app or website the customer is using. The important property for architecture is that a token is specific to the combination of card, token requestor and device. It is not a portable card reference you can reuse elsewhere. That means a token obtained through your web checkout is not usable by your mobile app unless it too is tokenised, and a customer changing devices may need to re-tokenise.
That specificity is a product design constraint people meet late. If your business has more than one customer-facing surface, each is a separate token requestor relationship. If you operate a marketplace where several merchants transact, tokens do not travel between them. And any flow that assumed a stored card could be charged from a batch job needs re-examining against what the token actually permits.
Consent has to be explicit and per-card. The customer agrees to tokenisation for that card with that merchant, with an additional factor of authentication at the point of setup. Building that into the flow means a first purchase has an extra step, and the payoff arrives on every subsequent one. Products that try to minimise the first-purchase friction by deferring tokenisation end up with a saved-card feature that does not work, which is worse.
One date worth having in the plan: the RBI's authentication directions requiring two-factor authentication for digital payments must be fully implemented by 1 April 2026. That is a separate obligation from tokenisation and is frequently conflated with it. If you are reviewing your payment flows for one, review them for both — the work overlaps, and doing it twice is avoidable.
