Yes, Stripe Terminal reduces your PCI scope, and you choose between two levels. By default, Terminal encrypts card data end to end at the reader (E2EE), so card numbers never pass through your systems in readable form, and Stripe says Terminal merchants validate with the in-person SAQ C rather than the full SAQ D. If you are a Level 2–4 merchant and sign up for Stripe’s point-to-point encryption (P2PE) option, you can validate with the even shorter SAQ P2PE, because a PCI-listed P2PE solution takes most of your card-handling environment out of scope. Stripe pre-fills both questionnaires in the Dashboard under Compliance Settings. This guide walks a Terminal merchant through that choice, plus the Connect-platform question of who attests.
We build and operate Stripe Connect platforms: BizSwoop runs its own at payments.bizswoop.app, and Jovvie has shipped in-person Stripe Terminal payments for WooCommerce merchants since 2016, so SAQ selection, the P2PE decision, and the Connect attestation split are things we deal with in production. Every claim below cites Stripe’s PCI documentation or the PCI Security Standards Council and was re-checked in November 2026. This is general information, not legal or compliance advice; confirm your obligations with your acquirer or a Qualified Security Assessor.
Key Takeaways
- Terminal shrinks scope; it doesn’t remove PCI. Every card-accepting business still validates compliance each year, but Terminal-only merchants use the in-person SAQ C instead of SAQ D.
- E2EE is on by default. Card data is encrypted inside the reader and decrypted only at Stripe, so your POS, store, ERP and network never see a full card number.
- P2PE is an opt-in for Level 2–4 merchants. Signing up for Stripe Terminal P2PE lets you use SAQ P2PE, the shortest in-person questionnaire, for an extra 5¢ per authorization.
- Stripe pre-fills the paperwork. Pre-filled SAQ C and SAQ P2PE documents for Terminal transactions are in the Dashboard under Compliance Settings.
- Keying cards changes your SAQ. Manually entering cards in the Dashboard falls under SAQ C-VT, which Stripe says is for exceptional cases only.
- On Connect, the charge type decides who owns the readers. With direct charges, Terminal resources belong to the connected account; with destination charges, they belong to the platform.
Does Stripe Terminal reduce PCI scope?
Stripe Terminal reduces PCI scope because the reader encrypts card data at the point of capture, so cardholder data never enters your servers, applications, or network in readable form, and PCI scope is defined by where cardholder data is stored, processed, or transmitted.
PCI DSS applies to every business that accepts cards. What varies is how much of the standard you attest to, which depends on your scope: the systems, people, and processes that touch cardholder data. Stripe’s PCI compliance guide is a plain-language primer on the standard and the merchant levels.
Terminal shrinks the flow. When a customer taps, dips, or swipes at a Stripe reader (the M2, S700, S710, T600, or Tap to Pay on a phone), the card data is encrypted inside the reader and travels encrypted to Stripe. Your point-of-sale app, your WooCommerce store, your ERP and your network never see a full card number. That is why Stripe says that if you collect card data only through Terminal, you can validate using SAQ C (Stripe Terminal and PCI compliance).
What Terminal does not do is make PCI disappear. You still validate every year, and if you also take payments in other ways, such as online checkout, you must validate those channels too. Stripe itself is a PCI Level 1 service provider certified annually by an independent Qualified Security Assessor, but that covers Stripe’s systems, not the merchant attestation that is yours to sign.
Which SAQ does a Stripe Terminal merchant complete?
A Terminal merchant completes SAQ C by default, or SAQ P2PE after signing up for Stripe’s P2PE option; P2PE eligibility, per Stripe, is for Level 2–4 merchants.
| SAQ C (default Terminal) | SAQ P2PE (P2PE opt-in) | |
|---|---|---|
| When it applies | Stripe Terminal with default end-to-end encryption | Readers on Stripe Terminal P2PE (Level 2–4 merchants) |
| Relative length | Longer: covers controls for your connected payment environment | The shortest in-person SAQ |
| Card data in your environment | Encrypted at the reader; your POS environment is still connected and in scope for some controls | Encrypted by a PCI-listed P2PE solution; most of your environment is out of scope |
| Extra Stripe fee | None | +5¢ per authorization (US) |
| What you commit to | Network, access and patching controls for the connected POS environment | Using the P2PE solution as its instruction manual specifies and protecting the devices |
| Pre-filled by Stripe | Yes, under Compliance Settings | Yes, under Compliance Settings |
If you run standard Terminal readers alongside your POS software, you are an SAQ C merchant, and Stripe’s pre-filled document means you are reviewing rather than authoring it. If your acquirer, board, or risk appetite justifies going further, signing up for P2PE makes you an SAQ P2PE merchant. The authoritative questionnaires are published in the PCI Security Standards Council document library.
Your PCI level (1 to 4) is set by annual transaction volume, not by your SAQ. Per Stripe’s guide, Level 1 means more than 6 million Visa or Mastercard transactions (or 2.5 million American Express) a year and requires a Report on Compliance from a Qualified Security Assessor. Stripe says it notifies Terminal merchants before they reach the Level 1 threshold. The SAQ C versus SAQ P2PE choice is the everyday reality for Level 2–4 merchants, who are most Terminal deployments.
What changes between E2EE and P2PE on Stripe Terminal?
E2EE and P2PE both encrypt the card at the reader; the difference is that P2PE is a formally validated PCI program with audited device handling, and that validation is what unlocks SAQ P2PE.
- E2EE (end-to-end encryption) is what Stripe Terminal provides by default: card data is encrypted inside the reader and decrypted only at Stripe. It is strong protection, but it describes an architecture, not a certification, and on its own it supports SAQ C.
- P2PE (point-to-point encryption) is a PCI SSC-listed solution. It has been validated by an assessor and comes with an instruction manual that tells the merchant how to deploy and handle the devices. Because encryption, key management and device handling are audited as a solution, most of the merchant environment falls out of scope. Stripe’s P2PE explainer covers the model.
How we frame the choice for merchants:
- Default E2EE and SAQ C suit most retail, hospitality and service merchants. It needs no sign-up, costs nothing extra, and the pre-filled SAQ C keeps the effort modest for a typical shop.
- P2PE is worth it when your audit burden is real: higher volumes, a security-conscious board, an acquirer that rewards P2PE, or a regulated industry where a smaller attestation surface is a genuine risk reduction.
- The ongoing cost is process plus 5¢. Beyond the per-authorization fee, P2PE means following the instruction manual for the life of the deployment: device inventory, tamper checks, and chain-of-custody handling.
P2PE only reduces scope if you operate it correctly. A P2PE program on paper that nobody follows is worse than a well-kept SAQ C, because it misrepresents your posture to an assessor.
Is Stripe Terminal PCI compliant out of the box?
Stripe’s side is: Stripe is a PCI Level 1 service provider, certified annually by an independent assessor, and Terminal readers encrypt card data by default. The merchant side is not automatic: you still complete and submit an annual validation.
The compliant half is the legitimate basis for the “Stripe handles PCI” shorthand: you don’t certify the readers or the processing rails. The half the shorthand leaves out is that you, the business taking the payment, are a merchant under PCI DSS and validate your own environment every year. Terminal makes that an SAQ C or SAQ P2PE, and Stripe pre-fills it, but you still review, confirm and submit it, and keep your connected POS environment patched, access-controlled and segmented as the SAQ requires. “Compliant out of the box” is true of Stripe’s equipment and infrastructure and false of your obligation to attest.
One trap to avoid: if staff key card numbers into the Stripe Dashboard, that channel falls under SAQ C-VT, which Stripe’s guide says is meant for exceptional cases, not routine processing. Keying also costs more than tapping (see our guide to card-present rates).
Taking in-person payments in a WooCommerce store? Jovvie runs on Stripe Terminal, so card data stays encrypted at the reader and out of your store.
Who attests for PCI on a Stripe Connect platform?
On a Connect platform that gives Terminal readers to its merchants, PCI is a shared responsibility, and the charge type you choose decides which account owns the Terminal resources, which in turn shapes whose environment the in-person card flow touches.
Stripe’s Use Terminal with Connect guide sets out the ownership:
| Direct charges | Destination charges | |
|---|---|---|
| Who owns Locations, Readers and PaymentIntents | The connected account | The platform |
| How API calls identify the merchant | Platform key plus the Stripe-Account header | Platform key, with the connected account identified in metadata and on_behalf_of |
| Connection tokens | Created with the Stripe-Account header for the connected account | Created on the platform account, optionally scoped to a Location |
| Who pays Stripe fees, refunds and chargebacks | The connected account | The platform (with an application fee and a transfer to the connected account) |
| Typical fit | Each merchant owns its Stripe relationship | The platform centralizes the payment experience |
Stripe also has a private preview of platform-owned readers with direct charges, where the platform owns Locations and Readers and connected accounts own the PaymentIntents.
Our reading, which you should confirm with your QSA: with destination charges, the platform owns the Terminal API surface (readers, locations, connection tokens, PaymentIntents), so the platform’s own assessment needs to cover that integration even though the readers sit in merchants’ locations. With direct charges, reader ownership sits with each connected account, and more of the in-person attestation follows it. Neither is “more compliant”; they distribute the work differently, and you want to know which one you have chosen before an assessor asks. The same decision also sets who bears Stripe’s fees, so model the compliance and fee consequences together; we cover the multi-tenant architecture in a separate guide.
What does a PCI auditor ask a Terminal merchant for?
An auditor won’t ask to see card numbers; they ask you to show you never stored them, that your encryption is what you claim, and that your records reconcile, so a Terminal merchant’s evidence is about demonstrating scope.
- Proof that card data never entered your systems. Terminal’s encryption is the reason; your evidence is your device inventory and application logs, databases and backups that contain Stripe IDs, not card numbers.
- Transaction records that reconcile. Every Terminal charge produces a PaymentIntent and balance transaction in Stripe, and your receipts and accounting reference those IDs. Reconciling your books to Stripe doubles as evidence that the money trail is intact and card-data-free.
- Device inventory and tamper checks. Good practice under SAQ C and required under P2PE by its instruction manual: list every reader, its location and serial number, and inspect it for tampering on a schedule. Physical custody of readers is the control an auditor cares most about.
- A current SAQ. Pull the pre-filled SAQ from Compliance Settings, review it, and keep it dated within the last twelve months.
Receipts are not a worry: card receipts show a masked card number (the last four digits) and the card brand, never the full number, so printed and emailed receipts don’t bring card data into scope.
Why do healthcare and education merchants choose P2PE?
Healthcare, education, and government merchants often choose P2PE because a smaller PCI footprint compounds with their other compliance obligations. A dental office collecting a copay is both a PCI merchant and a HIPAA-covered entity, so fewer in-scope systems mean fewer places where payment data and protected health information could mix.
P2PE does not satisfy HIPAA; the two govern different data. The benefit is a smaller, cleaner environment to defend across two audits. For these merchants, the P2PE decision is less about a shorter questionnaire and more about keeping card data out of systems that already carry sensitive records; our PCI compliance guide for nonprofits covers similar in-person scenarios. If you are comparing software, a POS for Stripe that keeps card capture on Terminal readers preserves this scope reduction.
Frequently asked questions
Does Stripe Terminal reduce PCI scope?
Yes. Terminal encrypts card data at the reader so it never enters your systems in readable form, and Stripe says merchants who collect card data only through Terminal can validate with SAQ C instead of SAQ D. Level 2–4 merchants who sign up for Stripe Terminal P2PE can use the shorter SAQ P2PE.
Which SAQ do I use for Stripe Terminal, SAQ C or SAQ P2PE?
SAQ C by default, because Terminal’s standard end-to-end encryption supports it. SAQ P2PE if you are a Level 2–4 merchant signed up for Stripe Terminal P2PE. Stripe provides pre-filled versions of both for Terminal transactions in the Dashboard under Compliance Settings.
Is Stripe Terminal PCI compliant out of the box?
Stripe’s side is: Stripe is a PCI Level 1 service provider certified annually by an independent assessor, and Terminal encrypts card data by default. You, the merchant, still complete an annual validation, usually SAQ C or SAQ P2PE, so “compliant out of the box” describes Stripe’s infrastructure, not your attestation.
What is the difference between E2EE and P2PE on Stripe Terminal?
E2EE is Terminal’s default encryption: card data is encrypted at the reader and decrypted only at Stripe. P2PE is a PCI-validated program built on that kind of encryption, with audited device handling and an instruction manual, which is what qualifies you for SAQ P2PE. In the US, Stripe charges 5¢ per authorization for optional P2PE.
Who is responsible for PCI compliance on a Stripe Connect platform?
It is shared. Stripe covers its own infrastructure as a Level 1 service provider, the platform is responsible for its own systems and integration, and each connected account is a merchant with its own obligations. With direct charges the connected account owns the Terminal resources; with destination charges the platform does, so confirm with your assessor how that maps to each party’s validation.
Does a Stripe Terminal receipt show the full card number?
No. Card receipts show a masked card number with only the last four digits, plus the card brand, so printed and emailed receipts don’t expose a full card number.
Want your PCI scope mapped before an assessor does it for you?
If you are rolling out Stripe Terminal across a platform, multiple locations, or a regulated business, talk to a Jovvie advisor. We operate a Stripe Connect platform in production and will tell you which scope-reduction path is worth the operational cost, including when the default SAQ C is the right answer.
Sources: Stripe Terminal and PCI compliance · Stripe PCI compliance guide · Stripe P2PE explainer · Stripe pricing · Use Terminal with Connect · PCI SSC document library. This article is educational and is not legal or compliance advice.
