Token Requestor

A card vault is the most expensive thing an e-commerce business can own: it puts storage of cardholder data in scope, and in some jurisdictions it is simply not allowed. India's restriction on storage of actual card data has held since 1 October 2022 that no entity in the card transaction or payment chain other than card issuers and card networks may store card-on-file data, and that data stored previously had to be purged.

The replacement is a network token: a surrogate number issued by the card network in place of the primary account number. Somebody has to ask for it, and that party is the token requestor, registered with the networks for the purpose. The token is bound to the requestor's identity, which is the fact that drives every architectural consequence that follows.

Why it matters

The requestor decision looks like a procurement detail and behaves like a lock-in decision. If your payment aggregator is the requestor, the tokens belong to that relationship; moving to another provider means re-tokenising every saved card, and tokenisation needs the cardholder's consent and an additional factor of authentication, so re-tokenising is a re-authentication campaign against your whole active base. If you register as the requestor yourself, you carry network registration, certification and operational duties, and you keep portability.

The second consequence is analytical. The primary account number disappears as a join key. Velocity rules keyed on card number, duplicate-account detection, loyalty linkage and chargeback matching against historical records all lose their identifier at the same moment.

Implementation patterns

• Store the token plus display metadata only: network, issuer, last four digits, expiry. That metadata is generally permitted and is what the saved-card UI needs.
• Key everything on your own mandate or payment-method id, never on the token, so a re-tokenisation changes one column rather than every foreign key.
• Tokenise on an authenticated moment. A successful billing cycle is free; a prompted migration is churn. At 4% monthly churn with monthly billing, roughly 96% of active mandates are reachable within one cycle.
• Ask the networks what account reference is available before designing around the loss of the PAN, since recognising the same card across tokens is a capability you either have or must replace with behavioural signals.
• Decide the requestor role explicitly and write down the exit cost, because the cheap option and the portable option are different ones.

Industry example

Razorpay's TokenHQ is a documented example of the aggregator-as-requestor model in India, built with Mastercard, RuPay and Visa, and offered to merchants who route payments through other gateways as well. The pattern it embodies is the common one: the aggregator takes on network registration and the merchant gets saved-card checkout back without holding card data. The cost of that convenience is that the tokens are scoped to the requestor, which the merchant discovers at the moment it wants to change provider.

Failure scenarios

• Purging the vault before the tokenised share is high enough, which is the point of no return: every un-tokenised customer must type their card in again.
• Treating migration as a batch job, then discovering that consent and authentication are required per card.
• Keying mandates on the token, so a provider change rewrites the schema.
• Dormant and annual mandates that no billing cycle touches, silently becoming the residual population nobody planned a re-entry flow for.
• Lost token-creation responses, leaving a mandate with two live tokens, which is benign, or with none that billed yesterday, which is the case to page on.

Trade-offs

When not to use it

If repeat purchase is rare and there are no recurring mandates, do not own tokenisation. The provider's hosted checkout with guest payment removes the vault, the migration and the storage obligation in one move, and the saved-card convenience lost is worth little when most customers buy once. Registering as your own requestor is also the wrong answer for a small merchant: the registration and certification burden outweighs a portability risk you can take once.

Interview question

Q: You hold 900,000 saved cards in your own vault in a market that no longer permits it, with 4% monthly churn and recurring billing. Plan the move to network tokens, name the point of no return, and say what you lose on the analytics side.

What a strong answer covers: dual-write first so the problem stops growing; tokenise on the next successful cycle rather than prompting; dual-read with an alert on vault fallback rate; a prompted re-entry flow for dormant mandates; purge as the irreversible step, gated on tokenised share rather than a date; and the loss of the PAN as a join key, with the requestor choice framed as portability against speed.

Quick check

Quiz: What does a token requestor change about a payment-provider migration? The tokens are bound to the requestor, so changing provider means re-tokenising every saved card with consent and authentication per card.

Flashcard: Why can a card-on-file token not simply be handed to a new payment provider? Because the network issued it against a specific registered requestor, so it is meaningless to anyone else and the cards have to be tokenised again.