· ReadyStack
Worked example
Real numbers from this tool, line by line.
Twenty findings sit in an ordinary checkout page, and the e-commerce developers who own that template in the US and the EU are the ones who have to clear them. The page renders correctly. Payments go through. Nothing in it looks wrong, because none of these are bugs - they are a requirement that has been mandatory since 2025-03-31 and that nobody put on the sprint board.
PCI DSS 4.0.1 requirement 6.4.3 says that every script loaded and executed in the customer's browser on a payment page needs three things: a method that confirms the script is authorized, a method that assures its integrity, and an inventory entry with a written business or technical justification for why it is there. Requirement 11.6.1 adds that you have to be alerted when the scripts or the security headers of that page change.
Here is the head of a checkout page that passes every other check you run.
<meta http-equiv="Content-Security-Policy" content="script-src 'self' 'unsafe-inline' https:">
<script src="https://www.googletagmanager.com/gtag/js?id=G-8QK2M1RS"></script>
<script src="https://cdn.jsdelivr.net/npm/jquery@latest/dist/jquery.min.js"></script>
<script src="https://static.hotjar.com/c/hotjar-2914455.js?sv=6"></script>
<script src="https://js.stripe.com/v3/"></script>Five lines, and four separate failures:
- The policy is in a
<meta>tag. A meta policy cannot carryreport-uriorreport-to- the browser ignores both there. So it can block, but it can never tell you it blocked, and 11.6.1 asks for exactly that alert. script-srcallows'unsafe-inline'and barehttps:. Every host on the internet is an authorized script source, which is the opposite of an authorization method.- The tag manager can add a script tomorrow that no inventory records. That is not a hypothetical; it is the normal way a marketing tag reaches a checkout page.
jquery@latestis a moving version. Whatever hash you wrote down at assessment time describes bytes that may no longer be served.
And one line that is fine and gets flagged by naive tooling: js.stripe.com is supposed to load without a Subresource Integrity hash, because Stripe rotates that file. Demanding a hash there is wrong. It still needs an inventory row, with "renders the hosted card fields" as its justification.
The thing that changed this year
Merchants with a fully outsourced checkout used to have a way out. If the payment page was entirely delivered by the processor, a QSA could agree that 6.4.3 and 11.6.1 were not applicable, and that agreement was enough to write it into the report.
On 2026-08-04 the PCI Security Standards Council published a revised FAQ 1331. QSA agreement alone is no longer sufficient: merchants must consult their Compliance Accepting Entity - the acquirer or the payment brand - to confirm what applies. The requirements did not change. The escape route narrowed, and it narrowed inside an assessment cycle that many teams are already in.
Why the tools you already have do not cover this
A CSP evaluator grades the policy string. It never opens your page, so it cannot see the script the page injects at runtime with document.createElement('script'). ESLint reads JavaScript; it does not read the attributes of a <script> tag, so integrity= with no crossorigin= - which browsers ignore, leaving you unprotected while the markup claims otherwise - goes straight past it. And an assistant that was trained before this year will confidently tell you Subresource Integrity is sufficient for 6.4.3, which is the single most common wrong answer in this area: SRI does not inventory anything, does not apply to dynamically injected scripts, and does not notice when an authorized script starts behaving differently.
What the audit does
It reads the page as markup, line by line, against 26 rules written for payment pages specifically. Each finding names the line, the requirement it fails and the replacement. Session recorders on a page with a card field. Marketing pixels that ship without a justification. <base href>, which quietly rewrites every relative script URL on the page. eval() and new Function(), which force 'unsafe-eval' into the policy and remove the CSP as an authorization method for everything else. Inline handlers, which force 'unsafe-inline' and do the same.
The free version audits the page you have open, completely: all 26 rules, no key, no watermark, no locked results. It runs in the editor and it runs as a single web page you can paste a template into.
What a licence adds is not more rules - it is the artifact. An assessor does not accept a findings panel; they accept a dated inventory. The full version exports that inventory as CSV, JSON or HTML across every payment page in the repository, and emits CI output that fails a build when an unauthorized script appears, so the next tag someone pastes in does not reach production between assessments.
A PCI consultant bills about $76 an hour in the US in 2026, and a QSA-assisted self-assessment runs $5,000 to $20,000. Building this inventory by hand is billed inside that, and it has to be rebuilt every time marketing adds a tag.
15 seconds — what it actually does
Questions people ask
What does PCI Payment Page Script Audit actually do?
It reads the HTML of a checkout page and marks every script that fails PCI DSS 4.0.1 requirement 6.4.3 or 11.6.1. Each finding carries the line number, the requirement it breaks and the fix: a missing integrity hash, a tag manager that can add scripts after your inventory was signed, a policy that only lives in a meta tag. Twenty-six rules ship inside.
Who is this for?
Web and e-commerce developers who own the checkout template, and the security engineer who has to hand a QSA the list of scripts running on the payment page. It is aimed at teams validating under SAQ A-EP or a full Report on Compliance, and at anyone who inherited a checkout page nobody has read since 2024.
Why is ESLint, a CSP evaluator or a chatbot not enough?
A general linter checks syntax; a CSP evaluator reads the policy and never sees the page. Neither knows a payment page is different. They will not tell you that Subresource Integrity is ignored without crossorigin, that a meta policy cannot carry report-uri, or that Stripe's script must load with no hash at all. Those are PCI findings, not code smells.
What is free and what needs a licence?
Free audits the checkout page you have open against all twenty-six rules, with no key, no watermark and no locked results. That finishes the job for one page. The licence changes what you can take away: the dated script inventory exported as a file, every payment page in the repository, and CI output that fails a build.
What would this cost if a person did it?
A PCI consultant bills around seventy-six dollars an hour in the United States in 2026, and a QSA-assisted self-assessment runs from five to twenty thousand dollars. Building the script inventory by hand is billed inside that, and it has to be rebuilt every time marketing adds one tag. The licence is twenty-nine dollars once.
Why not just ask ChatGPT or another AI chat?
A general AI chat answers from training data with a cutoff date, cannot read your repository and names no rule version. PCI Payment Page Script Audit: requirement 6.4.3 and 11.6.1 checks the file you open against 26 rules from a rule set dated 2026-09-20, and points at the exact line with the fix. For a filing, an audit or a client you need that dated result on your own files.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.