GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX
CARDS & MERCHANT PAYMENTS · REFERENCE CARD

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

Derived from Tokenization and PCI DSS. Every claim on this card is sourced on that page.