What is P2PE? Validated point-to-point encryption vs an “encrypted” reader

Validated P2PE vs “end-to-end encrypted”

Both phrases describe a reader that scrambles the card the moment it is tapped, dipped or swiped. The difference is who vouched for it. A P2PE solution on the Council's list was assessed against the P2PE standard by a qualified P2PE assessor, ships with an instruction manual for you, and has to renew its listing on a schedule. “End-to-end encryption” is the vendor's own description, and nobody outside the vendor checks it on your behalf.

The difference shows up inside a single vendor. Stripe sells both kinds for its Terminal readers and spells out the split on its own help page:

Stripe adds that its P2PE is “an optional, paid feature” and that “A third party validates it.” The Council's list carries “Stripe Terminal P2PE”; it does not carry Stripe's default encryption. The Stripe PCI guide covers which SAQ Stripe names for each route.

Square says “All card-present payments are encrypted from end to end” and that “no unencrypted payment data touches your device or application.” That may well be true, and it is still not a listing: the Council's export held no entry for Square on 2026-10-22. A PCI-listed P2PE solution “can significantly help to reduce the PCI DSS validation effort of a merchant's cardholder data environment.” Only a solution on the Council's list qualifies a merchant for SAQ P2PE; an “encrypted reader” that is not listed does not. The Square vs Clover comparison walks through what that means at a retail counter.

Source: Square: Payments security, read on 2026-10-22

How point-to-point encryption works

The Council's definition is short: “A PCI-listed point-to-point encryption solution includes a combination of secure devices, applications and processes that encrypt cardholder data from a PCI-approved point-of-interaction (POI) device through to a secure decryption environment.” The two points are the card device on your counter and the provider's decryption environment. Everything between them, including your till, your router and the shop Wi-Fi, only ever carries cipher text.

The device matters as much as the encryption. P2PE needs a PCI-approved POI device with SRED (secure reading and exchange of data), the hardware feature that protects the card inside the terminal and encrypts it before it leaves. The listing names the exact device models that belong to the solution.

Source: PCI SSC, Assessment Guidance for Non-Listed Encryption Solutions, §2, read on 2026-10-22

What the dates on a listing mean

A listing is not permanent. Under the Program Guide, a listed solution “remains Validated for 3 years based on the date of the most recent Acceptance,” and the provider has to file an annual revalidation at year 1 and year 2. At the end of the three years it either passes a reassessment, which is a new full assessment, or it lapses.

A missed date does not remove a solution overnight. The Council colours the date orange for up to 90 days, then red for up to 90 more. Only after 180 days does the solution move to the Expired list, and that is the line that matters for you.

How to check a P2PE listing

The list is public, and it is the only proof that counts for SAQ P2PE. Check it yourself rather than trusting a sales page or a screenshot someone sends you.

What a real listing looks like

Here is how the payment brands this site compares stood on the Council's export. Square, Helcim and Stax had no entry, and PayPal appeared under its European company and under PayPal Inc. The Clover vs Toast comparison and the PayPal vs Square comparison read these same entries for restaurants and part-time sellers.

Check the dates on any listing

What SAQ P2PE leaves you

SAQ P2PE is the questionnaire a listed solution opens up: “Merchants using only a validated, PCI-listed Point-to-Point Encryption (P2PE) solution. No access to clear-text account data and no electronic account data storage.” The word that trips people up is “only.” You confirm every one of these:

Phone and mail orders can fit

SAQ P2PE is not only for the counter. The Council gives a phone-order route, with a condition:

Key the same phone order into a browser on the office PC and you are on a different form: SAQ C-VT, if the virtual terminal and the computer meet that form's conditions. That is also where P2PE and SAQ SPoC part ways: SAQ P2PE covers “Card-present or card-not-present (mail/telephone order) merchants,” while SPoC, the questionnaire for a phone or tablet with a listed secure card reader, is for attended card-present sales only. The phone payment comparison covers the other ways to take cards over the phone.

Source: PCI SSC, SAQ Instructions v4.0.1 r1, pp. 7, 19 and 22, read on 2026-10-22

What stays yours

On the provider point the standard is blunt: “The use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity's responsibility for its own PCI DSS compliance.” That holds for your P2PE provider as much as for your web host.

If your reader encrypts but is not listed

Many readers encrypt the card without a P2PE listing. The Council calls these non-listed encryption solutions, and it says plainly who decides what they are worth to you:

NESA stands for Non-listed Encryption Solution Assessment: a write-up by a P2PE assessor of how close the solution comes to the P2PE standard. The same guidance tells merchants to “request NESA documentation from their non-listed encryption solution provider upon installation and on an annual basis thereafter.” Not every provider has one. If yours does not, you are back to choosing an SAQ by how card data moves through your business, and the encryption is something you describe to your acquirer, not a form you qualify for.

Some providers make their own case for what their sellers need to do. Square does, and the guide to Square's PCI claims sets beside the Council's rules. The scope checker shows which of your systems handle card data either way.

P2PE on one receipt