Stripe vs Square: who carries your PCI paperwork
Published
For a small merchant choosing between Stripe and Square, the PCI question is not which one is “compliant”. Both state PCI DSS Level 1 status on their own sites. The question is what each leaves on your desk: which self-assessment questionnaire (SAQ) your setup lands on, whether your card reader is a listed P2PE solution, and who runs the scans. Stripe maps every integration to an SAQ and asks you to attest each year. Square says you need not validate to it at all, on one condition. Here is how that plays out by setup.
The PCI side, row by row
Each row is a question the standard makes you answer about a provider, with the requirement it maps to. “Ask the vendor” means the provider’s own pages did not say when we read them on 2026-10-22.
Swipe sideways for more vendors
| What you need | Stripe | Square |
|---|---|---|
| States its own PCI DSS Level 1 statusReq. 12.8.4 | Yes | Yes |
| Publishes which SAQ each setup lands onSAQ eligibility | Yes | Ask the vendor |
| Card form it hosts that can fit SAQ A onlineSAQ A | Yes | Ask the vendor |
| Validated P2PE listing on PCI SSCSAQ P2PE | Yes | No |
| Shares who owns which requirementReq. 12.8.5 | Yes | Yes |
| Runs your quarterly ASV scansReq. 11.3.2 | No | Ask the vendor |
| Phone orders without card data on your networkSAQ A (MOTO) | Yes | Ask the vendor |
| Says you need not validate to itValidation | No | Yes |
| Makes your business PCI compliant by itselfReq. 12.8.1 | No | No |
Which SAQ each setup lands on
Your SAQ follows how card data moves, not the brand on the receipt. Stripe publishes a table that maps each of its integrations to an SAQ. Square’s PCI pages do not; they say instead that you need not validate to Square if Square handles all card data. Pick the way you take cards to see both statements next to the Council’s rule. The guide to all ten SAQ types explains each form.
Stripe says
Checkout or Elements: SAQ A. Stripe says they “host all card data collection inputs within an iframe served from Stripe’s domain (not yours).”
Square says
The Web Payments SDK “produces a secure single-use payment token” for your backend. Square’s pages name no SAQ for it. Ask Square how its card field loads on your page.
The Council's rule
SAQ A only if “All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor.” SAQ A still includes the 11.3.2 external scans for redirect and iframe pages.
Stripe says
Stripe.js v2 on a form hosted on your own site: SAQ A-EP, completed annually. Stripe points you to Checkout or Elements instead.
Square says
Not covered on Square’s PCI pages. Ask the vendor.
The Council's rule
A merchant-built form that posts card data straight to the processor (“Direct Post”), or a merchant script that builds the payment page, points to SAQ A-EP.
Stripe says
Direct API: SAQ D, which Stripe calls “the most demanding of the SAQs.”
Square says
Square’s no-validation statement holds “Provided you use Square for all storage, processing, and transmission of your customers’ card data.” Card numbers on your server fall outside that condition.
The Council's rule
SAQ D for Merchants covers “All merchants not included in descriptions for the above SAQ types,” including “E-commerce merchants that accept account data on their website.”
Stripe says
Card data collected only through Stripe Terminal’s default readers: SAQ C, per Stripe. Its optional, paid “Stripe Terminal P2PE” (on the Council’s list, P2PE v3.1) comes with a pre-filled SAQ P2PE for Level 2 to 4 users.
Square says
“All card-present payments are encrypted from end to end.” Square is not on the Council’s list of validated P2PE solutions.
The Council's rule
SAQ P2PE is for “Merchants using only a validated, PCI-listed Point-to-Point Encryption (P2PE) solution.” An encrypted reader that is not listed does not qualify.
Stripe says
Manual card payments in the Dashboard: SAQ C-VT, completed annually, “for exceptional circumstances only, not routine payment processing.”
Square says
Not covered on Square’s PCI pages beyond its general no-validation statement. Ask the vendor.
The Council's rule
SAQ C-VT: “Merchants that manually enter payment account data a single transaction at a time via a keyboard into a PCI DSS validated and compliant third-party virtual payment terminal solution, with an isolated computing device and a securely connected web browser. No electronic account data storage.” No card reader may be attached to that computer.
Stripe says
Three outcomes: SAQ A with a third-party pay connector that keeps card data away from you, SAQ C-VT if staff key orders into the Dashboard, SAQ D if you store card data.
Square says
Not covered on Square’s PCI pages. Ask the vendor.
The Council's rule
SAQ A covers mail/telephone-order merchants “that completely outsource all account data functions to PCI DSS validated and compliant third parties.”
Online: what SAQ A still asks
“SAQ A” sounds like a free pass. It is the lightest form, but the Council counts the requirements that still apply, and they depend on how the payment page reaches the shopper’s browser. Stripe’s Checkout and Elements fall on the redirect and iframe lines below, by Stripe’s own mapping.
PCI DSS v4.x requirements that apply
SAQ A, no access to your own webpage14
SAQ A, redirect to the processor27
SAQ A, processor iframe on your page27
SAQ A-EP, Direct Post or merchant script139
SAQ D, any other e-commerce setupall
SourceSAQ-IG v4.0.1 r1, p. 10
SAQ A for v4.x includes Requirements 11.3.2 and 11.3.2.1 (external vulnerability scans) for merchants whose pages redirect to, or embed, a processor’s payment page. So a Stripe Checkout shop on SAQ A still books quarterly ASV scans, and Stripe’s FAQ says it does not run them. A card form your own code builds moves you to SAQ A-EP or SAQ D, the step up the SAQ A guide walks through.
At the counter: readers and P2PE
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. On 2026-10-22 the Council’s list carried “Stripe Terminal P2PE” (Stripe, Inc., P2PE v3.1) and no Square solution.
That cuts both ways. Stripe maps its default Terminal readers to SAQ C, the form for “Merchants with payment application systems connected to the Internet, no electronic account data storage.” Stripe Terminal P2PE is an optional, paid feature, and Stripe gives Level 2 to 4 users signed up for it a pre-filled SAQ P2PE. Square says its card-present payments are encrypted end to end and asks for no SAQ at all, so for a one-counter shop that keeps every card inside Square the paperwork is lighter. The P2PE guide and Square vs Clover go deeper on terminals.
Each provider on its own
Stripe
Payment processor and gateway: hosted checkout, embeddable card fields, Terminal readers and a Dashboard.
FitsOnline sellers and developers who want their SAQ named for each integration
States its own Level 1 statusYes
Names your SAQ per integrationYes
P2PE solution on the Council's listYes
Runs your ASV scansNo
Says you need not validate to itNo
Stripe says “A PCI-certified auditor evaluated Stripe and certified us to PCI Service Provider Level 1.” It is just as plain about your side: “PCI compliance is a shared responsibility” and “As a business accepting payments, you must do so in a PCI-compliant manner, and annually attest to this compliance.”
Stripe says it reads your integration method, tells you which validation form to use, and helps you complete the questionnaire in the Dashboard for Checkout, Elements, Terminal and mobile integrations. Asked “Does Stripe provide ASV scanning?”, its FAQ answers “No.”
VerdictA custom online checkout, and phone orders through a pay connector
Square
Payment processor that is the merchant of record for every sale: readers, point-of-sale hardware and online payments.
FitsCounter and mobile sellers who keep every card inside Square's own products
States its own Level 1 statusYes
Names your SAQ per setupAsk the vendor
Not stated on their site when read on 2026-10-22.
P2PE solution on the Council's listNo
Runs your ASV scansAsk the vendor
Not stated on their site when read on 2026-10-22.
Says you need not validate to itYes
Square lists “PCI Data Security Standard, Level 1” among its credentials and says: “As the merchant of record, we maintain PCI certification so you don’t have to individually validate your compliance.” That is Square’s own claim, and it comes with a condition: “Provided you use Square for all storage, processing, and transmission of your customers’ card data.”
Its PCI DSS AOC and responsibility matrix are available on request from Square’s Trust Center. On hardware it says “All card-present payments are encrypted from end to end.” Its readers are not a listed P2PE solution, so SAQ P2PE is not the route if anyone asks you for a questionnaire.
VerdictA single-terminal shop that keeps all card data inside Square
What stays your job
“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.”
PCI DSS v4.0.1, Requirement 12.8.1, applicability notes
A TPSP is a third-party service provider, and both Stripe and Square are one. Picking either moves work off your desk; it never moves the whole job. These lines stay yours whichever you sign with, and they are the same lines for the Stripe vs PayPal choice.
- Req. 12.8.1Keep a list of every provider that touches card data or could affect its security, with what each one does for you.
- Req. 12.8.4Check each provider's PCI DSS compliance status “at least once every 12 months.”
- Req. 12.8.5Record “which PCI DSS requirements are managed by each TPSP, which are managed by the entity, and any that are shared between the TPSP and the entity.”
- Req. 11.3.2Run quarterly external scans by an approved scanning vendor when your SAQ includes them; neither provider says it runs them for you.
Questions merchants ask
Does Square make me PCI compliant?
Square says that as merchant of record it maintains PCI certification “so you don’t have to individually validate your compliance.” That removes the paperwork Square would otherwise ask you for. The Council notes that validation rules are set by “brands, acquirers, payment facilitators, etc.,” so Square can decide what it asks of you.
Validation and compliance are not the same thing. Requirement 12.8.1 says: “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.” Anything that sits outside Square, such as a card number written on an order pad, is still yours to protect. More in is Square PCI compliant.
Which SAQ do I file with Stripe Checkout?
Stripe maps Checkout and Elements to SAQ A. Two things come with it: SAQ A for v4.x includes Requirements 11.3.2 and 11.3.2.1 (external vulnerability scans) for merchants whose pages redirect to, or embed, a processor’s payment page, and the merchant must confirm “that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” See the SAQ A guide.
Do I still need ASV scans if I use Stripe?
If your SAQ includes 11.3.2, yes: PCI DSS 11.3.2 requires external vulnerability scans at least once every three months by an ASV approved by PCI SSC. Stripe’s FAQ says it does not provide ASV scanning: you hire an approved vendor and keep the reports, which go to Stripe only if it asks. What an ASV scan covers.
Can I use SAQ P2PE with Square readers?
Not on the Council’s list as read on 2026-10-22: Square has no validated P2PE solution there. Only a solution on the Council’s list qualifies a merchant for SAQ P2PE; an “encrypted reader” that is not listed does not. Stripe Terminal P2PE is listed: Stripe’s default readers lead to SAQ C, and its optional, paid Terminal P2PE comes with a pre-filled SAQ P2PE for Level 2 to 4 users. How P2PE works.
I use both. Do I validate twice?
Each way you take cards is assessed for what it is. Stripe’s guide says that if you use more than one of its methods, “you must illustrate compliance for them separately.” Before you start an SAQ, confirm with the organization you submit it to (usually your acquirer, the merchant bank) that you are eligible for it. The SAQ type finder sorts a mixed setup.
Sources
- Stripe: Security at Stripe (docs.stripe.com), read on 2026-10-22
- Stripe: Integration security guide (docs.stripe.com), read on 2026-10-22
- Stripe: A guide to PCI compliance (stripe.com), read on 2026-10-22
- Stripe: PCI compliance FAQ (support.stripe.com), read on 2026-10-22
- Stripe: PCI compliance for Stripe Terminal (SAQ C, pre-filled SAQ P2PE) (support.stripe.com), read on 2026-10-22
- Square: Payment security (squareup.com), read on 2026-10-22
- Square: Trust Center (PCI DSS AOC and Merchant Responsibility Matrix, on request) (trust.squareup.com), read on 2026-10-22
- Square: PCI Compliance: Everything You Need to Know (squareup.com), read on 2026-10-22
- Square: Web Payments SDK overview (developer.squareup.com), read on 2026-10-22
- PCI SSC: SAQ Instructions and Guidelines, PCI DSS v4.0.1 r1 (docs-prv.pcisecuritystandards.org), read on 2026-10-22
- PCI SSC: Prioritized Approach Tool for PCI DSS v4.0.1 (Req. 11.3.2, 12.8.1, 12.8.4, 12.8.5) (docs-prv.pcisecuritystandards.org), read on 2026-10-22
- PCI SSC: Validated P2PE Solutions list (pcisecuritystandards.org), read on 2026-10-22
- PCI SSC: At a Glance, P2PE v3 (docs-prv.pcisecuritystandards.org), read on 2026-10-22
- PCI SSC blog: Important updates for merchants validating to SAQ A (blog.pcisecuritystandards.org), read on 2026-10-22