Card tokenization: what a token is, who stores it, and why your database should never see a PAN

In digital commerce, there is a fundamental technical rule: the best protected payment data is the data that never touches your servers. During the early days of online retail, merchants often stored the Primary Account Number (PAN), expiration date, and even the CVV/CVC code in their own databases to process recurring charges or enable one-click purchases. Today, this practice is not only a severe compliance violation but also an unacceptable operational and financial risk.

The standard engineering solution for running future payments without handling sensitive cardholder data is tokenization. Understanding how a token is generated, which entity stores the underlying sensitive record, and how this impacts your technical architecture is essential for any team processing online payments.

What a payment token actually is

A token is an alphanumeric string generated through pseudorandom generation or irreversible cryptographic functions that stands in for sensitive card data. Unlike traditional reversible encryption—where a mathematical key can decrypt the original card number if compromised—a token contains no underlying PAN data within its structure.

A token behaves like a cloakroom ticket: it has zero intrinsic value outside the specific environment that issued it. If an attacker breaches a merchant database and steals a table of tokens, those values cannot be used to execute purchases at other merchants or clone physical cards. Only the authorized vault knows which real card the token references, and it will only accept payment instructions signed by the verified merchant.

In day-to-day operations, the merchant stores this token alongside non-sensitive card metadata within the user record:

• The last four digits of the card (for customer reference in the UI).
• The card brand (Visa, Mastercard, etc.).
• The expiration date.

With these fields, the merchant provides a seamless checkout experience without ever handling or seeing the complete card number.

The lifecycle of a tokenized payment

The process of swapping sensitive data for a secure identifier follows an exact sequence when a customer submits payment details:

• Client-side isolated capture: Checkout form fields never submit card details to the merchant backend. Data travels directly from the user browser or mobile app to the payment gateway secure servers via an isolated iframe, mobile SDK, or hosted web component.
• Vaulting in a secure environment: The gateway ingests the PAN, expiration date, and CVV inside an infrastructure certified at the highest PCI DSS compliance tier. The data is written to an encrypted digital vault.
• Token issuance: The gateway generates a unique reference mapped to that specific card and merchant account, returning it to the client frontend or via a direct server-to-server webhook.
• Merchant storage: The merchant database saves only the reference token (such as `tok_9f8a7b6c5d`) linked to the customer identifier.
• Subsequent charges: When processing renewals in subscriptions or recurring orders, the merchant submits an API call specifying the amount and the token, without prompting the customer for card data again.

Throughout this flow, the initial transaction typically completes strong customer authentication (SCA) and 3D Secure protocols so the issuing bank authorizes future Merchant Initiated Transactions (MIT).

Gateway tokens versus network tokens

There are two distinct architectural implementations of tokenization in digital payments:

Gateway tokens

Issued and maintained by a specific payment gateway. These identifiers are tied to that single vendor: migrating away requires a regulated, complex vault-to-vault transfer between providers or asking customers to re-enter their card details. Additionally, if a physical card expires or gets replaced due to loss, gateway tokens often break unless the provider operates an automatic card account updater service with issuing banks.

Network tokens

Issued directly by card schemes (such as Visa or Mastercard) through services like Visa Token Service (VTS) or Mastercard Digital Enablement Service (MDES). Under this model, the token exists natively across the card network. They provide two major operational advantages:

• Automatic lifecycle management: If a physical card is reissued or expires, the card brand automatically updates the underlying mapping in the central registry with zero friction for the customer or merchant.
• Higher authorization rates: Because transactions travel across schemes as brand-verified tokens, issuing banks apply more favorable fraud scoring, reducing false decline rates.

Why storing a PAN breaks merchant operations

Ingesting or storing a raw PAN on your own infrastructure triggers full-scope PCI DSS requirements at the most demanding and expensive audit tiers. It necessitates mandatory on-site evaluations by Qualified Security Assessors (QSAs), strict physical and logical network segregation, hardware security modules (HSMs) for encryption key management, and continuous penetration testing.

The annual operational expense of maintaining an infrastructure certified to hold cardholder data easily runs into tens of thousands of euros in audits and tooling alone, excluding legal liabilities and banking fines in the event of an intrusion.

By offloading card capture and storage to specialized token vaults, merchants reduce their compliance scope to minimal self-assessment questionnaires (typically SAQ A or SAQ A-EP), achieving robust technical security with negligible overhead.

Practical conclusion

Tokenization is not a matter of convenience; it is the core architectural foundation of modern recurring digital commerce. Keeping your database entirely free of cardholder numbers drastically shrinks your attack surface, cuts compliance overhead, and delivers frictionless repeat checkout flows. The engineering best practice is absolute: decouple card data capture at the client layer and ensure your application records only tokens and non-sensitive display references.