Stripe PCI Compliance: What SaaS Founders Still Own Under PCI DSS

Short answer: Yes, you still need PCI compliance if you use Stripe. Stripe is a PCI Level 1 service provider, but that covers Stripe's systems, not yours. You validate your own compliance yearly, usually with a Self-Assessment Questionnaire. Checkout, Elements or mobile SDKs typically mean SAQ A; handling raw card data means SAQ D.

Related guides:

• Shopify PCI compliance: what merchants still own
• A deep dive into SAQ types and common pitfalls
• PCI for SaaS

Key takeaways

• Stripe's PCI certification covers Stripe. As the business accepting payments, you must accept them in a PCI-compliant way and attest to that every year.
• Your Stripe integration type drives your paperwork: Checkout, Elements and the mobile SDKs typically map to SAQ A, card fields hosted on your own page to SAQ A-EP, and passing raw card numbers to the API to SAQ D.
• In January 2025 the PCI Security Standards Council removed the payment page script requirements (6.4.3 and 11.6.1) from SAQ A and replaced them with an eligibility criterion about your site not being susceptible to script attacks.
• Your acquirer and the card brands decide how you validate. Stripe's Dashboard shows the documents it needs from you.
• The work you own is mostly about your website, your Stripe account, your people and your vendors.

---

Is Stripe PCI compliant?

Yes, Stripe says it is certified annually by an independent Qualified Security Assessor as a PCI Level 1 Service Provider.

In its integration security guide, Stripe describes PCI compliance as "a shared responsibility" that applies to both Stripe and your business. Stripe's assessment covers the infrastructure where card numbers are collected, stored and processed when you use its products. It does not cover your web app, your admin accounts, your staff or the scripts you load on your pages.

So when a customer or acquirer asks whether you are PCI compliant, "we use Stripe" is the start of the answer, not the whole answer. (Collecting Stripe's documents for a SOC 2 vendor review is a different job, covered in Stripe SOC 2 evidence.)

Do I need PCI compliance if I use Stripe?

Yes, any business that accepts card payments is expected to comply with PCI DSS, and Stripe's security guide states that you must annually attest to your compliance.

The good news is that a well-chosen integration keeps the scope small. Stripe's PCI compliance guide notes that Checkout, Stripe.js and Elements host the card inputs in an iframe served from Stripe's domain, so card numbers never touch your servers. Stripe also says it offers prefilled SAQs and guided flows in the Dashboard for smaller users on these integrations.

Each year you confirm which SAQ applies, complete it, sign the Attestation of Compliance (AOC), submit it where you are asked to, and keep those controls running all year.

Which SAQ applies to your Stripe integration?

The SAQ you use depends on where card data is entered and whether it ever passes through your systems.

The table follows the mapping in Stripe's PCI compliance guide. Treat it as a starting point: your acquirer, and the eligibility criteria printed in each PCI SSC SAQ, have the final word.

Stripe integration	How card data flows	Typical SAQ
Stripe Checkout or Payment Links (Stripe-hosted payment page)	Customer is sent to a page Stripe hosts and enters card data there	SAQ A
Stripe Elements or embedded Checkout (iframe on your page)	Card fields are iframes served from Stripe's domain inside your page	SAQ A
Stripe mobile SDKs	Card numbers go from the customer's device directly to Stripe	SAQ A
Card fields hosted on your own page (for example, the legacy Stripe.js v2 pattern)	Your page renders the payment form and controls what runs on it, though Stripe receives the card data	SAQ A-EP
Direct API calls with raw card numbers	Your servers receive and pass card data to Stripe's API	SAQ D
Stripe Terminal for in-person payments	Card data is captured by Stripe's readers	Confirm with Stripe and your acquirer; depends on reader and setup
Staff keying card details into the Stripe Dashboard	Manual entry through a web-based virtual terminal	SAQ C-VT

Two things push SaaS teams out of SAQ A without anyone noticing:

• "Temporary" raw card handling. Taking card numbers by email, support ticket or spreadsheet to "fix a failed payment" brings those systems into scope.
• Custom payment forms. Replacing Elements with a homegrown form likely moves you to SAQ A-EP or SAQ D. SAQ A-EP covers merchants whose website does not receive account data but controls how customers or their data reach the processor.

What changed in SAQ A for PCI DSS v4.0.1?

In January 2025 the PCI SSC removed the payment page script requirements from SAQ A and added a new eligibility criterion about script attacks instead.

On 30 January 2025 the Council announced that the updated SAQ A no longer includes Requirements 6.4.3 and 11.6.1 for payment page security, or Requirement 12.3.1 for the targeted risk analysis that supports 11.6.1. In their place, merchants must confirm that their "site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)." The Council said the January 2025 SAQ A replaces the October 2024 version from 31 March 2025.

A month later, FAQ 1588 clarified who the criterion applies to:

• It applies to merchants that embed a processor's payment page or form on their own page, for example with one or more iframes. For a Stripe customer, that is the Elements or embedded Checkout pattern.
• It does not apply to merchants that redirect customers to the processor's page, such as with an HTTP 30x redirect, a meta redirect tag or a JavaScript redirect, or that fully outsource payment functions. For a Stripe customer, that is the hosted Checkout or Payment Links pattern.

According to the FAQ, embedded-form merchants can meet the criterion in two ways: by protecting their page using techniques such as, but not limited to, those in Requirements 6.4.3 and 11.6.1, or by getting confirmation from their PCI DSS compliant payment processor that its embedded solution includes such techniques when implemented as instructed.

For an Elements user, that means keeping third-party scripts on checkout and billing pages to a minimum (Stripe's security guide recommends this and publishes Content Security Policy directives for its products), and knowing which FAQ 1588 route you rely on, with evidence, before you sign.

For the wider set of v4 changes, see our PCI DSS v4.0 changes guide.

What do you own and what does Stripe own?

Stripe owns the security of the systems that capture and process card data; you own everything around them.

Area	Stripe	Your business
Card data capture in Checkout, Elements iframes and mobile SDKs	Owns	Integrates it as documented
Storage, processing and transmission of card numbers	Owns	Does not handle card numbers on SAQ A integrations
Your web app pages that host or link to payment forms		Owns: TLS, script control, change management
Stripe Dashboard accounts, roles and MFA	Provides the tools	Configures them and reviews access
API keys and webhook endpoints	Provides signing and key controls	Protects secret keys and verifies webhook signatures
Staff awareness, phishing and vendors near the payment flow		Owns
Annual SAQ and AOC	Provides guided and prefilled flows	Completes, signs and submits

Who decides how you validate?

Your acquirer and the card brands decide how you validate, not the PCI SSC and not your own preference.

The PCI SSC's merchant resources page states that whether a small merchant must validate compliance is determined by the individual payment brands, and directs merchants to their acquirer or the brands for specifics. When Stripe is your processor, the documentation requirements for your account appear in the Stripe Dashboard, as its security guide notes.

Merchant levels, based mostly on annual transaction volume per card brand, determine whether self-assessment is enough; see PCI DSS levels. If you are unsure which SAQ fits, ask before you sign.

A yearly Stripe PCI checklist

Most of the merchant side of Stripe PCI compliance is a short list of recurring tasks with clear owners.

Scope and paperwork

• Confirm which Stripe integrations are live across web, mobile, in-person and support channels.
• Re-check the eligibility criteria in the current SAQ against how you actually take payments.
• Complete the SAQ and AOC and submit them as your Stripe Dashboard or acquirer requests.

Payment pages and scripts

• Inventory every script that loads on checkout, billing and upgrade pages, with an owner and a reason.
• Remove scripts you do not need and require approval before new ones are added.
• If you embed Elements, record which FAQ 1588 route you rely on for the script criterion.

Accounts and secrets

• Review who has Stripe Dashboard access and at what role. Remove leavers promptly.
• Enforce MFA on Stripe and on the email accounts that can reset it.
• Rotate secret API keys on staff changes or suspected exposure, and scan code repositories for leaked keys.
• Confirm webhook endpoints use TLS and verify signatures, as Stripe's guide requires.

People and vendors

• Train staff never to accept card numbers by email, chat or support ticket.
• Run phishing awareness covering fake payment provider login pages.
• Update and review your list of vendors that can affect the payment flow.

Incident readiness

• Document who contacts Stripe and your acquirer if you suspect a compromise.
• Rehearse revoking keys, disabling a script and locking accounts in a tabletop exercise.

How SecureSlate helps

SecureSlate gives you one place to run the merchant side of PCI DSS. PCI DSS is a built-in framework, and multi-framework control mapping lets you track it alongside SOC 2, ISO 27001 or HIPAA so one control, such as MFA on admin accounts, supports all of them.

Vendor risk management records Stripe and every tool near your payment flow. Access reviews cover who can reach your Stripe Dashboard, and code security and secrets detection helps you find API keys committed to repositories. The trust center and security questionnaire automation help you answer customer PCI questions. Your validation still follows your acquirer's requirements.

Start your free SecureSlate trial

FAQ

Does using Stripe make me PCI compliant?

No. Stripe's Level 1 status covers Stripe's systems. You still attest to your own compliance annually, usually with an SAQ.

Is Stripe Elements SAQ A?

Stripe maps Elements to SAQ A because the card fields are iframes served from Stripe's domain. Since the January 2025 update, embedded-form merchants also need to confirm their site is not susceptible to script attacks, either through their own controls or confirmation from their processor.

Do I need SAQ A-EP or SAQ D with Stripe?

Only if your integration puts you there. Your own payment form usually means SAQ A-EP; sending raw card numbers through your servers to Stripe's API means SAQ D.

Who do I send my SAQ to?

Follow your Stripe Dashboard's compliance documents section and any acquirer requests. Keep signed copies each year.

Disclaimer (legal note)

This article is for general information only and is not legal, regulatory or professional advice. Requirements vary by framework, industry and jurisdiction. Consult qualified advisors for your specific obligations.