PCI tokenisation is the practice of replacing a primary account number (PAN) with a surrogate value (a token) that carries no exploitable worth. Tokenisation has become the typical mechanism for satisfying the cardholder data protection requirements of the Payment Card Industry Data Security Standard (PCI DSS) because a system that holds only tokens generally falls outside the scope of the full standard.

This distinction, between systems that touch raw card numbers and systems that only ever see tokens, determines how much of the PCI DSS applies to a given business. This is important for payment security, given that the cost of a PCI data breach can range from US$5,000 to more than US$500,000.

Below, we’ll discuss how PCI tokenisation supports compliance, what happens technically from the moment a card gets entered to the moment a token comes back, and the advantages network tokens have over business-issued tokens.

Key takeaways

• Tokens replace PANs with surrogate values that can’t be reversed outside a certified vault.

• Businesses that stop storing raw PANs can often qualify for a shorter PCI DSS Self-Assessment Questionnaire (SAQ).

• Network tokens add cryptographic binding and automatic lifecycle updates that business-issued tokens don’t provide on their own.

What is PCI tokenisation?

PCI tokenisation replaces the digits printed on a payment card with a token: a surrogate value that looks like a card number but carries no exploitable value on its own. The token is what moves through a business’s systems, while the PANs are stored separately in a vault.

How does PCI tokenisation reduce PCI DSS scope?

Once a system stops storing, processing, or transmitting PANs and handles only tokens, most of that infrastructure can move outside the cardholder data environment and isn’t subject to the PCI DSS. If a system holds only tokens, there’s no PAN to encrypt, no encryption keys to manage on that system, and nothing relevant to include in file integrity monitoring. Visa and Mastercard both recognise tokenisation as an approved control in their own security standards. The PCI DSS references tokenisation directly in its guidance for rendering PANs unreadable wherever they’re stored.

With tokenisation, the token vault itself, any system that handles card capture before tokenisation happens, and anything with the technical ability to reverse a token back into a PAN all have to stay in scope. The vault operator needs its own PCI DSS validation, usually as a Level 1 service provider, which means an annual Report on Compliance from a Qualified Security Assessor rather than a self-assessment. A business that relies on a third-party vault inherits some of that assurance but still documents the relationship in its own attestation, typically through a shared-responsibility matrix that explains which requirements the vault operator covers and which fall back to the business.

Even with tokenisation handling the bulk of cardholder data protection, a few requirement categories don’t disappear. Requirement 12, which covers security policy and incident response, still applies to any business that accepts card payments. Network segmentation under Requirement 1, physical security around card-present terminals, employee access controls, and general hygiene, patching, firewalls, and antivirus software on any system that touches the payment flow before tokenisation are all still in place.

Tokenisation can also impact how a business validates PCI DSS compliance, which is done through either an SAQ or a Report on Compliance. A business that stores full PANs on its own servers typically falls under SAQ D, which covers the full PCI DSS requirement set. One that tokenises at the point of entry and never stores an unencrypted PAN can often qualify for the simpler versions, SAQ A or SAQ A-EP, instead.

How does PCI tokenisation work in practice?

The mechanics of PCI tokenisation come down to four steps: capture, exchange, storage, and reuse.

First, the system confirms the entry is a structurally valid card number, typically 13–19 digits, and identifies the card brand and issuing network. Then, it creates the surrogate token, which is either random or format-preserving (so the token can pass through existing databases and reporting tools without breaking length or format assumptions built into older systems).

The real PAN and its corresponding token get written into an encrypted vault, with the encryption keys managed separately, often inside a hardware security module. The surrogate value stays in the business’s other systems, where it replaces the PAN for any future reference.

When a charge needs to run, the tokenisation system detokenises the value internally, routes the real PAN to the card network for authorisation, and never exposes it to the systems that initiated the request. Reconciliation tools can match transactions using the token since it consistently maps to the same underlying PAN for the life of that card relationship.

How does network tokenisation differ from merchant-based PCI tokenisation?

A business-issued token, generated by the business itself or by a payment provider on its behalf, exists entirely within that business’s payment stack. It maps to a PAN inside a vault the business or its provider operates, and it typically works only within that system. It solves the PCI DSS storage problem well, but it doesn’t do much beyond that.

A network token comes from the card network itself. These tokens are cryptographically bound to a specific device, business, or channel through a token requestor ID so a token provisioned for one business’s checkout can’t be replayed somewhere else even if it leaked. Network tokens also update themselves: if a customer’s card gets reissued after a lost-card report or expires, the network pushes the updated token automatically.

Both approaches are compliant since both remove the raw PAN from the business’s environment. The difference shows up beyond compliance. Network tokens tend to produce higher authorisation rates because issuers can verify the cryptographic binding and trust the transaction context, and they minimise the failed renewals that come from expired-card declines.

Is PCI tokenisation right for your business?

The honest answer depends on how much cardholder data touches the business’s own systems today.

Here are some scenarios when tokenisation has the most benefit:

• Recurring or stored-card transactions: Subscription businesses, membership platforms, and anything that stores a card on file for future charges gain the most from moving PANs out of their own environments.

• Multiple internal systems that touch payment data: If customer service tools, analytics, and order management all need to reference a transaction, tokens let them do so without expanding the cardholder data environment to cover each one.

• Limited in-house security resources: Businesses without dedicated teams benefit from off-loading PAN storage and key management to a certified vault operator instead of building that infrastructure themselves.

• Plans to reduce card-on-file decline rates: Businesses that experience authorisation or renewal issues from expired cards should confirm their tokenisation systems support network tokens rather than only business-level ones.

Businesses that use Stripe already get PCI tokenisation by default, built into checkout integrations, hosted fields, and saved payment methods. The practical decision usually isn’t whether to tokenise but whether the current integration keeps raw PANs off the business’s own servers entirely, and to confirm that, along with which SAQ applies, covers most of the pragmatic evaluation.

How Stripe Payments can help

Stripe Payments provides a unified, global payments solution that helps any business – from scaling startups to global enterprises – accept payments online, in person and around the world.

Stripe Payments can help you:

• Optimise your checkout experience: Create a frictionless customer experience and save thousands of engineering hours with prebuilt payment UIs, access to 125+ payment methods, and Link, a digital wallet built by Stripe.

• Expand to new markets faster: Reach customers worldwide and reduce the complexity and cost of multicurrency management with cross-border payment options, available in 195 countries across 135+ currencies.

• Unify payments in person and online: Build a unified commerce experience across online and in-person channels to personalise interactions, reward loyalty and grow revenue.

• Improve payment performance: Increase revenue with a range of customisable, easy-to-configure payment tools, including no-code fraud protection and advanced capabilities to improve authorisation rates.

• Move faster with a flexible, reliable platform for growth: Build on a platform designed to scale with you, with 99.999% historical uptime and industry-leading reliability.

Learn more about how Stripe Payments can power your online and in-person payments or get started today.