PCI DSS 4.0 is Now in Full Effect: What That Means for E-Commerce Merchants
Many e-commerce merchants believe choosing a PCI-compliant payment processor covers their security responsibilities. Starting March 31, 2025, that assumption put them at risk.
Under PCI DSS v4.0.1, even merchants that outsource payment processing must meet stricter security requirements, especially around third-party scripts.
For years, outsourcing payment processing allowed merchants to complete a streamlined Self-Assessment Questionnaire A (SAQ A). This process was meant for low-risk businesses that never directly handled payment data.
But now, a single line in the updated SAQ A changes everything: merchants must certify that their "site" is "not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s)." The word "site" expands the scope, requiring merchants to verify the security of their entire website, not just the payment components.
Recent FAQs from PCI DSS regulators offer clarity. Merchants can confirm their sites’ security by following the controls in PCI DSS requirements 6.4.3 and 11.6.1, or by obtaining assurances from PCI DSS-compliant third-party providers or payment processors.
The update applies to merchants that use embedded payment pages (e.g., iframes). It doesn't apply to merchants that redirect customers to a third-party site or fully outsource payment functions.
While these updates reflect the growing threat of client-side attacks, they create major challenges. Many merchants lack the expertise to detect vulnerabilities on their sites. With 98.9 percent of sites using client-side scripts, countless businesses may struggle to certify compliance. Even full outsourcing may not fully protect them.
Client-Side Attacks: Techniques and Risks
Merchants must understand their payment page architecture. Each approach — redirect pages, embedded forms, and APIs — has its own vulnerabilities that attackers know how to exploit.
The Redirect Trap: When Trust Fails
Redirect payment pages seem safe. Customers enter card data on a provider’s domain, like Stripe or PayPal. However, attackers exploit this trust. By injecting malicious code into a merchant’s site, they intercept redirects and send visitors to pixel-perfect fake pages. Targeting just 1 percent to 2 percent of transactions helps attackers stay undetected for weeks.
If an attacker hijacks the redirect, the payment processor’s security doesn’t matter. The customer never reaches the real payment page. The merchant’s site security becomes the only defense.
The iframe Illusion: Embedded Payment Forms
Embedded forms show a payment provider’s form inside a merchant’s site using an iframe. This creates a seamless experience — but also a risk.
Attackers can overlay an invisible iframe on top of the legitimate one. Customers believe they’re entering data into the secure form, but their information is captured by the attacker's fake overlay.
The API Paradox: Custom Payment Forms
Custom payment forms allow merchants to design their own checkout experiences and transmit data via APIs. While flexible, this method creates even greater risk.
Attackers can inject keylogging scripts that capture sensitive card information before it ever reaches the secure API. Overlay attacks can also occur, just like with embedded forms.
In all cases, any JavaScript running on the checkout page — analytics tools, customer support widgets, chatbots — can become an entry point for client-side attacks.
How Client-Side Attackers Breach Sites
Modern e-commerce sites unintentionally open doors for attackers. JavaScript frameworks dynamically update content, giving every script access to sensitive payment elements.
Open-source software dependencies introduce more risk. A single compromised component can silently harvest payment data. Development teams often have no way to detect these breaches.
Older platforms, especially PHP-based ones, create further vulnerabilities. They weren’t built to defend against today’s sophisticated client-side threats.
The New Reality: Client-Side Security is Essential
PCI DSS 4.0 makes it clear: relying on compliant payment processors is no longer enough. Merchants must actively protect their sites from client-side threats.
Traditional security tools — e.g., crawlers, manual reviews and blacklists — cannot detect highly targeted, stealthy attacks. These exploits often activate under specific conditions, making them hard to catch.
To stay secure, merchants must deploy continuous, real-time monitoring across their entire client-side environment, with automatic threat detection and mitigation.
E-commerce merchants must rethink their security strategies. Those who act now will not only meet compliance standards but also protect their customers, their reputation and their bottom line from the rising wave of client-side attacks.
Simon Wijckmans is the CEO and founder of c/side, the only fully autonomous detection tool for assessing third-party scripts.
Simon Wijckmans is the CEO and founder of c/side. Previously, he held product management roles at Cloudflare and Vercel, where he focused on web security.
