If your business takes card payments online, a quiet but consequential deadline has already passed — and most store owners never saw it. As of 2026, the full PCI DSS v4.0.1 standard is in force with no grace period left, and for the first time the security of your checkout page itself — the code running in your customer’s browser — is explicitly your responsibility. This is not a minor revision. It targets the exact way card data is being stolen today, and the penalties for getting it wrong are immediate and financial.
The deadline that already passed
When PCI DSS v4.0 arrived, the Security Standards Council marked 51 of its new requirements as “future-dated,” giving merchants until March 31, 2025 to implement them. That date is gone. In 2026 every assessment is measured against the complete v4.0.1 standard, and the transitional allowances that softened the rules for three years no longer exist. A store that built its compliance around the 2023–2024 carve-outs is now being judged against controls it may never have switched on.
It is worth remembering that PCI DSS is not a government law — it is a contract with your acquiring bank and the card brands. That makes enforcement faster than regulation: non-compliance fines run roughly $5,000 to $100,000 per month, and a breach while non-compliant exposes you to forensic-investigation costs, card-reissuance charges, direct liability, and in the worst case the loss of your ability to accept cards at all.
Why your checkout page is the target
For years the mental model of payment security was server-side: lock down the database, encrypt what you store. But that is no longer where the theft happens. Card data is increasingly skimmed in the shopper’s own browser through an attack known as e-skimming, Magecart, or formjacking. An attacker compromises a single JavaScript file on your payment page — often a third-party script you did not write — and silently copies card numbers as the customer types them, before anything is encrypted and entirely outside your back-end systems.
The scale is not theoretical. Security researchers have tracked more than 11,000 e-commerce domains actively running payment-page skimmers, a roughly 300% jump in a single year. Every analytics tag, chat widget, A/B-testing tool, and marketing pixel on your checkout is a potential entry point — and a compromise of any one of them is a compromise of your payment page.
The two requirements every online store must meet now
PCI DSS v4.0.1 answers this threat with two paired, client-side requirements:
- Requirement 6.4.3 — Maintain an inventory of every script that loads on your payment page, confirm each one is authorized with a documented business reason, and verify its integrity so a tampered or unexpected script is caught.
- Requirement 11.6.1 — Run a tamper-detection mechanism that alerts your team when the contents of the payment page, or its security-related HTTP headers, change without authorization. Weekly is the minimum; continuous monitoring is the real goal.
Two clarifications trip teams up. First, you cannot hand this off to your payment processor: even if card entry happens inside a hosted iframe, any script on your host page that can reach that iframe stays in scope. Second, a Content Security Policy alone is not enough — CSP can stop an unknown script from loading, but it will not tell you when an already-approved script quietly changes its behavior. The standard expects active verification and alerting, not a one-time setting.
A practical checklist for store owners
- Inventory every script on your checkout and cart pages — including the ones marketing added without telling engineering.
- Document a business justification and an owner for each script, and remove anything you cannot justify.
- Lock down sources with a tuned Content Security Policy, and validate static third-party scripts with Subresource Integrity (SRI) hashes.
- Stand up tamper and change detection that alerts on script and header changes — and route those alerts somewhere a human actually sees them.
- Keep evidence: a dated log of reviews, approvals, and alerts. In 2026, assessors expect proof of continuous operation, not a one-time switch-on.
How Vadimages helps
We build and maintain custom e-commerce systems — order management, checkout flows, and the multi-channel integrations that bolt third-party tools onto them — so the payment page is exactly the surface we work on every day. For teams facing v4.0.1, that means we can:
- Audit your live checkout and produce the script inventory and ownership map that Requirement 6.4.3 demands.
- Shrink the attack surface by consolidating tags, moving non-essential scripts off the payment path, and replacing risky third-party widgets with leaner custom code.
- Implement a tuned CSP and SRI, and wire up continuous tamper-and-header monitoring with alerting into the tools your team already uses — satisfying Requirement 11.6.1.
- Generate the ongoing evidence trail your Qualified Security Assessor will ask for, so compliance becomes a maintained system rather than an annual scramble.
If you run a custom or headless storefront, this is squarely the kind of operations-critical software work we do — and it is far cheaper to engineer in than to retrofit after a breach.
The bottom line
The grace period is over. In 2026, client-side payment security is simply part of the standard, and the e-skimming threat it addresses is one of the most active in commerce. The stores that treat 6.4.3 and 11.6.1 as a living system — inventory, verify, detect, review — will pass their assessments and protect their customers. The ones that treated March 2025 as a date that did not apply to them are now one compromised script away from a very expensive year.
This article is for general information and is not legal or compliance advice; consult a Qualified Security Assessor for your specific obligations.