Token Requestor

A token requestor is an organisation that asks a token service provider to issue payment tokens to replace card numbers, and then stores and uses those tokens to initiate payments. Typical token requestors are phone and watch wallet providers, merchants that keep cards on file, payment gateways and processors acting for many merchants, card issuers offering their own wallets, and makers of connected devices that can pay. The role is defined in EMVCo's payment tokenisation framework, which sets out how requestors, service providers, issuers and acquirers interact.

The token requestor is the "front end" of network tokenization. It decides when to ask for a token, presents it at checkout and holds it securely, while the token service provider creates the token, keeps the link to the real card and validates its use. Each token requestor is registered and identified, so that tokens issued to it can only be used within its own domain.

Imagine a hotel that gives you a key card for your room instead of a copy of your house keys. You ask the hotel's front desk for a key; the front desk makes one that only works for your room, at that hotel, for your stay. If it is lost, the hotel cancels it, and your house is untouched.

In card payments, the token requestor is the party asking for the key card: your phone wallet or an online shop. It asks the card network to make a stand-in card number that only works for it. If that number leaks, it is useless anywhere else, and your real card keeps working.

• Device and wallet providers. Phone, watch and other wallet operators that put tokens on devices for in-store and in-app payments, a major use described under mobile wallets.
• Card-on-file merchants. Large merchants that request tokens directly for cards customers save at checkout, used in card-on-file transactions.
• Payment service providers. Gateways, processors and acquirers that request tokens on behalf of many merchants, so that smaller merchants benefit without integrating with each network.
• Issuers. Banks that tokenise their own cards in their apps, for example to push cards into wallets or merchants.
• Connected devices. Cars, wearables and other internet-of-things devices that can pay for fuel, parking or services.

Before requesting tokens, an organisation registers with each network's token service, agrees to its terms and meets security and technical requirements. The token service assigns a token requestor identifier, an 11-digit value in the EMVCo framework, which travels with each token transaction so the network knows which requestor is involved. The identifier is linked to the requestor's domain controls: rules that restrict a token to particular channels, merchants or devices. A token stolen from a merchant's system would fail if used through a different requestor or channel.

1. Request. When a customer adds a card, the requestor sends the card details and supporting data to the token service.
2. Identity and verification. The issuer decides whether to approve the token, sometimes asking the cardholder to confirm through a one-time password or the bank's app.
3. Provisioning. The token, its expiry and often a payment account reference are returned to the requestor and stored.
4. Payment. For each payment, the requestor or device obtains a one-time cryptogram and presents the token and cryptogram in the transaction.
5. Lifecycle. The requestor receives updates when a card is replaced, suspended or deleted, keeping tokens current without customer action.

Requestors differ in how they obtain cryptograms. Device wallets generate them on the phone or watch, using keys held in secure hardware or delivered from the cloud, which lets in-store taps work even with a weak signal. E-commerce requestors usually ask the token service for a fresh cryptogram for each online payment and pass it to the acquirer with the token.

Token requestors must protect tokens and keys, follow network rules on when tokens may be used, show cardholders which cards are tokenised, and handle deletion requests. Holding tokens rather than card numbers reduces the impact of a data breach and can reduce, though not remove, a merchant's PCI DSS scope. Requestors commonly report higher approval rates and fewer failed recurring payments, because issuers trust the cryptogram and tokens survive card reissuance. In some markets regulators have pushed adoption: India's central bank required card-on-file tokenisation and stopped merchants from storing card numbers from October 2022, making many merchants and payment providers token requestors. Merchants that are not large enough to register directly usually rely on their payment provider as requestor, sometimes through a payment gateway that also manages token storage.