All posts
Retail & E-commerce

PCI DSS 4.0.1 and Your Checkout Page: Payment Page Scripts, SAQ A, and What Changed in 2025

By

October 26, 2026

6 min read

Requirements 6.4.3 (authorize and inventory every script on payment pages) and 11.6.1 (detect changes to them) took effect on March 31, 2025, aimed at card-skimming attacks. In January 2025 the PCI Council removed them from SAQ A and added an eligibility check instead. What applies to your checkout, depending on how card data is captured, and how to meet it.

PCI DSS
E-commerce
Payments
Content Security Policy
Web Security

Card skimming on e-commerce sites works by getting a malicious script onto the checkout page, often through a compromised third-party script, where it copies card details as customers type. PCI DSS 4.0 added two requirements aimed directly at it, which became mandatory on March 31, 2025.

The two requirements

  • 6.4.3: every script loaded and executed on payment pages in the consumer's browser is authorized, its integrity is assured, and there is an inventory with a written justification for each.

  • 11.6.1: a change- and tamper-detection mechanism alerts on unauthorized changes to the security-relevant HTTP headers and contents of payment pages as the browser receives them, run at least weekly or as often as a targeted risk analysis sets.

Want a second opinion on this for your system?

Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.

Which applies to you

How you take cards

Typical validation

What applies

Fully redirected to the processor's hosted page, or the processor's embedded iframe

SAQ A

Since the January 2025 SAQ A update, 6.4.3 and 11.6.1 are not in SAQ A; instead you must confirm your site is not susceptible to script attacks that could affect your e-commerce systems

Your own page builds the card form or posts card data straight to the processor (direct post, or script on your page that captures card data)

SAQ A-EP

6.4.3 and 11.6.1 apply to your payment pages

Card data touches your servers

SAQ D or a full assessment

Everything, and a much larger scope

How to meet them

  1. Prefer the processor's hosted page or iframe. It is the single biggest reduction in scope and risk.

  2. Keep payment pages minimal: no tag managers, chat widgets, A/B testing or analytics scripts on them.

  3. Set a strict Content Security Policy on payment pages listing exactly the script sources allowed, and use Subresource Integrity for scripts you load from fixed URLs.

  4. Serve those headers from your CDN (CloudFront response headers policies, for example) so they cannot be dropped by an application change.

  5. Monitor the page as browsers see it, using a script-monitoring service or CSP violation reports collected and alerted on.

hoolco Monthly Review

Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.

As of October 26, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.