Payment Tokenization: Mermaid Flowchart Diagram

About Source

Payment tokenization is the process of replacing a sensitive card number (PAN — Primary Account Number) with a non-sensitive substitute called a token. The token can be stored on merchant systems and used for future charges without exposing the real card data, dramatically reducing the scope of PCI DSS compliance.

There are two distinct types of tokenization used in payments:

Merchant tokenization (vault tokens): The payment gateway receives the card number, stores it in a secure vault, and returns a gateway-specific token (e.g., tok_1234abcd). The merchant stores this token. Future charges pass the token to the gateway, which looks up the real card in its vault and processes the charge. The token is specific to that gateway — it cannot be used with a different processor.

Network tokenization (device tokens): The card network (Visa, Mastercard) issues a device account number (DAN) that represents the real PAN in the network's Token Service Provider (TSP) infrastructure. This is the technology behind Apple Pay and Google Pay. Network tokens are tied to a specific device and merchant, rotate automatically when the physical card is replaced, and carry cryptograms that prove the payment came from the enrolled device.

Tokenization directly reduces PCI DSS scope. If a merchant stores only tokens and the gateway vault is breached by a third party, the stolen tokens are useless — they cannot be used at other merchants and do not expose real card numbers. The real PAN is only decrypted within the gateway's vaulting environment during charge processing.

The tokenization flow also integrates with client-side JavaScript libraries (Stripe.js, Braintree Drop-in). The JavaScript intercepts the card form submission, sends the card data directly to the gateway over TLS, and replaces the form values with a token before the form is submitted to the merchant's server — so the merchant's server never receives the card number in a request parameter. This is the recommended pattern for all web checkout forms.

Frequently asked questions

Payment tokenization replaces a sensitive card number (PAN) with a non-sensitive substitute — a token — that can be stored and reused for future charges without exposing real card data. It is the primary mechanism for reducing a merchant's PCI DSS compliance scope.

The gateway or network receives the real PAN, stores it in a secure vault or network TSP, and returns a token. The merchant stores the token. Future charges pass the token to the gateway, which retrieves the real card in its secure environment and processes the transaction without the card number ever touching merchant systems.

Use network tokens (device account numbers via Apple Pay, Google Pay) when you want device-level binding, automatic card-on-file updates when the physical card is renewed, and the cryptographic proof-of-device that lowers issuer fraud risk and improves approval rates.

Common mistakes include logging raw card numbers in server-side request logs before the JS library has replaced them, storing both the token and the last-four digits in a way that reconstructs partial PAN, using a gateway-specific vault token when network portability is needed, and not testing the JavaScript interception in browsers that block third-party scripts.

mermaid

flowchart TD
    A([Customer enters card on checkout form]) --> B[Client-side JS library intercepts form]
    B --> C[Send raw card number directly to gateway over TLS]
    C --> D{Tokenization type}
    D -->|Merchant vault token| E[Gateway stores card in PCI-compliant vault]
    E --> F[Gateway generates opaque vault token]
    F --> G[Return token to client JavaScript]
    G --> H[JS injects token into form, clears card fields]
    H --> I[Merchant server receives token only]
    I --> J[Store token in merchant database]
    J --> K{Future charge?}
    K -->|Yes| L[Send token to gateway]
    L --> M[Gateway looks up real PAN in vault]
    M --> N[Submit authorization to card network]
    D -->|Network token: Apple Pay, Google Pay| O[Wallet generates device account number]
    O --> P[Card network Token Service Provider issues cryptogram]
    P --> Q[One-time cryptogram sent to merchant]
    Q --> N
    N --> R([Transaction authorized])