Stripe vs PayPal: the checkout you build decides your SAQ
Published
For a small online shop, Stripe and PayPal both hold their own PCI validation, so the question is not which one is “PCI compliant.” It is which questionnaire your own checkout lands you on. That depends on where the shopper types the card number: on the provider's page, in the provider's iframe on your page, or in a form your site builds. Each provider offers all three, and each documents the outcome differently.
Where the card number is typed
The Council's rule 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. Redirect to the processor's page, or an iframe from the processor, can fit SAQ A. Its own table counts what each setup costs you in requirements:
No access to your own webpageSAQ A: 14
The processor hosts and runs the whole page
Redirect to the processorSAQ A: 27
Stripe Checkout's hosted page, PayPal's window
Processor iframe on your pageSAQ A: 27
Stripe Elements, Braintree Hosted Fields
Direct Post or a merchant scriptSAQ A-EP: 139
Your own card form with Stripe.js v2
Any other setupSAQ D: All
Card numbers through your own server
The jump from 27 to 139 is the whole argument of this page. A card number that reaches your own server puts you on SAQ D, the full questionnaire. The ten SAQ types are explained one by one in our guide.
Find your setup
Pick the way your shop takes cards today. The left column is what the provider's own docs name; the result sets it beside the Council's table and flags where the two do not line up.
Right column: what the provider's own docs say.
Stripe Elements
Card typed intoStripe's iframe fields inside your own checkout page
Provider namesSAQ A
Council's tableThe processor's iframe on your page
Requirements counted27
“Alternatively, both Checkout and Elements allow you the flexibility and customizability of a self-hosted form, while also meeting PCI eligibility for the SAQ A.”
Quarterly ASV scans: Yes. SAQ A includes 11.3.2 and 11.3.2.1 for redirect and iframe pages.
Check this: Your page still loads Stripe.js and your own scripts. SAQ A now asks you to confirm your site is not susceptible to attacks from scripts.
Likely formSAQ A
Selling in person too, or by phone? The SAQ type finder walks every channel, not only the online one.
The PCI table
PayPal gets two columns because its two developer products are documented differently: PayPal's own Card Fields point to SAQ A-EP, while Braintree's fields are marked SAQ A.
Swipe sideways for more vendors
| What you need | Our pickStripe | PayPal | Braintree |
|---|---|---|---|
| Hosted payment page, no card field on your siteSAQ A, redirect | Yes | Yes | Ask the vendor |
| Card fields in the provider's iframe on your pageSAQ A or A-EP | Yes | Yes | Yes |
| Docs say the iframe setup fits SAQ ASAQ-IG p. 10 | Yes | No | Yes |
| Docs name the form for cards through your serverSAQ D | Yes | Ask the vendor | Ask the vendor |
| Helps you fill in the yearly SAQSAQ and AOC | Yes | Yes | Ask the vendor |
| States Level 1 service-provider status on its own siteReq. 12.8.4 | Yes | Ask the vendor | Ask the vendor |
| Validated P2PE listing for in-person salesPCI SSC P2PE list | Yes | Yes | Yes |
| Runs your quarterly ASV scans for youReq. 11.3.2 | No | Ask the vendor | Ask the vendor |
For counter sales the two companies sit closer together: both have solutions on the Council's P2PE list. The counter-side comparison is in Stripe vs Square and PayPal vs Square. If your shop runs on a hosted platform instead, Shopify Payments vs Stripe sets that choice out.
Stripe and PayPal, one by one
Stripe
A payment platform whose online options run from a hosted page to a raw card API.
FitsShops that want the SAQ named for every setup
Hosted page (Checkout)Yes
Iframe card fields (Elements)Yes
Docs name SAQ A for bothYes
Docs name SAQ D for the Direct APIYes
SAQ help in the DashboardYes
Level 1 service provider, on its own siteYes
Runs your ASV scansNo
Stripe says a PCI-certified auditor certified it “to PCI Service Provider Level 1,” and that it tells each user “which PCI validation form to use.” For Elements, Checkout, Terminal and its mobile libraries it helps you complete the SAQ in the Dashboard, and its guide offers some of those users “prefilled SAQs and guided flows.”
The one setup that changes everything is the Direct API: Stripe's security guide says a business handling card data directly “might be required to meet more than 300 security controls in PCI DSS.” Scans stay with you: asked “Does Stripe provide ASV scanning?”, its PCI FAQ answers “No.” More in is Stripe PCI compliant.
VerdictBest overall for a small online shop
PayPal
PayPal's checkout buttons and Card Fields, plus Braintree, a PayPal service.
FitsShops whose buyers already pay with PayPal
Hosted checkout window (buttons)Yes
Iframe card fields (Card Fields)Yes
Docs name SAQ A for Card FieldsNo
Braintree docs name SAQ A for its fieldsYes
Help with the yearly SAQYes
Level 1 service provider, 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” and “can help you complete the annual Self-Assessment Questionnaire (SAQ).” Its v6 SDK reference says Card Fields send card data through “PayPal-hosted iframes,” then points you to SAQ A-EP for the PCI side.
Braintree's docs mark both Drop-in and Hosted Fields “SAQ A PCI compliant.” If you sell in person as well, PayPal and Braintree both have solutions on the Council's list; see what P2PE listing means.
VerdictBest for shoppers who pay with a PayPal account, and for a store already built on Braintree
What stays your job
Both providers carry their own PCI validation. That does not carry over to you. 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.”
Before you file
- 01Name your setup. Hosted page, iframe fields, your own form, or the API. Use the picker above.
- 02Check every element of the payment page. SAQ A needs: “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.”
- 03Confirm your site resists script attacks. The SAQ A criterion: “The merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”
- 04Book the quarterly ASV scans. 11.3.2: at least once every three months, by an ASV approved by PCI SSC.
- 05Confirm the form, then file it. Ask the organization you submit it to before you start.
Repeatsevery year
Questions
Does using Stripe or PayPal make my shop PCI compliant?
No. The standard says so in 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.”
Braintree says the same in its own words: “integrating with us does not automatically fulfill your PCI compliance requirements.” Stripe tells merchants to “annually attest to this compliance.”
Do I still need quarterly ASV scans if I qualify for SAQ A?
If your pages redirect to, or embed, the processor's payment page, yes. 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. PCI DSS 11.3.2 requires external vulnerability scans at least once every three months by an ASV approved by PCI SSC. The Council's scanners are listed in our directory of approved scanning vendors.
Why does PayPal point Card Fields at SAQ A-EP when Stripe says Elements fits SAQ A?
Neither page explains the other. The Council's test is whether every element of the payment page comes from the processor: 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. 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.
What changed in SAQ A in January 2025?
The Council removed “PCI DSS Requirements 6.4.3 and 11.6.1 for payment page security, and Requirement 12.3.1 for a Targeted Risk Analysis to support Requirement 11.6.1,” and added an eligibility criterion that the merchant “confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s).” The January 2025 SAQ A took effect on 31 March 2025, when the October 2024 SAQ A was retired. See our SAQ A guide for the full form.
I take a few phone orders. Can I key them into the Stripe Dashboard?
Stripe maps Dashboard entry to SAQ C-VT and says manual card payments there are “possible for exceptional circumstances only, not routine payment processing.” If phone orders are routine for you, compare PCI compliant virtual terminals.
I run Stripe and PayPal on the same shop. Which form do I file?
Each provider only describes its own setups. The Council does not decide this either: “Compliance validation requirements are set by brands, acquirers, payment facilitators, etc.” Ask each provider which SAQ it wants from you, and file what they ask for.
Sources
- Stripe: PCI compliance guide (stripe.com), read on 2026-10-22
- 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 Support: PCI compliance FAQ (support.stripe.com), read on 2026-10-22
- Stripe Support: Enabling access to raw card data APIs (support.stripe.com), read on 2026-10-22
- PayPal: PCI compliance (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
- PCI SSC: SAQ Instructions and Guidelines v4.0.1 r1 (April 2025) (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
- PCI SSC: Prioritized Approach Tool for PCI DSS v4.0.1 (Requirements 12.8.1 and 12.8.4) (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 (pcisecuritystandards.org), read on 2026-10-22