Every payment-page script — inventoried, and with zero eval.
Since 31 March 2025, every script running on a payment page must be authorized, integrity-assured, and inventoried with justification — and any tampering detected. Blueprint generates nothing from strings, so the inventory is short, the CSP stays strict, and the payload can’t change without a deploy you control.
Who says so: the PCI Security Standards Council — “Requirements 6.4.3, 11.6.1, and 12.3.1 become effective as of 31 March 2025.”
What it actually asks, in plain terms.
Two requirements working together: one makes you govern the scripts, the other makes you notice when they change.
- Authorize each script — every one has an explicit authorization.
- Assure its integrity — it’s what you intended, and hasn’t been altered.
- Keep an inventory of all scripts with written justification of why each is necessary.
- A mechanism alerts personnel to unauthorized modification (indicators of compromise, changes, additions, deletions)…
- …to the HTTP headers and the contents of payment pages, as received by the consumer browser.
- Performed at least weekly, or at a frequency defined by your targeted risk analysis (§12.3.1).
Why it’s hard with a config- or server-driven UI.
If bindings are evaluated (eval / code generated from strings), you can’t truly inventory them: the code that runs is produced at runtime, not what you wrote.
If the UI payload can change from the server without a deploy on your side, you have exactly the surface §11.6.1 makes you monitor — and §6.4.3 makes you justify.
A strict CSP rejects eval: what works in the editor breaks in production. (The same dynamic documented on Builder.io — “code generation from strings.”)
How Blueprint makes it provable, clause by clause.
What an auditor sees: a diff, not a promise.
A change to the screen is a reviewable diff. The payload it produces carries no eval and an inventory your scanner can check.
{ "type": "form", "id": "checkout", "fields": [ { "type": "input", "label": "Card number" }, { "type": "button", "label": "Pay" } { "type": "checkbox", "label": "I authorize this payment", "required": true }, { "type": "button", "label": "Pay" } ] }
The whole client footprint
Script inventory · /checkout
- Contract signed · v14
- Runtime-injected 0
- CSP strict
The honest part
Blueprint doesn’t make you PCI compliant and isn’t certified. It does two things: it reduces your scope (self-hosted, no data egress) and makes §6.4.3 / §11.6.1 demonstrable with artifacts — an inventory, a signed diff, a CSP report — that your assessor can verify. Scope and SAQ determination remain yours and your QSA’s.
The questions your compliance team will ask.
Is Blueprint in my CDE / PCI scope?
It runs in your environment and doesn’t receive or store cardholder data. Precise scope depends on your architecture — confirm with your QSA. The point of this page is that Blueprint gives you the artifacts to demonstrate 6.4.3 / 11.6.1, not that it replaces scoping.
Does it cover SAQ A / SAQ A-EP?
With the SAQ A revision (v4.0.1, effective 31 March 2025) PCI SSC removed 6.4.3 and 11.6.1 from SAQ A, replacing them with an eligibility criterion (the site must not be susceptible to script attacks). They still fully apply to SAQ A-EP, SAQ D, and onsite assessments. Blueprint helps demonstrate them where they apply; the SAQ choice remains yours and your QSA’s. Source: PCI SSC ↗
What if a component loads a third-party script?
That script must still be authorized, integrity-assured, and inventoried — the same rules apply. Blueprint inventories what the contract produces; third-party scripts you add stay in your responsibility perimeter, but at least they start from a real inventory rather than “whatever is running.”
Does it really generate zero eval?
The runtime maps the contract onto real components — there’s no code generation from strings in the payload. It’s a property of the architecture, not an option to toggle.
Verify it yourself.
Every claim about 6.4.3 / 11.6.1 on this page traces to a primary PCI SSC source.
- Date + SAQ APCI SSC — Important updates for merchants validating to SAQ A — confirms “effective as of 31 March 2025” and the removal of 6.4.3/11.6.1 from SAQ A.
- 6.4.3 / 11.6.1 textPCI SSC — Information Supplement: Payment Page Security & Preventing E-Skimming — verbatim wording of both requirements + the “at least weekly” cadence.
- StandardPCI SSC — Document Library — PCI DSS v4.0.1 (download under SSC licence; contains the literal “once every seven days”).
- CommentaryJohn Elliott — “A Crucial Change in 4.0.1 of PCI DSS” (PCI Rocks) — framing (secondary, not authoritative).