India is the market where the usual “just save the card for next time” pattern is not a design choice you get to make. The regulator removed it, and what replaced it changes how a saved card works everywhere in your system.
| Currency | INR (Indian rupee) |
|---|---|
| Card networks in common use | RuPay, Visa and Mastercard |
| National card scheme | RuPay — operated by National Payments Corporation of India (domestic credit and debit) |
| Other payment methods a checkout has to handle | UPI, Net banking and Cash on delivery |
| Payments regulator | Reserve Bank of India |
| Strong customer authentication | Required — RBI Additional Factor of Authentication (AFA) |
Merchants cannot store card numbers
Under the Reserve Bank of India’s tokenisation framework, merchants and payment aggregators may not store card credentials — not the number, not the expiry, not the CVV Master Directions1. The card-on-file model that most checkouts are built around is simply unavailable.
What replaces it is network tokenisation. The customer consents, the card network issues a token, and the merchant stores the token instead of the number. The token is scoped to that one merchant, so it is worthless if stolen and used elsewhere — which is the entire point.
This is a bigger change than it sounds, because a token is not a drop-in replacement for a PAN in the places PANs tend to leak into a system. Support tools that let an agent search orders by card number stop working. Fraud rules keyed on “same card, many accounts” need rewriting against a value that is deliberately different per merchant. Analytics that deduplicated customers by card number silently stop deduplicating. Anywhere a PAN was doing double duty as an identifier, tokenisation takes that job away, and the code that relied on it has to be found.
The general mechanics — what a token is, who issues it, how it differs from the PCI-scope reduction sense of the word — are in the tokenisation guide. India is the clearest large-scale case of it being mandatory rather than optional.
Two-factor authentication on domestic card payments
India required an additional factor of authentication on domestic card transactions well before Europe’s PSD2 arrived, and the requirement is unusually broad: it applies to card-not-present payments generally, with a narrow set of exceptions, rather than being risk-scored away.
For a developer this means the challenge path is the normal path, not the exception. A checkout that treats authentication as a rare branch — a spinner that appears occasionally, an error state nobody tested — will show its seams here. Recurring payments have their own regime built on pre-debit notifications and mandate registration, which is why subscription flows written for other markets frequently need reworking before they function in India at all.
RuPay, and a prefix collision worth knowing about
RuPay is the domestic scheme, operated by the National Payments Corporation of India RuPay2. It issues both credit and debit cards and is very widely held, so a brand detector built only from Visa, Mastercard and Amex prefixes will fail to identify a large share of Indian cards.
There is a specific technical trap here. Some RuPay ranges sit at prefixes that overlap what other tables assign to other networks — the 6- and 8-series in particular are crowded, with Discover, UnionPay, Maestro and RuPay all allocated in nearby space. A detector that resolves matches by “first rule that matches wins” will give different answers depending on the order its rules happen to be declared in, which is a bug that hides well because it produces a plausible brand name every time.
The fix is not to add RuPay to the top of the list. It is to rank matches by specificity — the rule that pins down the most digits wins, and an exact prefix beats a range that merely spans it. The BIN and IIN guide covers how the ranges are structured, and the brand detection guide covers writing a detector that does not depend on declaration order.
UPI is not a card
The Unified Payments Interface moves money directly between bank accounts using a virtual payment address, with no card, no PAN and no network in the path. It carries an enormous share of Indian digital transactions.
The reason to mention it in a guide about cards is precisely that it is not one. Nothing a card generator produces is relevant to a UPI flow, no card validation logic applies to it, and a UPI payment does not enter the parts of your system that handle cards. If you are localising for India, UPI is a separate integration with a separate test plan — treating it as “another card method” is the mistake, and it is a common one.
What to test, concretely
- The tokenised saved-card path, including the first payment where the token is created and a later one where it is used. Confirm no PAN is stored at any step; that is a compliance requirement, not a preference. The PCI DSS guide covers what counts as cardholder data.
- Authentication as the default path. Success, failure, timeout, and the customer who closes the tab mid-challenge.
- RuPay brand detection, and specifically that your resolver is not order-dependent.
- Amount formatting. The Indian digit grouping system groups the first three digits then pairs — ₹12,34,567 — and a formatter using thousands separators throughout will render amounts that read wrong to every Indian customer.
For the card field itself, a Luhn-valid number from the generator exercises the input normally. As everywhere, the generated number tells you nothing about whether a payment would succeed — and here is why.
India’s constraint is regulatory, but the general shape is common to every market worth localising for. Germany puts much of its commerce outside the card rails entirely, and Brazil changes what a single card authorisation even means.
The regulatory and scheme details on this page were last checked against provider documentation on . Providers do change what they publish — the official link beside each claim is authoritative.