Somewhere in your inbox there is a message from your payment provider with the words "annual PCI validation" in it, and you have been not-opening it for three weeks. That is a normal reaction. It is also an expensive one, because nearly everything that makes a PCI compliance audit painful was decided months earlier, in choices nobody labelled as compliance decisions at the time.
Most owners assume the PCI Security Standards Council is the body coming after them. It isn't. The Council writes the standard and publishes the paperwork, and it says plainly that it "does not define compliance requirements for any organization or set compliance validation responsibilities." Those are set by the card brands, your acquirer, and your payment facilitator.
The Council's own merchant guidance puts the practical version this way: whether a small merchant has to validate compliance is determined by the individual payment brands, and merchants should contact their acquirer or payment brand to find out.
So the useful first question is not "what does PCI require of me." It is "what has my acquirer told me to submit, and by when." Two stores running identical technology can face very different validation work because they bank with different acquirers.
One thing does not vary. The standard itself applies to everyone handling card data, regardless of size or transaction volume. Only the proving part changes.
Here is the part most owners miss: the size of the audit is set by how card data moves through your store, not by how careful your team is.
If a shopper types their card number into a field your server rendered and your code can read, your store sits inside what the standard calls the cardholder data environment. The assessment then covers your whole stack: servers, network, access control, logging, patching, all of it. If the card details are captured entirely by your payment provider, in a hosted page or a provider-controlled iframe your site never touches, your store sits outside that environment and the questionnaire gets dramatically shorter.
That shorter route is SAQ A. The Council's January 2025 announcement describes who qualifies: merchants whose account data functions are completely outsourced to validated third parties, and who do not store, process, or transmit any account data in electronic form on their own systems or premises.
Two consequences owners rarely connect. A custom checkout that posts card fields through your own backend, added at some point to squeeze in a loyalty step or a one-page flow, can move you from the short form to the long one. And encrypting that data on your side does not undo it. The Council is blunt: encryption alone is generally insufficient to take cardholder data out of PCI DSS scope.
PCI DSS v4.x added two requirements aimed squarely at online stores, 6.4.3 and 11.6.1, and they took effect on 31 March 2025. In plain terms: you need to know every script that runs on your payment page, be able to say why each one is there, confirm none of them has been altered, and get alerted when the page or its HTTP headers change between your server and the shopper's browser.
That is not a firewall problem. It is a front-end governance problem, and most stores have never had one.
The Council acknowledged how hard this landed. After merchant feedback about the complexity, it removed 6.4.3 and 11.6.1, plus the supporting risk analysis in 12.3.1, from SAQ A. In their place it added an eligibility criterion: the merchant must "confirm their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)."
Read that carefully. The paperwork got shorter. The responsibility did not move. You still have to be able to say, honestly, that your checkout page cannot be poisoned by a script, and the Council stated that the change does "not remove or diminish the underlying requirements within PCI DSS."
Go and count what actually loads on your checkout page. Not the homepage. The page with the card fields on it.
On a typical store that has been trading for a few years, the list runs past a dozen: analytics, a session recorder, an A/B testing tool, a chat widget, a loyalty popup, two ad-network pixels, a reviews badge, and something a freelancer added in 2021 that nobody can identify anymore. Every one of those is third-party JavaScript executing in the same page as the card fields, and every one of them is a way in. That is precisely the mechanism behind checkout skimming on e-commerce sites, and it is why the standard moved here rather than somewhere more comfortable.
The business version of the problem is simpler than the technical one. Every marketing tag on your checkout page is a security liability and a compliance liability at the same time, and in most companies nobody owns the list.
Scripts are only half of it. The platform underneath the page runs on its own clock, and in September 2026 being current on patches turned out not to be protection. That clock also has an end date: a store on a release Adobe no longer supports stops receiving fixes altogether. A short questionnaire and a secure store are two different achievements, and only one of them is what your acquirer asks about.
Four moves, in the order that pays best.
Get the card fields out of your page. A hosted payment page or a provider-controlled iframe is the single largest reduction available, and nothing else comes close. We built two payment gateway plugins for a licensed European payment institution around exactly this pattern, hosted checkout with deliberately low PCI scope, because the alternative drags the merchant's entire platform into assessment. Everything below this is a smaller lever.
Take the marketing tags off checkout. Not off the site. Off the payment step.
Analytics on a product page is a completely different risk from analytics on a page with a card field in it, and only the second one matters here. Most stores can get to a clean checkout in a couple of weeks, and in our experience the conversion cost is roughly zero. The objection is always that marketing will lose the funnel. They lose very little in practice, because the purchase event still fires on the confirmation page, which is where it was always counted.
Write the script inventory down. Who added each script, why, and what breaks if it disappears. That list is the artifact 6.4.3 is asking for, and on most stores it is an afternoon of work rather than a project.
Ask your acquirer which questionnaire they expect, before you build anything new. The Council's guidance points merchants at the entity the questionnaire will be submitted to, typically the acquirer or the payment brands, to establish which one applies. A ten-minute email in January prevents a three-month scramble in October.
The pattern we see across the Magento stores we run under ongoing support and maintenance is consistent, and slightly unfair: the businesses with the least painful audits are not the ones with the most security tooling. They are the ones whose checkout is boring.
Before anyone fills in a form, open your checkout in a browser and look at what loads. If the honest answer is "we're not sure," that is the finding. Getting card data out of your own stack and keeping the payment page clean is the sort of work we handle at Encomage, and it usually starts with an audit of what is actually running there.
Let’s build something powerful together - with AI and strategy.
