Short answer
Point-to-point encryption (P2PE) encrypts card data inside the payment terminal the moment a card is read and keeps it unreadable until it reaches the solution provider's secure decryption environment. For PCI purposes, only solutions validated and listed by the PCI Security Standards Council count. Using one can move you to SAQ P2PE, a questionnaire for merchants whose terminals are the only systems touching card data.
Point-to-point encryption, or P2PE, encrypts card data inside the payment terminal at the instant a card is dipped, tapped, or swiped, so it stays unreadable all the way to your payment provider. The PCI Security Standards Council (PCI SSC), which writes the card industry's security standards, describes a PCI-listed P2PE solution as a combination of secure devices, applications, and processes that encrypt card data from an approved terminal through to a secure decryption environment. Your POS, your network, and your back office only ever handle scrambled data.
Why should a store owner care? A thief who gets into your network finds card data it can't read. And because card data never sits on your systems in readable form, merchants using a PCI-listed P2PE solution face fewer PCI DSS requirements, which means less compliance work. This guide covers how P2PE works, what "PCI-listed" means, how it compares with end-to-end encryption and tokenization, and whether a small business needs it. Everything is current as of October 2026.
What is point-to-point encryption?
It's encryption with two fixed ends: the terminal where the card is read, and the provider's decryption environment. Everything between them, including your POS software, Wi-Fi, router, and internet connection, carries only encrypted data. PCI SSC notes that with a listed solution, account data stays unreadable until it reaches the secure decryption environment, which makes it much less valuable if it's stolen in a breach.
What matters most is who can decrypt. In a P2PE solution, you can't. Decryption happens in the provider's secure environment, so nothing in your store can turn the data back into card numbers. That's the real gap between a terminal that "encrypts" and a P2PE solution. If the merchant's own systems could get at the readable data, it's still the merchant's data to protect.
How does P2PE work at the counter?
From the cashier's side, nothing changes. Behind the scenes, it goes like this:
- Your provider ships terminals that belong to its listed P2PE solution, already set up to encrypt.
- You set up and look after the devices exactly as the provider's P2PE Instruction Manual (PIM) says.
- A customer taps, dips, or swipes, and the terminal encrypts the card data immediately.
- The encrypted data passes through your POS and network to the provider.
- The provider decrypts it inside its secure environment and sends the transaction on for authorization.
- The approval or decline comes back to your terminal and POS, the same as any other sale.
Step 2 isn't optional paperwork. SAQ P2PE, the questionnaire for merchants using these solutions, requires that you have implemented all controls in the PIM provided by the solution provider. Read it before you sign, because it tells you what your staff will have to do.
What makes a P2PE solution "PCI-listed"?
A solution is PCI-listed when it has been validated against PCI SSC's P2PE standard and appears on the Council's list of validated P2PE solutions, published on its website. That list is the one that counts. PCI SSC's program guide says only Council-listed solutions are recognized as meeting the requirements for a merchant to reduce scope through P2PE.
Here's where sales language gets slippery. Plenty of terminals encrypt card data, and plenty of providers call their setup "encrypted" or "end-to-end." That may be good security. It isn't the same thing for PCI. PCI SSC's merchant FAQ says encryption alone is generally insufficient to take card data out of scope. If a solution isn't on the list, plan on filing the questionnaire you'd file without it.
Checking takes five minutes. Search the solution or provider name on PCI SSC's list of validated P2PE solutions, confirm the listing is current, and confirm that the exact terminal models you'll receive are part of it.
Which SAQ do you file with P2PE?
If you qualify, SAQ P2PE. It's written for merchants whose only card-handling systems are the terminals from a validated, PCI-listed P2PE solution. Its eligibility criteria come down to five conditions (PCI SSC):
- All payment processing goes through a validated, PCI-listed P2PE solution.
- The only systems in your environment that store, process, or transmit account data are that solution's payment terminals.
- You don't otherwise receive, transmit, or store account data electronically.
- Any account data you keep is on paper, such as printed receipts or reports, and wasn't received electronically.
- You've implemented every control in the solution provider's PIM.
The same document says SAQ P2PE merchants can be brick-and-mortar stores or mail and telephone order merchants, as long as all card data goes in through the P2PE terminals.
Here's how that compares with the other questionnaires for in-person sales, which our guide to what PCI compliance is explains in full:
| Your in-person setup | Likely SAQ |
|---|---|
| Terminals from a PCI-listed P2PE solution, nothing else touching card data | P2PE |
| Standalone, PCI-listed terminals on an IP connection, kept apart from other systems | B-IP |
| A POS system connected to the internet that handles card data, with no electronic storage | C |
| Card numbers stored electronically anywhere | D |
The final word isn't yours. PCI SSC sends merchants with questions about validation and reporting to their acquirer or the payment brands, so confirm which SAQ to complete with them. If you also sell online, ask how your acquirer wants that channel reported, because P2PE covers only the terminals.
How is P2PE different from end-to-end encryption and tokenization?
They solve different problems, and good setups often use more than one.
| P2PE | End-to-end encryption (E2EE) | Tokenization | |
|---|---|---|---|
| What it protects | Card data from the terminal to the provider's decryption environment | Card data in transit, as each vendor defines it | Stored card numbers, swapped for tokens |
| Who defines it | PCI SSC's P2PE standard, with a public list of validated solutions | Each vendor, in its own terms | Your gateway, the card networks, or the wallet provider |
| Effect on PCI scope | Can qualify you for SAQ P2PE | Encryption alone is generally not enough to reduce scope | Keeps card numbers out of systems that would otherwise store them |
| Where it helps most | In-person terminals | Depends on the setup | Card on file, recurring billing, refunds |
E2EE is the label to be careful with. Some setups sold as E2EE use strong encryption, and that's worth having. Without a PCI listing, though, they won't get you SAQ P2PE or the scope reduction that comes with it.
Tokenization works at the other end of the sale. EMVCo describes payment tokens as a unique alternative value that can be restricted to a specific merchant, device, or payment scenario, used instead of the card number. P2PE protects the card number on its way in. Tokens mean you never have to keep it afterwards. Our payment tokenization guide covers tokens in full.
And the EMV chip is a different job again. The chip fights counterfeit cards; it doesn't keep card data out of your systems. That's covered in our guide to what EMV is.
Does a small business need point-to-point encryption?
Not always. P2PE is optional: PCI SSC says merchants may choose to implement Council-listed solutions to reduce the scope of their PCI DSS assessment. Whether it's worth it depends on how card data moves through your business today. Our PCI compliance overview puts P2PE next to the other ways to shrink scope.
It's usually worth asking for when:
- Your terminals connect to a POS system, so card data passes through software and a network you're responsible for.
- You have several locations or checkout lanes, and every extra device adds to your PCI work.
- You've had a security scare or failed a vulnerability scan, and you want card data out of your network for good.
It's less pressing when:
- You run one or two standalone terminals on their own network. SAQ B-IP already includes only those PCI DSS requirements applicable to merchants using standalone, PCI-listed terminals, so there's less to save.
- The P2PE option would cost you more each month than the compliance work it saves.
- You sell mostly online. P2PE is about terminals. For a website, a hosted payment page does the scope-shrinking.
Visa's incentive is worth knowing. Its Technology Innovation Program can remove the annual validation requirement for eligible merchants when at least 75% of yearly transactions run through EMV chip terminals, a validated P2PE solution, or EMVCo-standard tokenization. In the US, Visa says the terminals must accept both contact chip and contactless. Notice that chip terminals alone can get you there, so P2PE isn't the only route. Before you drop anything, get your acquirer to confirm you qualify.
Two made-up examples. A gift shop in Boston with one countertop terminal on its own network files SAQ B-IP and keeps no card data anywhere else. P2PE would trim its paperwork a little, but its time is better spent inspecting the terminal and keeping it on a separate network. A restaurant group in New Orleans with POS-connected terminals at three locations is a different story. Card data crosses its POS network at every table and bar, so a listed P2PE solution could take most of that network out of scope. That's worth getting a real quote for. Our pages for retail and restaurants cover the rest of each setup.
What should you ask a provider about P2PE?
Get these answers in writing before you sign:
- Is your solution on PCI SSC's list of validated P2PE solutions, and under what name?
- Are the exact terminal models you're sending me part of that listing?
- Can I read the PIM before I sign, so I know what it asks of my staff?
- Which SAQ do you expect me to file, and will you confirm it in writing?
- When a terminal breaks, how fast is the replacement, and is it part of the same listed solution?
- What, if anything, does P2PE add to my monthly cost?
- Do you tokenize cards for refunds, card on file, or recurring billing?
- If I leave, what happens to the terminals and to any stored tokens?
Clearo's POS terminals take chip, tap, and swipe, and our PCI compliance support helps you work out which questionnaire fits the setup you actually have.
How do you switch to a P2PE setup?
Plan it like any terminal change, with one extra rule: once you switch, nothing outside the solution touches card data.
- List every place a card number enters your business today: terminals, the POS, phone orders, a back-office laptop, paper forms.
- Decide what moves onto the P2PE terminals and what stops. Phone orders keyed into a laptop either move to a P2PE terminal or end, because card data on a computer rules out SAQ P2PE.
- Get the PIM and train staff on it before the new terminals arrive.
- Swap every terminal at once if you can, and retire the old ones so nobody plugs them back in on a busy Saturday.
- Confirm your SAQ with your acquirer in writing, then file it at your next validation date.
The order matters. A shop that installs P2PE terminals but keeps one old reader at the back counter hasn't changed its questionnaire at all.
Common P2PE mistakes
- Plugging a card reader that isn't part of the solution into the same setup. Under the eligibility criteria, the listed terminals have to be the only systems handling card data.
- Treating "encrypted" on a spec sheet as P2PE.
- Skipping the PIM. SAQ P2PE assumes you follow every control in it.
- Keying a card number into a laptop "just this once." Card data on a computer breaks the eligibility criteria.
- Forgetting physical security. Requirement 9.5 of PCI DSS covers it: keep a list of your card-reading devices, inspect them for tampering, and train staff to spot it, per PCI SSC's FAQ on the requirement. Encryption doesn't help if a skimmer sits on top of the terminal. Our credit card skimmer guide shows what to look for.
Your next step
If you're paying PCI fees and aren't sure what your setup requires, send us a recent statement for a free statement review. We'll flag PCI-related charges, which our PCI compliance fee guide explains, and tell you what your terminals likely mean for your questionnaire. Or contact us to talk through your counter setup before you buy new hardware.
About this guide
Written by the Clearo Payments team. Clearo provides interchange-plus payment processing to merchants in the US and Canada, with no long-term contracts and no cancellation fees. Card network rules and laws change, so check the sources below before you act on anything here. Our editorial standards explain how we source and update guides. Questions about your own setup? Ask our team.
Sources
Official and primary sources we checked while writing this guide.
- At a Glance: P2PE v3 (PCI SSC) (listings.pcisecuritystandards.org)
- Point-to-Point Encryption (P2PE) Standard - PCI SSC (pcisecuritystandards.org)
- Payment Card Industry (PCI) Point-to-Point Encryption (P2PE) Program Guide v3.0 (listings.pcisecuritystandards.org)
- Merchant Resources - PCI Security Standards Council (pcisecuritystandards.org)
- PCI DSS v4.0.1 SAQ P2PE - PCI SSC (docs-prv.pcisecuritystandards.org)
- PCI DSS v4.0.1 SAQ B-IP - PCI SSC (docs-prv.pcisecuritystandards.org)
- FAQ: Are point-of-interaction devices required to be physically secured to meet PCI DSS Requirement 9.5? - PCI SSC (pcisecuritystandards.org)
- Payment Tokenisation (EMVCo) (emvco.com)
- Account Information Security (AIS) Program and PCI | Visa (corporate.visa.com)
- Merchant qualifications | Visa (corporate.visa.com)