Payment Tokenization
How real card numbers (FPAN) are replaced by tokens (DPAN) for digital wallets, card-on-file, and IoT payments. Covers the full lifecycle, cryptogram generation, and the Visa VTS vs. Mastercard MDES service comparison.
Custom tokens: without Visa, Mastercard or Amex
A custom token is any token you issue yourself instead of a card network's token service: a PSP's vault token, a merchant's or processor's internal card reference, an issuer's internal token, or the card credential of a closed-loop store or gift card. It only means something inside your own systems. To pay on the card rails you swap it back for the card number, or for a network token, just before authorization. The payoff is that everything else — CRM, billing, analytics, support tools — never touches a card number.
Ways to build one
| Method | Reversible? | Same card → same token? | Needs a database? | Good for |
|---|---|---|---|---|
| Vault, random token | Only via the vault | Your choice | Yes: token → card number | The default: PSPs, gateways, large merchants |
| Vaultless FPE (FF1) | Yes, with the key | Yes, per key and tweak | No | Legacy fields that need 16 digits; high-volume, multi-region systems |
| Keyed hash (HMAC) | No | Yes | No | Analytics, duplicate and fraud matching, loyalty linking |
| Encryption (e.g. AES-GCM) | Yes, with the key | No (random IV) | No | Storing card data itself — this is not a token, and PCI DSS treats it as card data |
Animated flows — vault, vaultless FF1, closed-loop card, wallet pass, tap with your own app
Your own token service with a vault: the card number is stored once, everything else in your systems holds a random token, and only the payment service can swap it back when it is time to authorize.
Card captured
The card number goes straight to the token service, never through your application servers.
This is what keeps the rest of the estate out of PCI DSS scope: only the capture page and the token service ever see the full card number.
Designing the token format
- Shape: new APIs can use opaque strings (
tok_8Hq…) that nobody will mistake for a card. Keep a 12–19 digit token only where legacy fields, screens or partners require it. - Keep the BIN and last four only if you need them: the BIN for routing, card-type logic and fraud rules, the last four for customer service. PCI DSS allows at most the BIN and last four to be shown, and every kept digit shrinks the part that hides the card.
- Make it fail Luhn. A digit token that passes the check can collide with a real card number and be sent to a network by mistake; one digit set to fail avoids that. The Custom Token Generator does this and can reverse it.
- Scope: one token per card for the whole platform, or one per merchant or tenant so tokens cannot be linked across them (in FF1 use the merchant ID as the tweak).
- Single-use or multi-use: single-use tokens suit a one-off checkout; stored cards need multi-use tokens, returned again when the same card is saved twice.
Vaultless FF1: what the standard now says
FF1 (NIST SP 800-38G) encrypts a string of digits into another string of digits of the same length. The second public draft of the revision (2025) removes FF3 and FF3-1 after an attack on their tweak schedule, keeps FF1, and requires at least one million possible values. On a 16-digit card, keeping 6 + 4 digits leaves only 6 to encrypt — exactly a million, and one fewer if one digit is set to fail Luhn. Keep fewer digits, or use a vault. The key must live in an HSM, because whoever has it can reverse every token.
PCI DSS scope
PCI DSS 4.0 requirement 3.5.1 accepts index tokens as a way to make stored card numbers unreadable. Per the PCI SSC Tokenization Guidelines, systems that only store tokens and cannot ask for detokenization can be taken out of scope; the vault, the tokenization and detokenization services, their keys and the capture page stay in it. A token made by encryption (including FPE) is still encrypted card data wherever the key can be reached. Keyed hashes must use a strong secret key (requirement 3.5.1.1, in force since 31 March 2025), because without one every possible card number can simply be hashed and compared.
Custom tokens vs network tokens: custom tokens protect your systems and are free to design; network tokens protect the payment on the rails (domain restriction, per-payment cryptograms, card updates) but are issued by the networks. Most PSPs use both: their own token for the merchant, pointing to a vault entry that holds the card number and a network token (see Merchant Tokens).
Putting a custom token in a phone
Apple Pay and Google Pay accept only payment cards from networks they have agreements with, provisioned through that network's token service — a custom token cannot become a card there. It can still reach the phone in four ways:
| Route | Apple | Google / Android | Accepted at |
|---|---|---|---|
| 1. Wallet pass with a barcode or QR code | Apple Wallet store card, gift card or generic pass (PassKit); rotate the code by pushing pass updates | Google Wallet API loyalty, gift card or generic pass; rotatingBarcode with TOTP built in | Your own tills and website that scan it |
| 2. Wallet pass read over NFC | NFC-enabled passes (Value Added Services), with an NFC certificate Apple must approve | Smart Tap on loyalty and gift card passes | Terminals that support VAS or Smart Tap — mostly loyalty; some closed-loop programmes pay this way |
| 3. Your own app emulates the card | NFC & SE Platform (iOS 18.1+, in countries such as the US, UK, Canada, Australia and Japan) or host card emulation in the EEA (iOS 17.4+); needs Apple's entitlement and a commercial agreement | Host card emulation: any app can register its own AIDs and be chosen as the default payment app | Terminals configured for your application ID (closed loop or domestic network) |
| 4. Become or join a supported network | Issue a real payment card on a network the wallet supports (including domestic schemes); it is then tokenized by that network's TSP | Everywhere the network is accepted | |
For store, gift, fuel and campus programmes, route 1 (plus route 2 where terminals support it) is the usual answer: the pass carries the custom token or a short-lived code derived from it, and your host checks it. Route 3 is for tapping to pay at your own acceptance points, and needs your own cryptogram so a copied token is useless. Step through both in the flow above.
Closed-loop and domestic cards
When the issuer also runs acceptance — store, gift, fuel, campus and transit cards — no card network is involved and the issuer defines its own token: a device-bound credential, a rotating QR code or barcode, or an NFC credential with its own keys. Domestic schemes (for example Cartes Bancaires, RuPay or eftpos) run their own token services on the same EMVCo model as VTS and MDES, so their tokens look like network tokens to merchants in that country (see Issuer Token Services).