EASYwalkthrough

Tokenization (PCI-DSS)

3 of 8
3 related
A raw credit card number (Primary Account Number, PAN) is 16 digits. Under PCI-DSS Level 1, any server that touches a raw PAN must pass a yearly audit costing 50K50K-500K, including penetration testing, log review, and network segmentation verification. Tokenization replaces the PAN with a random token (e.g., tok_abc123) at the edge, before the number ever reaches application servers.
Application servers only ever see tokens. When we need to charge the card, the payment service sends the token to the token vault, which decrypts the PAN and forwards it to the card network.
The token vault is a dedicated, isolated service with its own network segment, encrypted storage (AES-256 at rest), and HSM-backed key management.
This reduces the PCI-DSS audit scope from hundreds of servers to one isolated vault. Stripe's vault processes billions of tokenization requests per year.
Why not just encrypt the PAN and store it in the main database? Because encryption at the application layer still means the app server handles raw PANs in memory during encryption/decryption.
PCI-DSS considers this in-scope. The vault pattern ensures PANs are only in plaintext inside the vault's memory, never in application server memory.
Trade-off: every charge requires a round-trip to the vault (~5ms), but this is negligible compared to card network latency (200-500ms).
Why it matters in interviews
Interviewers ask 'how do you handle card numbers?' to test PCI-DSS awareness. Explaining tokenization at the edge and why application-layer encryption is insufficient shows you understand the audit scope reduction that makes compliance feasible.
Related concepts