Does using Stripe make you PCI compliant?
No. Using Stripe shrinks your PCI DSS scope and can move you to the shorter SAQ A self-assessment, but it does not make you fully compliant. Stripe certifies its own systems, not your website. PCI DSS 4.0.1 requirements 6.4.3 and 11.6.1 govern the scripts on your payment page, and that page still loads in your customer's browser. They stay your responsibility.
E-commerce and compliance teams often overlook this gap. Offloading card capture to a processor is valuable: it removes cardholder data from your servers and cuts the number of controls you self-attest to. But "we use Stripe" answers a question about where card numbers are processed. It does not answer the question PCI DSS 4.0.1 now asks: what is every script doing in the browser while your customer types their card?
What Stripe actually covers (and what it does not)
Stripe is a PCI DSS Level 1 service provider, and you can use Stripe for PCI DSS scope reduction. When you use Stripe Elements, hosted fields, or Stripe Checkout, the card number is entered into an iframe served and controlled by Stripe. The sensitive data lands in Stripe's environment, not yours. That is the scope reduction you are paying for, and it is real.
What Stripe does not do is take ownership of the page that surrounds its iframe. Your checkout page is still served from your domain, assembled by your stack, and decorated with your scripts: analytics, tag managers, session replay, chat, fraud SDKs, and whatever a marketing team added last quarter. Those scripts run in the same browser as the payment flow.
| Concern | Stripe covers it | You still own it (6.4.3 / 11.6.1) |
|---|---|---|
| Card number entry and storage | Yes, inside Stripe's hosted iframe | No |
| Stripe's own PCI DSS attestation | Yes, as a Level 1 service provider | No |
| Third-party scripts on the payment page | No | Yes, inventory and justify each one (6.4.3) |
| Integrity of those scripts (no tampering) | No | Yes, confirm integrity (6.4.3) |
| Tamper and change detection plus alerting | No | Yes, deploy a mechanism (11.6.1) |
| Security-impacting HTTP headers | No | Yes, monitor for unauthorized change (11.6.1) |
| Your merchant SAQ and AoC | No | Yes, you self-assess and attest |
The split is clean. Stripe owns the card data, you own the browser environment around it. PCI DSS 4.0.1 made that second column explicit.
What do requirements 6.4.3 and 11.6.1 actually require?
Both requirements were introduced to address client-side attacks, where malicious code is injected into scripts that run in the customer's browser. They became mandatory on 31 March 2025 (PCI Security Standards Council, PCI DSS v4.0.1).
Requirement 6.4.3: manage your payment-page scripts. For every script loaded and executed on the payment page in the consumer browser, you must:
- Maintain an inventory of all scripts, with written justification for why each one is necessary.
- Authorize each script before it is added or changed.
- Confirm the integrity of each script by verifying it has not been modified without authorization.
Requirement 11.6.1: detect tampering and alert. You must deploy a change-detection and tamper-detection mechanism that:
- Alerts personnel to unauthorized modification of the HTTP headers and the scripts of the payment page, as received by the consumer browser.
- Evaluates the received page at least once every seven days, or at a frequency defined by your targeted risk analysis.
6.4.3 says know and authorize your scripts, and 11.6.1 says watch them in real-time and alert when they change. Neither is satisfied by your payment processor, because neither is about where the card data goes. They are about what runs in the browser. For a step-by-step walkthrough, see our practical guide to PCI 6.4.3 and 11.6.1 compliance.
Do these requirements apply to me if I am SAQ A?
Teams get caught here. SAQ A is the shortest self-assessment, reserved for merchants who fully outsource cardholder data handling. It is tempting to read "fully outsourced" as "nothing client-side to worry about." That is no longer how the PCI SSC treats it.
The January 2025 SAQ A removed 6.4.3 and 11.6.1 from the questionnaire itself, then added a new eligibility criterion in their place. To use SAQ A you now have to confirm that your payment page is not susceptible to attacks from scripts that could affect your e-commerce systems, and that every element delivered to the browser comes directly from a PCI DSS compliant processor (PCI Security Standards Council, 2025). Merchants who cannot make that confirmation drop out of SAQ A and have to satisfy the payment-page script requirements directly. Either way, browser-side script risk is now your problem. Confirm your current SAQ A version and its eligibility criteria against the PCI SSC Document Library before you assume you are out of scope.
The change traces back to a specific event. The 2024 Polyfill[.]io incident showed how a single trusted third-party script, embedded on more than 490,000 sites, can be turned malicious overnight and serve skimming or redirect code to checkout pages (Sansec, 2024). A merchant on SAQ A with Stripe Checkout was just as exposed as anyone else, because the malicious script rode in on the merchant's own page, not Stripe's.
Why the payment page is still your attack surface
The core problem is where code runs. Stripe's iframe isolates the card fields, but client-side attacks rarely target the card field directly. They target the page around it.
- Form overlays. A compromised script can draw a fake card form on top of, or alongside, Stripe's iframe and capture data before it reaches Stripe.
- Checkout redirection. Injected code can send a shopper to a spoofed payment page mid-flow.
- Data harvesting. A tampered analytics or chat script can read name, email, address, and order details from the DOM and exfiltrate them to an attacker-controlled domain.
- Header weakening. Modified security-impacting HTTP headers such as Content-Security-Policy can open the door for the scripts above, which is why 11.6.1 names headers explicitly.
E-skimming is not a rare edge case. Magecart-style web skimming has hit thousands of e-commerce sites, and the technique persists because the browser is hard to monitor from the server. In the 2024 Verizon DBIR, payment card data accounted for 25% of breached records in the retail sector, and retail is named as the home turf of Magecart actors who insert malicious code into checkout pages (Verizon, 2024). Your server logs and Stripe's dashboard will both look normal while a skimmer runs in your customers' browsers.
This is why the requirements live in the browser, not the backend. To learn how these attacks bypass server-side controls, see our guide to client-side security.
How to satisfy 6.4.3 and 11.6.1 in practice
You can meet these requirements manually: keep a spreadsheet of every script, justify each, hash them, and check the rendered payment page weekly for changes. For a site with a handful of static scripts, that might hold. For a real checkout where a tag manager injects scripts dynamically, the manual approach breaks down fast and produces evidence auditors distrust.
The operational answer is continuous, automated script monitoring built for the payment page. cside PCI Shield is designed to satisfy both requirements directly:
- Automated inventory and justification (6.4.3). cside discovers every script running on your payment page, builds the inventory, and lets you record authorization and justification in one place, with one-click and AI-assisted review.
- Real-time integrity and tamper detection (11.6.1). cside monitors scripts and security-impacting HTTP headers continuously and alerts on unauthorized change, rather than sampling on a weekly cron and hoping nothing slipped through between checks.
- Audit-ready evidence. cside archives every script version with full history, so you hand a QSA forensic records instead of behavioral guesses.
The point is not to replace Stripe. Stripe and a script-monitoring layer solve different halves of the same compliance picture: Stripe takes card data out of scope, and cside covers the browser-side requirements Stripe leaves with you.
The bottom line
Using Stripe is a smart way to shrink PCI scope, and it can put you on SAQ A. It does not make you fully PCI compliant, because requirements 6.4.3 and 11.6.1 hold you responsible for the scripts and headers on your payment page, where Stripe's hosted fields have no reach. Those requirements are mandatory, and SAQ A eligibility itself now depends on confirming your payment page is protected against script tampering.
Treat the payment page as your attack surface, inventory and authorize every script, and deploy real-time tamper detection. For the operational side of that, see cside PCI Shield and client-side security, or book a demo to walk through your checkout.
