The PCI deadline that already passed: what online ordering sites need now
By Yan Payments
If you take online orders, this already applies to you
PCI compliance used to feel like an annual chore: fill out a self-assessment questionnaire once a year, check a box, move on. That changed with PCI DSS v4.0.1. The older standard, v3.2.1, was retired back in March 2024, and the transitional v4.0 version was fully retired at the start of 2025, which makes v4.0.1 the only version the card networks and your processor will accept now.
The bigger shift is what’s inside it. When v4.0 was first published, a batch of 51 requirements were marked “future-dated,” meaning they existed on paper but weren’t enforced yet. As of March 31, 2025, that grace period ended. All 51 are now mandatory, with no phase-in and no exceptions during assessment.
Two of those requirements are aimed squarely at anyone running a payment page: online ordering, an e-commerce checkout, a “pay your invoice” link, any page where a customer types in a card number.
The two requirements that catch people off guard
Requirement 6.4.3 covers every script that loads on a payment page. You now need to know what scripts are running there, confirm each one is actually authorized to be there, and have a documented business reason for it. That sounds bureaucratic, but it exists because of a very real attack pattern: a third-party script (an analytics tag, a chat widget, an ad pixel) gets compromised or swapped out, and it starts quietly copying card numbers as customers type them in. This is often called a Magecart-style attack, and it doesn’t touch your server at all, so a server-side security scan won’t catch it.
Requirement 11.6.1 requires a change- and tamper-detection mechanism on your payment pages: something that watches the actual page content and headers as a customer’s browser receives them, and alerts you if a script or header changes without authorization. The standard sets a minimum check frequency of at least once every seven days, though your own risk assessment can call for more often.
If your checkout runs through a payment processor’s hosted page, iframe, or redirect (common with Clover’s online ordering and most modern e-commerce setups), a lot of this burden shifts to the processor rather than sitting entirely on you. But you still need to confirm that’s actually how your setup works, not assume it.
A quick way to check where you stand
| Your setup | What you likely need to do |
|---|---|
| Fully hosted checkout (customer redirected to the processor’s page) | Confirm with your processor that they’re handling 6.4.3 / 11.6.1 on their page; keep that confirmation on file |
| Embedded iframe from your processor on your own site | Same as above, but also check that nothing on your surrounding page (ads, chat tools) can read into the iframe |
| Custom-built checkout form on your own server | You’re responsible for inventorying every script on that page and standing up tamper detection yourself, likely with a specialized vendor tool |
| Card-present only, no online ordering | These two requirements don’t apply to you directly, but the rest of v4.0.1’s baseline requirements still do |
What to actually do this week
- Ask whoever hosts your online ordering or checkout page directly: “Is our payment page compliant with PCI DSS requirements 6.4.3 and 11.6.1?” A real processor should have a clear answer, not a shrug.
- Pull your current PCI self-assessment questionnaire and confirm it’s the v4.0.1 version, not an old v3.2.1 form someone’s been recycling.
- If you built your own checkout page in-house, this is worth a conversation with a PCI-qualified security assessor before your next assessment cycle, not after.
Getting this wrong doesn’t just risk a compliance headache. A card-data breach traced back to a skimmed payment page can mean network fines, mandatory forensic investigations, and in some cases losing the ability to accept cards at all until it’s resolved. Those costs land on the merchant whose name was on the checkout page, regardless of which vendor’s script actually caused the problem.
One point of confusion: v4.0.1 itself didn’t add anything new on top of v4.0. It’s a cleanup release, fixing typos and clarifying wording in requirements that already existed. If your processor or QSA mentions v4.0.1 specifically, they’re not describing a new deadline, they’re just naming the current, correct version of the standard you’re already supposed to be following.
The bottom line
The deadline already passed. If nobody’s asked you about requirements 6.4.3 and 11.6.1 yet, that doesn’t mean you’re clear, it means the question hasn’t reached you. For most small merchants running ordering through Clover or a similar hosted platform, the fix is usually confirming your processor has it covered, not building new security infrastructure yourself. But confirm it, don’t assume it.
If you’re not sure how your online ordering setup handles this, talk to us and we’ll help you check.
Sources
← Back to all posts