· ReadyStack
Worked example
Real numbers from this tool, line by line.
Sixteen findings on one checkout page, fifteen of them errors: that is what this lint returns on a template most e-commerce developers in the EU and the US would call their own.
PCI DSS v4.0.1 has two requirements that stopped being future-dated on 31 March 2025. Requirement 6.4.3: manage every script loaded and executed in the consumer browser on the payment page. Requirement 11.6.1: run change- and tamper-detection against that page, evaluated at least every seven days unless a targeted risk analysis says otherwise. Both land on one file — the template that renders the page where the card number is typed.
6.4.3 has three bullets: a method that confirms each script is authorised, a method that assures its integrity, and an inventory of all scripts with a written business or technical justification for each. The first two are engineering — a Content-Security-Policy and Subresource Integrity. The third is a document, and the document is where assessments go wrong, because it drifts the moment somebody adds a tag.
The bundled dirty.html, checked as of 2026-09-11:
L2 inventory_review_stale reviewed 832 days ago L3 tamper_evaluation_stale last evaluated 43 days ago L7 csp_unsafe_inline script-src contains 'unsafe-inline' L10 script_sri_missing no integrity=, and fetched over http:// L24 script_version_floating .../latest/hostedfields.js L28 injector_not_declared Google Tag Manager L30 script_sri_no_crossorigin integrity= present, crossorigin= absent L33 inline_script_no_nonce no nonce= on an inline block
Sixteen findings across eight lines; five scripts, one written justification between them. Line 28 is worth a look: Tag Manager is not one script but a loader for however many the container holds today, all of them inside 6.4.3.
The integrity= on line 30 is real, correct, and does nothing. Subresource Integrity is enforced cross-origin only when the request is made in CORS mode, so crossorigin has to be on the tag. Without it the browser never compares the hash. It reads like evidence and it is not.
The /latest/ on line 24 is the same failure in another costume: if the bytes behind an authorised URL can change upstream, the authorisation expired without telling anyone.
The two date-driven checks are what make this a lint rather than a checklist. The tamper note on line 3 is not missing; it is 43 days old against a 7-day cadence. The inventory note on line 2 was reviewed 832 days ago, by someone who has left. A page that passes on a Monday fails the following Tuesday with no code change — which is what 11.6.1 is describing.
So the inventory lives in the page: a <!-- pci:script owner="..." reason="..." --> comment above the tag it justifies, a <!-- pci:tamper ... evaluated=YYYY-MM-DD --> note recording the mechanism and its last evaluation, and <!-- pci:inventory reviewed=YYYY-MM-DD --> dating the review. The lint fails when a tag arrives without a justification, so the register is maintained by the review that merges it. Fourteen checks; the clean fixture returns zero.
Checking one page is free and finishes the job: all fourteen checks, every finding on its line with the requirement reference, in VS Code or in the browser, nothing uploaded. The licence buys a different job — a sweep of every payment template in the repository, written out as a dated register for the assessor. $29 once, 7-day full refund. A QSA hour compiling the same register bills $150-$300.
Not legal advice: your QSA, acquirer and SAQ or ROC scope decide what applies.
Questions people ask
What does PCI DSS 6.4.3 Payment Script Lint actually do?
It reads a checkout or payment page and reports every browser script that fails PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1: scripts with no integrity hash, scripts missing from the written inventory, entries with no business justification, a policy that allows unsafe-inline, and missing or slower-than-weekly tamper detection. Sixteen checks, each tagged with its requirement number.
Who is it for?
E-commerce developers who own the checkout template at a merchant that takes card details on its own pages: Shopify Plus and WooCommerce theme developers, Laravel and Rails shop teams, and anyone whose acquirer has just asked for a payment-page script inventory. It is a code linter, so it belongs to whoever edits the HTML, not to the compliance inbox.
Why can't I just ask a chatbot or use a generic HTML linter?
Generic linters do not know what a payment page is; they flag unused tags, not unauthorised scripts. Chatbots still answer from PCI DSS v3.2.1 or describe 6.4.3 and 11.6.1 as future-dated best practices, which stopped being true on 2025-03-31. Neither one reads your actual checkout file line by line.
What is free and what needs a licence?
Free, with no key and no limit: check the file open in your editor against all sixteen rules, with each finding on its line and its requirement number. The licence adds a different job, ownership of the evidence: sweeping every checkout template in the workspace and writing the dated script inventory report you hand to an assessor.
What would this cost me otherwise?
PCI consultants and QSAs typically bill $150 to $300 an hour for the same payment-page script review, and they bill again after each template change. The licence is $29 once. The other cost is the assessment itself: arriving without a script inventory means a finding you close under deadline pressure.
Does it change my files or send my code anywhere?
No. The extension reads the file, reports findings in the editor, and writes nothing except the report you ask for. There is no network call in the checker itself; the only request the extension ever makes is validating a licence key you typed.
Ask about this tool
One question, answered by the person who built it. Your email only if you want the answer sent.