PCI DSS 4.0.1 Is Here. Most Online Stores Don't Know They're Already Violating It.

Let's start with a scenario. You run an online store. Customers check out, enter their card details, maybe save them for next time. Business is good. You've got a payment processor you trust — maybe Shopify or WooCommerce — and you've been told the platform "handles PCI compliance."

Here's the problem with that: as of March 31, 2025, two brand-new mandatory security requirements went into full effect — and the vast majority of online merchants, including ones on "PCI-compliant" platforms, are failing them. Not because they're reckless. Because the rules changed and almost nobody told them.

That's what this post is about.

So What Even Is PCI DSS?

PCI DSS stands for Payment Card Industry Data Security Standard. It's a set of security rules created by the five major card networks — Visa, Mastercard, American Express, Discover, and JCB — through a body called the PCI Security Standards Council.

The short version: if your website touches payment card data in any way, you're expected to follow these rules. That includes stores that outsource payment processing to Stripe or PayPal. Your checkout page still loads in the customer's browser. That browser is in scope.

PCI DSS has been around since 2004. Version 3.2.1 held the standard for years. Then came Version 4.0 — and it changed a lot.

When Did PCI DSS 4.0.1 Take Effect?

There were two distinct phases to the rollout:

• Mar 31, 2024
  Version 3.2.1 officially retired

  All merchants and service providers must now operate under PCI DSS 4.0.1 (updated to 4.0.1). No more extensions, no grandfathering.
• Mar 31, 2025
  Future-dated requirements become fully mandatory

  Requirements that were labeled "best practices" during the transition period became fully enforceable. This is the date that matters most for e-commerce merchants — two of the biggest new requirements hit right here.

Think of it like a law that passed but gave businesses two years to prepare. The grace period ended. The hammer dropped.

The Two Requirements Catching Merchants Off Guard

Requirement 6.4.3 — Script Control

Every single JavaScript file that loads on your payment or checkout page must be inventoried, authorized, and integrity-verified. You need a documented list of every script, a business reason for each one, and a method to detect if any of them are changed without your knowledge.

Why does this matter? Because web skimming attacks — where hackers inject malicious code into checkout pages to steal card numbers in real time — have become one of the most common forms of payment fraud online. The Magecart group has compromised thousands of e-commerce sites this way. Your visitors type their card number into what looks like your form. That data goes to you and to the attacker. You may not find out for months.

Requirement 6.4.3 is the standard's answer to that threat. If you can't prove you know what JavaScript is running on your checkout page, you're non-compliant.

Requirement 11.6.1 — Tamper Detection

Beyond knowing what's there today, you need a system that alerts you when something changes. If a script gets added, modified, or removed from your checkout page without authorization — someone needs to know, in near real time.

Requirement 11.6.1 also covers the HTTP security headers your web server sends — the invisible instructions that tell browsers what to trust and what to block. Missing or misconfigured headers aren't just a compliance checkbox. They're open doors.

What Are the Real Risks?

Non-compliance isn't an abstract regulatory technicality. The consequences are real and fast-moving once something goes wrong.

You don't have to get breached to face consequences. Acquiring banks are increasingly requiring merchants to demonstrate compliance — not just sign a form saying they are.

The "My Platform Handles It" Myth

Yes, Shopify, WooCommerce, Magento, and similar platforms handle the server-side payment infrastructure. That's real and it matters. But your checkout page is a browser experience. It loads Google Tag Manager. Analytics scripts. Chat widgets. A/B testing tools. Third-party pixel trackers. Every one of those scripts is a potential vector for a web skimming attack.

Requirement 6.4.3 applies to every script that loads in the browser during the checkout flow — regardless of where payment processing happens on the backend. The platform can be fully PCI-compliant on its servers while your storefront is failing a critical browser-side requirement.

What Does a Compliant Checkout Look Like?

You don't need to become a security engineer — but you do need visibility and a clear action plan. Here's what compliance looks like in plain terms:

What Should You Do Right Now?

Step one is understanding where you stand. You can't fix what you can't see — and most merchants genuinely don't know how many third-party scripts are loading on their checkout pages, or what those scripts are doing.

A proper client-side security scan of your checkout and payment pages will show you exactly what's there, what's missing, what headers are configured correctly, and where the critical gaps are. That's the starting point for any real compliance conversation.

PCI DSS 4.0.1 isn't a bureaucratic inconvenience. It exists because the attack patterns it addresses are real, active, and profitable for criminals. Magecart-style web skimming attacks hit British Airways, Ticketmaster, Newegg, and hundreds of smaller merchants. The customers whose cards were stolen didn't know their data was being intercepted. Neither did most of the merchants.

The standard finally caught up to the threat. Now it's up to merchants to catch up to the standard.