The Outsourced Illusion: Why Even “Cardless” E-Commerce Merchants Now Face PCI DSS Scans
The New Compliance Curveball: Scanning the “Cardless” Merchant
Picture this: a small online shop, never storing or seeing a customer’s credit card number, relying entirely on a trusted payment processor. For years, these merchants, classified as SAQ A, enjoyed the lightest compliance load. No card data on their servers, no heavy security checklist. Suddenly, PCI DSS v4.x lands, and with it, a new rule: quarterly external vulnerability scans, performed by a certified third party, are now mandatory. The question echoes: if the merchant never handles card data, why scan their website at all?
SAQ A: The “Hands-Off” Payment Model, Explained
SAQ A is the self-assessment path for e-commerce merchants who have fully outsourced payment processing. Two flavors exist: some redirect customers to a payment processor’s site (the customer leaves the merchant’s domain entirely), while others embed a payment form from a compliant third party using an iframe. In both cases, the merchant’s own systems never see the card number. The card data lives and dies on the payment processor’s servers. This setup, by design, was supposed to keep the merchant’s compliance burden light.
The Quiet Revolution: PCI DSS v4.x Changes the Game
For years, the logic was simple: no card data, no scan. Requirement 11.3.2, the rule mandating external vulnerability scans, didn’t apply to SAQ A merchants. That changed with PCI DSS v4.x. Now, even the most hands-off e-commerce merchants must submit to quarterly scans by an Approved Scanning Vendor (ASV). The update slipped in quietly, but its impact is anything but subtle. Suddenly, the “easy” compliance path isn’t quite so easy.
Requirement 11.3.2, Unpacked: What It Really Means
Quarterly. External. Vulnerability. Scans. That’s the heart of 11.3.2. Every three months, every internet-facing system in PCI scope, including web servers, firewalls, and anything exposed to the public internet, must be scanned by an ASV. The only way devices can be considered out of scope is if the customer does not control them, or if they implement segmentation and have no connectivity to the CDE. These aren’t just any scans. The ASV is a company certified by the PCI Security Standards Council, with tools and processes scrutinized and re-qualified every year.
External means the scan comes from the outside, mimicking the perspective of an attacker probing for weaknesses. A passing scan? No vulnerabilities with a CVSS score of 4.0 or higher. No default passwords. No open doors. If the scan finds issues, the merchant must fix them and rescan. The cycle repeats until a clean bill of health is achieved. And it’s not a one-and-done affair: merchants must keep evidence of four passing scans, one per quarter, over the past year.
Internal scans, by contrast, look inward, searching for weaknesses inside the network. ASV scans look outward, simulating the real-world threat. For more complex environments, 11.3.2.1 may add extra requirements, but the core remains: quarterly, external, passing scans.
Another thing I hear all the time is “we use a 3rd party content provider or xyz company is protecting our website, so we don’t need to do ASV scans”, this is not true. These types of issues could be considered “Scan Interference” because they block the scanner from scanning the actual systems. Check out these two blog posts: one on using Cloudflare and a breakdown of the ASV Program Guide (which you should have already read if you have to do ASV scans).
The Real Threat: Why the Merchant’s Website Still Matters
If the merchant never touches card data, why bother? The answer lies in the modern attacker’s playbook. Magecart-style attacks, where malicious JavaScript is injected into e-commerce sites, can skim card data as customers type, even if the payment form is technically hosted elsewhere. DOM-based skimming takes it further, with scripts on the merchant’s page intercepting or manipulating data before it reaches the secure payment environment or altering the behavior of embedded iframes.
Redirect hijacking is another favorite: compromise the merchant’s site, change the redirect, and customers land on a fraudulent payment page. In all these scenarios, the merchant’s website is the gateway. It doesn’t store card data, but it controls the path by which card data is entered. Compromising that gateway is enough.
Third-party scripts, analytics, marketing, and A/B testing tools loaded on checkout pages add yet another layer of risk. Any one of them can become a vector for skimming.
“Even if the merchant’s site does not directly receive or process cardholder data, it acts as the gateway to the payment process. If compromised, it can redirect customers to attacker-controlled sites or inject malicious scripts that interact with embedded payment forms.”
Outsourcing Payment ≠ Outsourcing Risk
There’s a compliance myth that dies hard: outsource a function, and the risk goes with it. Not so. The merchant controls the webpage. The merchant decides which third-party scripts to load. The merchant is responsible for the integrity of the redirect or the parent page hosting the iframe. PCI SSC’s guidance is blunt: having a compliant payment processor isn’t enough. The merchant must also confirm that their own site can’t be used as an attack vector against their customers.
PCI SSC’s Fine Print: Redirects, Iframes, and the Script Dilemma
PCI SSC draws a sharp line between merchants who fully redirect customers to a payment processor (the customer leaves the merchant’s page entirely) and those who embed iframes. For full redirects, the new script-attack protections may not apply in the same way. For iframe-embedding merchants, the bar is higher: either implement protections against script-based attacks directly, or get written confirmation from the payment provider that their solution is protected when deployed as instructed.
Misclassifying the payment environment, claiming SAQ A eligibility when the site actually loads scripts that could interact with the payment form, can turn a simple compliance checklist into a sprawling, expensive project.
What This Means on the Ground: The New Normal for SAQ A Merchants
Quarterly ASV scans are now a fact of life for SAQ A merchants. Budgeting for them is non-negotiable. The goal isn’t just to check a box, but to close the window that attackers use to compromise customer-facing payment flows. Every third-party script on a checkout page is a potential attack surface. The scan-remediate-rescan cycle demands ongoing attention, not a once-a-year scramble. The compliance clock never stops: four passing scans in the last 12 months is the minimum bar.
Where the Line Blurs: The Future of E-Commerce Security
The story of Requirement 11.3.2 is a warning shot. The boundary between “in scope” and “out of scope” in payment security is dissolving. Attackers don’t care where the card data lives; they care where trust is placed. If the merchant’s website is the gateway, it’s a target, no matter how far removed from the actual payment processing. As compliance standards evolve, the question lingers: how much trust can be placed in the spaces between the merchant and the payment processor, and what is broken?
Key Takeaway:
Outsourcing payment processing doesn’t mean outsourcing risk. Under PCI DSS v4.x, even merchants who never touch card data must now prove their websites aren’t a backdoor for attackers.
