In this guide
- 01
Find out where your checkout renders
- 02
Read what that means for you
- 03
Does PCI DSS 6.4.3 apply to merchants using Stripe?
It depends on how the Stripe payment form reaches your customer.
How PCI DSS 6.4.3 and 11.6.1 work
6.4.3, scripts on the payment page
Report URI, a vendor that works on script monitoring, publishes the 6.4.3 text from PCI DSS v4.0.1 as follows:
PCI DSS v4.0.1, 6.4.3All payment page scripts that are loaded and executed in the consumer’s browser are managed as follows:
- A method is implemented to confirm that each script is authorized.
- A method is implemented to assure the integrity of each script.
- An inventory of all scripts is maintained with written business or technical justification as to why each is necessary.
11.6.1, detecting changes to the payment page
11.6.1 asks for a change- and tamper-detection mechanism on the payment page. One line of it, as Report URI quotes it, reads “To alert personnel to unauthorized modification.” The Applicability Note says the intention “is not that an entity installs software in the systems or browsers of its consumers.” Both requirements take effect March 31, 2025, per the PCI SSC blog.
What changed for SAQ A in January 2025
On January 30, 2025, PCI SSC announced the “Removal of PCI DSS Requirements 6.4.3 and 11.6.1 for payment page security.” from SAQ A. An eligibility criterion replaced them.
The SAQ A v4.0.1 Revision 1 form, as copied on a university host.
FAQ 1588 describes two routes for a merchant with an embedded payment form:
Which Stripe setup you have, and what PCI SSC says about it
| Setup | Where the card fields render | What PCI SSC’s guidance says |
|---|---|---|
|
Stripe Checkout, full redirect
|
On a Stripe-hosted page | FAQ 1588: the script criterion does not apply to merchants that redirect customers or fully outsource payment |
|
Stripe Elements or Payment Element, embedded
|
In an iframe “served from Stripe’s domain (not yours)” inside your page | The criterion applies: confirm the site is not susceptible to script attacks |
|
Direct API with raw card data
|
On your own form and server | 6.4.3 and 11.6.1 apply as requirements. Stripe calls this “the most demanding of the SAQs” |
Stripe’s PCI guide maps each integration to a questionnaire type, and your acquirer confirms which one you use. Scripts, 6.4.3 and 11.6.1 are not mentioned in the Stripe pages we read. If you use a full redirect, per the FAQ the script criterion does not apply to you, and the rest of this guide is written for the embedded case.
Open your checkout as a customer. If the browser leaves your domain for a Stripe page, you are on a redirect. If the card fields sit inside your page in a frame from a Stripe domain, you have an embedded form. Check again after any change.
Why the page around Stripe’s fields matters
“Including JavaScript from other sites makes your security dependent on theirs and poses a security risk. If they’re ever compromised, an attacker could execute arbitrary code on your page.”
Stripe’s security guide
On WordPress, the checkout page loads your theme, WooCommerce, the gateway plugin, analytics and a tag manager. Our reading is that “scripts that could affect the merchant’s e-commerce system(s)” points at these. It is an inference from the criterion’s wording, not a Stripe statement.
Stripe’s guide also says: “PCI compliance is a shared responsibility and applies to both Stripe and your business.” The iframe covers the card fields, and the rest of the page is yours. See what PCI asks of a WordPress payment page.
What keeping track of payment page scripts involves
This is general practice for WordPress, not quoted rule text:
| Script URL | Who added it, and why | Authorized | Last checked |
|---|---|---|---|
- List every script URL loaded on the payment page.
- Record who added each one and why. That is your written justification.
- Record that each one is authorized.
- Recheck after any plugin or theme change.
Stripe publishes Content Security Policy directives. We found no source that says a CSP alone meets 6.4.3. See also what WordPress hardening covers.
We found no primary source for what evidence an assessor expects, or for what a monitoring product costs, so this guide gives no list and no figure.
After your next plugin update, compare your script list against the page. Anything new without an entry is unaccounted for.
What to do next
- 01
Find where your checkout renders.
- 02
If it is embedded, decide which of the two FAQ 1588 routes you use.
- 03
Ask your acquirer which questionnaire applies.
- 04
Keep the script list current after every change.
Every NoDrama plan includes “WordPress, plugins and themes kept current” and “Scanned for malware every 12 hours,” and includes reporting. Keeping those current supports compliance work. NoDrama does not produce a script inventory, justifications or 11.6.1 detection. See what each NoDrama plan includes.
Check where your checkout renders, then see what that means.
NoDrama’s guide to checking whether your website is secure walks through the next look.
Common misreadings of 6.4.3
What this does not solve
This guide does not tell you which SAQ you complete. That is your acquirer’s call, or the payment brands’. It is not a QSA opinion, and it does not cover PCI requirements beyond 6.4.3 and 11.6.1. UK merchants follow the same standard, and we found nothing that differs.
Where your checkout renders decides it
Whether PCI DSS 6.4.3 and the SAQ A script criterion reach you depends on where your checkout renders. A full redirect falls outside the criterion per FAQ 1588. An embedded Stripe form means you confirm your site is not susceptible to script attacks.