TL;DR: Stripe PCI DSS compliance
- Stripe handles PCI DSS Level 1 compliance for the card processing itself, which is why merchants often say they are 'PCI compliant with Stripe.' That is half true.
- Merchants still own PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 on their own site even when Stripe processes the card. These cover script inventory and payment-page tamper detection on your domain.
- Stripe Elements minimizes but does not eliminate the merchant's scope. SAQ-A merchants using Stripe Elements still need to satisfy 6.4.3 and 11.6.1, and cside's free tier covers both.
Short on time? See cside PCI Shield. It covers everything below in one deployment.
Yes, Stripe holds PCI DSS Level 1 certification, the highest level available. That certification covers Stripe's infrastructure. It does not cover your website. If your payment page loads any script you control, analytics, live chat, consent management, A/B testing, two PCI DSS 4.0.1 requirements remain your responsibility that Stripe cannot satisfy on your behalf: §6.4.3 and §11.6.1.
Who is responsible for what with Stripe and PCI DSS 4.0.1?
Stripe's Level 1 service provider status is verified annually by a Qualified Security Assessor (QSA) and listed on the Visa Global Registry of Service Providers. The certification confirms that Stripe's data centers, card processing systems, and internal infrastructure meet PCI DSS standards. Where the line falls between Stripe and you depends on which integration you run:
| Your Stripe integration | What Stripe's certification covers | What stays yours under 4.0.1 |
|---|---|---|
| Stripe Checkout, hosted payment page (SAQ A) | The card fields, the hosted page itself, and the card data end to end, all served from Stripe's certified domain | Every script and security header on the page that sends the shopper into Checkout, under §6.4.3 and §11.6.1 |
| Stripe Elements, embedded hosted fields (SAQ A) | The iframe that collects the card, and the transmission and storage of that card data | The page around the iframe: analytics, chat, consent, tag managers, plus header and cookie-attribute change detection |
| Stripe.js with your own payment UI (SAQ A-EP) | Tokenization and the card data once Stripe.js hands it over | Your whole checkout DOM, the integrity of every script that can reach it, and your headers |
| Mobile and Terminal SDKs (SAQ A) | Card capture and transmission inside Stripe's own SDK | Any web checkout you run alongside the app, on the same terms as the rows above |
| Direct API, card data on your server (SAQ D) | The card data only once it reaches Stripe, never while it sits on your systems | Full PCI DSS scope: storing and transmitting card data, plus §6.4.3 and §11.6.1 |
The boundary is Stripe's servers. Your payment page, the page that collects or redirects card data, runs in your customers' browsers, and that surface is yours, whichever row you are in.
How to be compliant using Stripe
Stripe's products are designed to handle sensitive card data securely, reducing the scope of your PCI DSS responsibilities:
- Stripe Checkout and Elements: These tools use hosted payment fields, ensuring that sensitive payment information is transmitted directly to Stripe's PCI DSS-validated servers without touching your servers.
- Mobile and Terminal SDKs: Stripe's SDKs for mobile and in-person payments also send sensitive information directly to Stripe, minimizing your PCI scope.
| Stripe Integration | SAQ Required | Reason |
|---|---|---|
| Stripe Checkout (hosted payment page) | SAQ A | No cardholder data touches your server |
| Stripe Elements (embedded fields)* | SAQ A* | Elements securely transmits data to Stripe* |
| Stripe.js v2 with custom UI | SAQ A-EP* | Your frontend affects transaction security |
| Direct API (card data on your server) | SAQ D | You store, process and/or transmit card data |
*You must now monitor dependencies on payment pages, more below.
- If you use Stripe Checkout (hosted payment page), you qualify for SAQ A.
- If you use Stripe Elements (embedded fields that send data directly to Stripe), you qualify for SAQ A.
- If you use Stripe's Mobile or Terminal SDKs, payment data is securely processed by Stripe, keeping you in SAQ A.
- If you collect and store cardholder data or use a direct API integration, you must complete SAQ D and implement full PCI controls.
If you qualify for SAQ A, your PCI DSS responsibilities are minimal because Stripe handles the sensitive card data.
If you require SAQ A-EP or SAQ D, you take on more responsibility for securing transactions.
Which PCI DSS requirements Stripe does not cover
PCI DSS 4.0.1 introduced two requirements targeting the browser layer, both mandatory since March 31, 2025:
Requirement 6.4.3, Script authorization on payment pages
You must maintain a documented inventory of every script authorized to run on your payment pages. For each script, you need a method to confirm its integrity, that the code has not been modified since you last reviewed it. This applies whether the script is yours or a third party's (analytics, support chat, A/B testing tools).
Requirement 11.6.1, HTTP header change detection
You must deploy a mechanism that detects unauthorized changes to HTTP security headers and cookie attributes on your payment pages and generates alerts.
Stripe has no visibility into these scripts or headers. Both requirements address what happens in your customers' browsers on your web page, a surface entirely outside Stripe's environment.
The PCI Security Standards Council's January 2025 update to SAQ A confirmed this: even merchants using fully hosted Stripe Checkout must satisfy §6.4.3 and §11.6.1 if their checkout flow passes through any page that loads external scripts. See our January 2025 SAQ A update breakdown for details.
For a full technical breakdown of what Stripe covers and what it does not for §6.4.3 and §11.6.1, see our post: Does Stripe make you PCI compliant for requirements 6.4.3 and 11.6.1?
Script monitoring for SAQ A compliance
As per the January 2025 update, the PCI Security Standards Council emphasized the importance of monitoring dependencies. This includes both first-party and third-party scripts on websites.
A client-side monitor satisfies §6.4.3 and §11.6.1 by running in your customers' browsers, inventorying every script on each payment page visit, and alerting when a script changes or a new one appears. cside monitors scripts and HTTP headers in real visitors' browsers, including conditional payloads that appear clean to scanners but activate in production traffic.
See Stripe's documentation on PCI DSS here.
Related reading: our PCI DSS 6.4.3 and 11.6.1 compliance guide · Adyen's PCI DSS shared responsibilities
Determine your PCI compliance level
| Level | Criteria | Validation Requirement |
|---|---|---|
| Level 1 | Over 6 million transactions annually | Full onsite audit by a QSA + SAQ D |
| Level 2 | 1 to 6 million transactions annually | SAQ A, SAQ A-EP, or SAQ D + Attestation of Compliance (AOC) |
| Level 3 | 20,000 to 1 million online transactions annually | SAQ A, SAQ A-EP, or SAQ D + Attestation of Compliance (AOC) |
| Level 4 | Less than 20,000 online transactions OR up to 1 million total transactions | SAQ A, SAQ A-EP, or SAQ D + Attestation of Compliance (AOC) |
- Level 1 = Must complete a ROC (Full PCI DSS Assessment with Report on Compliance by QSA)
- Level 2 = Must complete at least an SAQ with third-party QSA or ISA attestation
- Level 3 = Must complete an SAQ
- Level 4 = Optional
The PCI DSS Attestation of Compliance for Stripe merchants
The PCI DSS Attestation of Compliance (AoC) for a Stripe merchant is a document a QSA (or an authorised internal signer under SAQ) produces at the end of an assessment cycle, stating which SAQ level the merchant qualifies for and that all applicable controls are in place. For most e-commerce Stripe merchants that means an SAQ A (fully outsourced payment page) or SAQ A-EP (checkout hosted on the merchant's site) attestation.
The important operational point is that Stripe's AoC covers Stripe. It does not cover the merchant. Even when using Stripe Elements or Checkout, the merchant still holds an AoC obligation because the payment page runs on the merchant's domain and the merchant is responsible for scripts loaded on that page under 6.4.3 and 11.6.1. Enterprise procurement teams frequently ask for both AoCs during vendor onboarding.
cside supplies the evidence trail that supports the merchant's own SAQ A or SAQ A-EP AoC: continuous script inventory, integrity monitoring, and audit-ready 6.4.3 / 11.6.1 evidence that a QSA can pull without a scramble.
Identify your integration type and required documentation
Complete the appropriate SAQ Once you have identified the correct SAQ based on your integration method, complete it thoroughly. Stripe provides a PCI wizard in your Dashboard to guide you through this process.
Submit your documentation After completing the SAQ, submit it along with any required Attestation of Compliance (AOC) or Report on Compliance (ROC) to Stripe for review. Stripe's Dashboard allows you to upload these documents directly.
Maintain ongoing compliance PCI compliance requires continuous monitoring. Review your script inventory regularly, keep your SAQ current, and monitor payment page headers for unauthorized changes.
The same gap between processor certification and merchant obligation applies when using Adyen or PayPal and Braintree as your payment processor.
