PayPal vs Square: the questionnaire each path leaves a small seller
Published
This page is for the seller who sends invoices most weeks and takes a card in person now and then: a tutor, a photographer, a maker at a weekend market. PayPal and Square each handle invoices and in-person cards. The PCI difference is in what each tells you to file. PayPal's documents start online and name a different self-assessment questionnaire (SAQ) for different products. Square starts at the counter and says you need not validate to it at all, as long as every card stays inside Square.
PayPal and Square on the PCI questions
Each row is a question the standard makes you answer about a provider, with the requirement or form it maps to. Braintree, a PayPal service, sits in PayPal's column. “Ask the vendor” means the provider's own pages did not say when we read them on 2026-10-22; “Not needed” marks SAQ help Square says you will not need.
Swipe sideways for more vendors
| What you need | PayPal | Square |
|---|---|---|
| Invoice paid on the provider's page, not yoursSAQ A, card-not-present | Yes | Yes |
| Its docs name an SAQ for its online card fieldsSAQ eligibility | Yes | Ask the vendor |
| Offers card fields its docs mark SAQ ASAQ A, iframe | Yes | Ask the vendor |
| Reader in a solution on the Council's P2PE listSAQ P2PE | Yes | No |
| Helps you fill in the yearly SAQSAQ and AOC | Yes | Not needed |
| Says you need not validate to itValidation | No | Yes |
| States it charges you no PCI-compliance feeFees | Ask the vendor | Yes |
| States Level 1 status on its own siteReq. 12.8.4 | Ask the vendor | Yes |
| Runs your quarterly ASV scansReq. 11.3.2 | Ask the vendor | Ask the vendor |
| Makes your business PCI compliant by itselfReq. 12.8.1 | No | No |
Each provider in its own words
PayPal
Invoices, checkout buttons and Card Fields, Braintree for developers, and a point-of-sale app with its own readers.
FitsSellers whose sales start online and whose clients already pay with PayPal
Invoices paid on PayPal's pageYes
Braintree fields marked SAQ AYes
Card Fields marked SAQ ANo
Reader with P2PE certification, per its siteYes
Help with the yearly SAQYes
Level 1 status, on its own siteAsk the vendor
Not stated on their site when read on 2026-10-22.
Runs your ASV scansAsk the vendor
Not stated on their site when read on 2026-10-22.
PayPal says it “is fully PCI compliant, so the processing, storing, and transmitting of card data for your transactions will meet the PCI standards,” and that it “can help you complete the annual Self-Assessment Questionnaire (SAQ).” So PayPal expects a questionnaire from you; Braintree says so outright: “You are still required to complete an annual SAQ.”
Its own documents split on the online form. Card Fields send card data “through PayPal-hosted iframes,” then point you to SAQ A-EP; Braintree's Hosted Fields are “built for merchants who want SAQ A eligibility.” The Stripe vs PayPal compare walks each checkout setup.
VerdictSAQ P2PE at the counter, or an SAQ A checkout built on Braintree
Square
Readers, point-of-sale hardware, invoices and online payments, with Square as merchant of record for every sale.
FitsCounter and market sellers who keep every card inside Square's own products
Invoices paid on Square's pageYes
Names your SAQ per setupAsk the vendor
Not stated on their site when read on 2026-10-22.
Reader on the Council's P2PE listNo
Says you need not validate to itYes
No PCI-compliance fee, on its conditionYes
Level 1 status, on its own siteYes
Runs your ASV scansAsk the vendor
Not stated on their site when read on 2026-10-22.
Square lists “PCI Data Security Standard, Level 1” and says: “As the merchant of record, we maintain PCI certification so you don’t have to individually validate your compliance.” The condition sits in its PCI article: “Provided you use Square for all storage, processing, and transmission of your customers’ card data, you don’t need to take any steps to validate your PCI compliance to Square, and you don’t need to pay any PCI-compliance fees.”
That is Square's claim about what it asks of you. The standard still 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.” More in is Square PCI compliant.
VerdictA stall or counter that invoices now and then, all inside Square
Online first, counter first
Line up each provider's products in the order its PCI material covers them and the gap shows. PayPal's developer documents name an SAQ product by product, and its own card-field products land on different forms. Square names no SAQ for any setup; it gives a single statement that covers them all, with a condition.
PayPal, from the screen out
InvoicesPayPal's page
Checkout buttonsNo SAQ named
Card Fields (SDK v6)SAQ A-EP
Braintree Drop-in, Hosted FieldsSAQ A
PayPal POS Card ReaderP2PE claimed
Where its PCI story startsOnline
Square, from the counter out
Readers and POS hardwareEncrypted end to end
InvoicesSquare's page
Cards on fileKept in Square
Web Payments SDKNo SAQ named
Validation to SquareNone, on a condition
Where its PCI story startsCounter
The Council's test for the online side is short: if any element of the payment page delivered to the shopper's browser comes from the merchant's own website, SAQ A does not apply; SAQ A-EP may. The guide to every SAQ type sets the forms side by side.
Build your sales mix
Sellers on this page rarely use a single channel. Set the answers to match your week and read both paths: what each provider says about every channel you use, and the Council's form for it. Nothing here asks for a card number.
Answer for how you sell today. Pre-filled with a seller who invoices and takes cards at a market stall.
PayPal path
InvoicesNo SAQ named
PayPal emails a link; clients “choose to pay you online with their debit or credit card, or using their PayPal Wallet.” The card is typed on PayPal’s page.
In personSAQ P2PE, if listed
PayPal’s Card Reader page: “Point-to-Point Encryption (P2PE) certification gives you peace of mind.” Ask PayPal which listed solution your reader runs under.
Lines to raise with it2
Square path
InvoicesSquare asks for none
Clients “can pay an online invoice through their computer, in person, or from their mobile device.” Square’s no-validation statement holds “Provided you use Square for all storage, processing, and transmission of your customers’ card data.”
In personSquare asks for none
“All card-present payments are encrypted from end to end.” Square is not on the Council’s P2PE list, so SAQ P2PE is not the route. Square’s no-validation statement holds “Provided you use Square for all storage, processing, and transmission of your customers’ card data.”
Lines to raise with it0
The Council's form, channel by channel
- Invoices: SAQ A is for card-not-present merchants that “completely outsource all account data functions to PCI DSS validated and compliant third parties.”
- In person: SAQ A is not for face-to-face channels. SAQ P2PE is for “Merchants using only a validated, PCI-listed Point-to-Point Encryption (P2PE) solution.”
Your mix has card-present and card-not-present sales. The Council words each SAQ's criteria “for this payment channel,” so ask the provider or acquirer you report to which form, or forms, it wants.
A mix that the builder cannot settle is a question for your provider or your acquirer. The SAQ type finder runs the same channels against every SAQ, not only PayPal and Square.
The reader: a listing or a promise
For the in-person side, the useful word is “listed.” 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.
PayPal's hardware page claims “Point-to-Point Encryption (P2PE) certification” for its Card Reader, and the Council's list carries PayPal solutions under the names “Zettle by PayPal P2PE” and “PayPal Braintree In-Person.” Square says “All card-present payments are encrypted from end to end” but has no solution on the list. With Square that matters less, because Square asks you for no SAQ at all on its condition. The P2PE guide explains the listing, and Stripe vs Square compares the counter side with another listed reader.
What sits outside both
Whichever path you take, the standard leaves some things with you. 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.” For an invoice-and-market seller, these are the lines that usually remain:
Outside both providers
A list of the providers that touch card dataReq. 12.8.1
Every provider you use goes on it, PayPal or Square included, “including a description for each of the services provided.”
Who handles which requirementReq. 12.8.5
“Information is maintained about 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.”
A yearly look at each provider's PCI statusReq. 12.8.4
“A program is implemented to monitor TPSPs’ PCI DSS compliance status at least once every 12 months.”
Paper: order pads, call notes, signed slipsReq. 9.4.6
Kept in secure storage, then “cross-cut shredded, incinerated, or pulped” when no longer needed.
No security codes keptReq. 3.3.1.2
“The card verification code is not stored upon completion of the authorization process.”
Quarterly external scans, where your form has themReq. 11.3.2
SAQ A includes 11.3.2 and 11.3.2.1 for redirect and iframe pages; an invoice-and-reader seller with no website checkout should ask whether its form does.
Carried byYou
If phone orders are where your card numbers pile up, see what you may store and what you may not.
Questions sellers ask
If I use Square, do I ever fill in an SAQ?
Square says you need not validate to Square, “Provided you use Square for all storage, processing, and transmission of your customers’ card data.” The Council leaves that call to the payment side: “Compliance validation requirements are set by brands, acquirers, payment facilitators, etc.”
No paperwork for Square is not the same as nothing to protect. The standard's note to Requirement 12.8.1: “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.” Card numbers on an order pad, or a second processor beside Square, sit outside Square's condition.
Which SAQ does a PayPal invoice put me on?
PayPal's invoicing page names none. The client pays on PayPal's page, which matches the Council's description of SAQ A: “Card-not-present merchants (e-commerce or mail/telephone-order) that completely outsource all account data functions to PCI DSS validated and compliant third parties.” 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. Our SAQ A guide covers the form.
Why do PayPal Card Fields point to SAQ A-EP when Braintree's fields say SAQ A?
PayPal points the Card Fields iframe setup at SAQ A-EP even though the Council's table lets a processor's iframe fit SAQ A. Braintree's comparison table marks both Hosted Fields and Drop-in “SAQ A PCI compliant.” Ask PayPal which form it expects for the product you run, and read the guide to the SAQ types before you choose a build.
Is PayPal's card reader on the Council's P2PE list?
PayPal's hardware page says the Card Reader has “Point-to-Point Encryption (P2PE) certification.” On 2026-10-22 the Council's list carried “Zettle by PayPal P2PE” (listed under PayPal's European company) and “PayPal Braintree In-Person” (PayPal Inc). PayPal says its POS “is no longer called Zettle, but it still operates the same way.” Ask PayPal which listing covers your reader before you file SAQ P2PE; what P2PE listing means.
Do I need quarterly ASV scans with either one?
Only if your form includes them. 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 PCI DSS 11.3.2 requires external vulnerability scans at least once every three months by an ASV approved by PCI SSC. Neither provider's pages say it runs those scans for you. See what an ASV scan is.
A client reads me their card number for an invoice. Where does that leave me?
The Council's instructions give a clean route: “a mail/telephone-order merchant could be eligible for SAQ P2PE if they receive account data on paper or over a telephone, and key it directly and only into payment terminal from a validated PCI-listed P2PE solution.” Keying into a virtual terminal is SAQ C-VT ground instead; virtual terminals compared.
Either way, never keep the security code (Requirement 3.3.1.2): “The card verification code is not stored upon completion of the authorization process.” Under 9.4.6, paper with card data is “cross-cut shredded, incinerated, or pulped” when you no longer need it.
Sources
- PayPal: Industry regulation and network compliance (PCI) (paypal.com), read on 2026-10-22
- PayPal: Invoicing (paypal.com), read on 2026-10-22
- PayPal: Point-of-sale system (paypal.com), read on 2026-10-22
- PayPal: POS hardware (paypal.com), read on 2026-10-22
- PayPal: In-person payments (“no longer called Zettle”) (paypal.com), read on 2026-10-22
- PayPal Developer: JavaScript SDK v6 reference, Card fields (developer.paypal.com), read on 2026-10-22
- PayPal Developer: Standard Checkout integration (developer.paypal.com), read on 2026-10-22
- Braintree: Hosted Fields overview (developer.paypal.com), read on 2026-10-22
- Braintree: PCI compliance (developer.paypal.com), read on 2026-10-22
- Square: Payment security (squareup.com), read on 2026-10-22
- Square: PCI Compliance: Everything You Need to Know (squareup.com), read on 2026-10-22
- Square: Invoices (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 (pp. 4, 9, 10, 15, 21) (docs-prv.pcisecuritystandards.org), read on 2026-10-22
- PCI SSC: Prioritized Approach Tool for PCI DSS v4.0.1 (Req. 3.3.1.2, 9.4.6, 11.3.2, 12.8.1, 12.8.4, 12.8.5) (docs-prv.pcisecuritystandards.org), read on 2026-10-22
- PCI SSC: ASV Program Guide v4.0 r2 (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 (30 Jan 2025) (blog.pcisecuritystandards.org), read on 2026-10-22