Payment Tokenisation vs P2PE: cutting PCI scope the right way

Merchants often buy tokenisation expecting it to shrink PCI DSS scope at the till, or buy point-to-point encryption expecting it to clean up stored card data, and end up with neither benefit because each control removes card data from a different part of the flow. Point-to-point encryption (P2PE) protects account data from the moment the card is read until it reaches a secure decryption environment; tokenisation replaces the primary account number (PAN) with a surrogate after authorisation so that downstream systems never hold it. This guide compares the two as a scoping decision: where each removes card data, what the PCI Security Standards Council (PCI SSC) says each does to scope, how they fail, and how to combine them. It is for payment security leads, architects and assessors in retail, hospitality and multi-channel businesses. The P2PE standard itself is covered in the PCI Point-to-Point Encryption Guide and the general encryption versus tokenisation choice in Tokenisation vs Encryption; this page does not repeat them.

Key takeaways

• They protect different stretches of the card data journey. P2PE covers capture and transmission, from the terminal to decryption; tokenisation covers everything after the token is issued, from order systems to analytics and refunds.
• Neither removes PCI DSS. PCI SSC FAQ 1158 says a PCI-listed P2PE solution can significantly reduce the PCI DSS requirements that apply but does not fully remove them, and the PCI SSC Tokenization Guidelines say tokenisation does not remove the need to maintain and validate compliance.
• Only listed P2PE delivers the formal card-present scope reduction. SAQ P2PE eligibility depends on a validated, PCI-listed solution, terminals as the only systems touching account data, and all controls in the P2PE Instruction Manual (PIM) in place.
• Token systems leave scope only under strict conditions. PAN recovery must be computationally infeasible, the systems must be segmented from anything that can de-tokenise, and no cardholder data may arrive through another channel.
• The PCI SSC recommends combining them. Its Tokenization Guidelines suggest pairing tokenisation with P2PE so that the only PANs in the merchant environment exist inside a PTS-approved point-of-interaction device.

Short answer: which one removes which card data

The pattern is the decision. If your card data problem is the store network and POS estate, P2PE is the control. If it is stored PAN in business systems and multiple channels, tokenisation is the control. Most merchants with physical stores and stored card-on-file data have both problems.

How each option works and where it fails

Point-to-point encryption

Architecture in words: the cardholder taps, dips or swipes at a PCI-approved PTS point-of-interaction (POI) device. The terminal encrypts account data with keys injected by the solution provider; the merchant's POS, network and servers carry ciphertext they cannot decrypt; the data is decrypted only in the provider's secured decryption environment, typically in a hardware security module. PCI SSC describes the data as unreadable until it reaches the secure decryption environment, so it is less valuable to thieves if stolen.

Threat model: P2PE targets attacks that harvest cardholder data inside the merchant environment: memory-scraping malware on POS systems and network sniffing on store networks (in ATT&CK terms, T1005 Data from Local System and T1040 Network Sniffing). It does not stop terminal tampering or overlays at the device itself, which is why the merchant's PIM duties matter, and it does nothing for PAN that later lands in merchant systems through another route.

Failure modes:

• Unlisted or expired solution: solutions on the PCI SSC list of expired validations are not considered validated, so the merchant loses SAQ P2PE eligibility even though the encryption still works.
• PIM not followed: implementing all PIM controls is an eligibility condition, so unmanaged terminal handling breaks it.
• Side channels: a manual key-entry PC, a back-office virtual terminal or emailed card details puts cleartext PAN back into scope.
• PAN returned in the response: if the provider returns full PAN for refunds or loyalty matching, the merchant again stores account data electronically, which SAQ P2PE does not allow.

Since 1 January 2026 all new P2PE submissions, including reassessments, must use P2PE v3.2, published by PCI SSC on 30 June 2025; existing v3.0 and v3.1 validations are not affected by that change.

Payment tokenisation

Architecture in words: after capture, the PAN is sent to a tokenisation service, which returns a surrogate value. The merchant stores and uses the token for refunds, recurring payments and analytics; only the tokenisation system can map a token back to the PAN. Three models exist in practice: a processor or gateway tokenisation service operated by a third party, an in-house vault the merchant runs itself, and payment network tokens issued under the EMV Payment Tokenisation Specification and covered in the Network Tokenisation for Payments Guide.

The PCI SSC Tokenization Product Security Guidelines classify tokens as irreversible (never convertible back to the PAN), reversible cryptographic (derived from the PAN with a key) and reversible non-cryptographic (recovered only by look-up in a card data vault). Reversible, encryption-based tokens are encrypted PANs and may remain subject to PCI DSS.

Threat model: tokenisation targets theft of stored card data from databases, backups, logs and analytics copies. It concentrates the risk in the vault and the de-tokenisation interface, and it does nothing for card data in transit from the terminal to the tokenisation service.

Failure modes:

• In-house vault inside the merchant network: the Tokenization Guidelines put every component that generates tokens, redeems PANs or can reach the tokenisation system in scope; running it yourself moves scope rather than removing it.
• De-tokenisation sprawl: refund, fraud and customer service tools that call de-tokenise by default bring their hosts and users back into scope.
• High-value tokens treated as harmless: tokens that can initiate a transaction may be as valuable to an attacker as the PAN, need extra fraud controls and may stay in scope; the guidelines tell merchants to consult their acquirer and the payment brands.
• Legacy PAN left behind: systems only leave scope once historical cardholder data has been securely deleted.

What each does to PCI DSS scope

The PCI DSS v4.0 SAQ P2PE (April 2022) lists the eligibility conditions: all payment processing through a validated, PCI-listed P2PE solution; the solution's terminals are the only systems that store, process or transmit account data; no other electronic receipt, transmission or storage of account data; any retained account data on paper only; no access to cleartext account data on any computer system; and all PIM controls implemented. Check the current SAQ edition with your acquirer before you plan around it. For the full list of questionnaires see PCI DSS SAQ Types.

For tokenisation, the PCI SSC guidance recommends that the tokenisation system never returns the PAN to the merchant in any response, so refunds and chargebacks work on tokens. That single design rule decides more scope than any other tokenisation choice.

Combining both

The two controls are designed to meet in the middle. A combined design looks like this:

1. Capture: the card is read and encrypted in a listed P2PE terminal.
2. Transit: ciphertext crosses the store network and POS to the provider.
3. Decryption and authorisation: the provider decrypts in its secure environment and authorises the transaction.
4. Token issue: the provider returns a token (and perhaps a truncated PAN for receipts), never the full PAN.
5. Use: the merchant stores the token for refunds, recurring payments, loyalty matching and analytics.
6. Other channels: e-commerce and contact centre payments are captured by a provider-hosted payment page or secure capture service and receive tokens from the same service, so one token format spans channels.

This is the PCI SSC's own suggestion in its Tokenization Guidelines: the only PANs in the merchant environment then exist within a PTS-approved POI device. Two conditions make it work. First, the P2PE provider and the tokenisation provider should be the same party, or have a defined interface where decryption and token issue happen outside the merchant environment. Second, token format and lifecycle must be agreed before rollout, because changing token providers later means re-tokenising stored data or keeping two mappings.

Worked scenario

A regional restaurant group has 120 sites with integrated POS, an online ordering site and a loyalty programme that matches cards to members. Its QSA finds the store network, POS servers and loyalty database in scope. Moving the stores to a listed P2PE solution removes cleartext data from the store estate, but the loyalty database still stores PAN received in authorisation responses, so the group cannot use SAQ P2PE until that stops. Switching the provider response to tokens fixes the loyalty match and the refund process; the old PAN in the loyalty database is securely deleted; online ordering moves to a provider-hosted payment page that returns the same token format. The stores become eligible for SAQ P2PE, and the loyalty and order systems fall outside scope once segmentation from the provider's de-tokenisation service is confirmed. The online channel is validated separately under the questionnaire the acquirer specifies.

Decision criteria

Trade-offs: P2PE ties you to the solution provider's terminals, key injection and processing relationship, so switching acquirer is a hardware project. Tokenisation ties stored data to a token provider's format, so switching means migration. Small merchants usually get both from one processor and should focus on not undoing the benefit through side channels. Large merchants need an architecture decision on who runs decryption and the vault, and an exit plan for each.

Implementation steps

1. Map every card data flow. Include channels, refunds, chargebacks, loyalty, fraud review, call recordings and data warehouse feeds. Mark where PAN appears in cleartext, encrypted or tokenised form. See the PCI DSS Scoping and Network Segmentation Guide.
2. Confirm the target with your acquirer. SAQ eligibility is set by acquirers and payment brands, not the Council.
3. Select a listed P2PE solution. Check the PCI SSC listing and its expiry, then read the PIM before signing.
4. Define the token response. Contract for tokens and truncated PAN only, never full PAN; agree format, multi-use behaviour and portability.
5. Pilot in a few sites. Run P2PE terminals alongside the old flow, confirm no PAN reaches POS logs or databases, and test refunds, voids and offline modes.
6. Remove side channels. Retire manual key-entry PCs, virtual terminals on general workstations and email or fax card capture.
7. Purge legacy PAN. Discover and securely delete historical card data so that systems can leave scope.
8. Roll out by region with rollback. Keep old terminals boxed until each wave passes; rollback means returning that wave to full scope, so keep the old controls valid until sign-off.
9. Revalidate. Present the new data flow, PIM evidence and segmentation tests to your QSA or acquirer.

Where identity fits

De-tokenisation is a privilege. Every human and machine identity that can call it brings scope with it, so treat the de-tokenisation API like a privileged credential: few callers, mutual authentication for systems, multi-factor authentication for people, as the PCI SSC Tokenization Product Security Guidelines recommend, and logs that never contain PAN. Integration accounts and API keys that call the token service are non-human identities; see PCI DSS Requirements for Service Accounts and NHIs Guide (8.6). For P2PE, the identities that matter sit with the provider: remote terminal management and key loading.

Detection and measurement

• Cleartext PAN discovery: scheduled data discovery scans across file shares, databases and logs; target zero PAN outside the provider.
• De-tokenisation calls: volume by caller and purpose; alert on new callers and unusual spikes.
• PIM control completion: share of sites evidencing every PIM control at each review.
• Listing status: days until the P2PE solution's validation expiry, reviewed quarterly.
• Side-channel count: manual entry points, virtual terminals and non-P2PE devices still accepting cards.
• Scope size: number of in-scope system components before and after, as agreed with the assessor.

Card data compromise response is covered in the Payment Card Compromise Response Playbook.

Common failure patterns

• Buying tokenisation to fix the store network: tokens are issued after authorisation, so cleartext PAN still crosses POS and network.
• Buying P2PE but receiving full PAN back: the merchant keeps storing account data electronically and loses SAQ P2PE eligibility.
• Ignoring listing expiry: an expired solution is no longer validated, whatever the encryption strength.
• Keeping one manual entry PC: a single non-P2PE capture path brings the workstation and its network back into scope.
• Running the vault in the CDE without segmentation: the tokenisation system and everything that can reach it stays in scope.
• Treating multi-use tokens as worthless: high-value tokens need fraud controls and may stay in scope.

Framework mapping

Practitioner checklist

• Map where PAN exists by channel and stage before choosing either control.
• Confirm SAQ eligibility and the target questionnaire with your acquirer.
• Use only a validated, PCI-listed P2PE solution and track its expiry.
• Implement and evidence every control in the PIM at every site.
• Contract for tokens, never full PAN, in every response.
• Remove all non-P2PE capture paths.
• Restrict and log de-tokenisation; treat callers as privileged identities.
• Securely delete legacy PAN so systems can leave scope.
• Agree token portability and exit terms with the provider.

Standards and references

• PCI SSC: Point-to-Point Encryption (P2PE)
• PCI SSC: Version 3.2 of the P2PE Standard released
• PCI SSC: PCI DSS v4.0 Self-Assessment Questionnaire P2PE
• PCI SSC: Information Supplement, PCI DSS Tokenization Guidelines
• PCI SSC: Tokenization Product Security Guidelines
• PCI SSC: FAQ 1158, effect of a PCI-listed P2PE solution on merchant validation
• PCI SSC: FAQ 1247, who can use SAQ P2PE
• PCI SSC: FAQ 1326, PCI DSS and EMVCo Payment Tokens

Related NHI Mgmt Group resources: PCI Point-to-Point Encryption Guide, Tokenisation vs Encryption, Network Tokenisation for Payments Guide, PCI DSS Scoping and Network Segmentation Guide.