Tokenization and PCI DSS
How card numbers are kept out of harm's way: network tokens that replace the PAN, and PCI DSS — the security rulebook for anyone who touches card data.
IN ONE LINE
An everyday analogy: a card number is like a house key that opens every door you own — anyone who copies it can come back whenever they like.
Tokenisation hands shops a different kind of key: a valet key, cut for one wardrobe — one phone, one shop, one purpose — and useless anywhere else.
When Maya Chen adds her Bank Alfa card to her phone, the phone never stores the real number at all: it stores a stand-in issued through the Cardnet network (a fictional stand-in for Visa- or Mastercard-style networks), and only the card system can connect it back to her account.
(SYNTHETIC / TRAINING ONLY — all names fictional.) PCI DSS is the other half of the story: a security rulebook for everyone who still handles real card numbers, on the blunt logic that the fewer places a real key exists, the fewer places it can be stolen from.
WHAT IT ACTUALLY IS
The real card number is the PAN — the primary account number.
A network token replaces it with a DPAN (a device or digital PAN): a substitute number issued under EMVCo's payment tokenisation specification, bound to a specific token requestor — a wallet, a merchant, an issuer app — and to a domain of use.
Payments carry the DPAN plus a per-transaction cryptogram; the network's token service vault maps it back to the real PAN so the issuer can authorise as usual.
A stolen DPAN is poor loot: outside its domain, without a fresh cryptogram, it should not work — and it can be paused or replaced without reissuing the card.
PCI DSS — the Payment Card Industry Data Security Standard — is the contractual security baseline for every entity that stores, processes or transmits real PANs: the networks require it of acquirers, and acquirers require it of their merchants.
HOW IT WORKS
The two tools meet in one practitioner's word: scope.
PCI DSS applies to every system that touches real card data, and every control in it — segmentation, encryption, access management, testing — costs effort per system in scope.
So the working strategy is to shrink scope: let a hosted payment page or a certified device capture the PAN so it never crosses the merchant's own servers, keep only acquirer-issued reference tokens for refunds and repeat billing, and use network tokens for wallets and stored credentials.
A merchant that never sees a PAN still has PCI DSS duties, but can attest through a much shorter self-assessment questionnaire; larger or riskier merchants face on-site assessment.
Two honest cautions close the topic: tokenisation reduces scope, it does not abolish it — and a network token is only as safe as the identity checks done when it was provisioned, which is exactly where wallet-fraud attacks have concentrated.
THE WORDS
- Network token
- A substitute for the real card number, issued by the card network's token service and restricted to a specific device, merchant, or channel.
- DPAN
- The substitute card number a phone or watch stores in place of the real PAN — a network token bound to that specific device.
- Token requestor
- The party that asks the token service to tokenise a card — a mobile wallet, a merchant with cards on file, or a gateway — each under its own registered identifier.
- PCI DSS
- The card industry's security standard for anyone who stores, processes, or transmits card numbers — enforced through the schemes and acquirers, not by law.
READ FIRST
CONNECTED TO
SOURCES
- Payments Signal editorial teaching models — Payments Signal
Derived from Tokenization and PCI DSS. Every claim on this card is sourced on that page.