The Green Sheet Online Edition
July 28, 2025 • 25:07:02
Demystifying ecommerce skimming: What merchants need to know
Earlier this year, attackers quietly exploited a payment processor’s API, injecting malicious scripts into legitimate merchant checkout pages, capturing customer credit card data before it was successfully processed. This is just the latest evolution in e-skimming, a threat many merchants still don’t fully understand, even as new PCI DSS v4.0.1 requirements attempt to address it.
For merchants, breaches like this can lead to significant financial losses, reputational damage and potential legal liabilities. For customers, it’s personal: unauthorized transactions and identity theft.
Scripts, hidden windows of vulnerability
Payment pages today rely on a complex web of scripts for analytics, marketing, form validation and payment processing. These scripts interact with the consumer’s browser, often pulling in content from multiple third- or even fourth-party sources. Every added script is a potential open window for attackers.
The guidance on PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1, has changed more than once in just a few months. This has left many acquirers, merchants and their third-party service providers (TPSPs) wondering: do these new requirements apply to me? If so, who’s responsible for covering them, me or my TPSP?
The confusion is real, and the risk is growing.
Why the new PCI DSS requirements matter
PCI DSS v4.0.1 addresses e-skimming head-on with two new mandates:
- 6.4.3: Merchants must maintain an inventory of scripts on their payment pages and document why each is necessary.
- 11.6.1: A tamper-detection mechanism must monitor scripts weekly and alert the merchant to unauthorized changes.
These requirements are sound, but implementation often reveals confusion, especially when TPSPs are involved.
TPSPs: Who’s doing what?
Many merchants use ecommerce platforms or web hosting partners to manage key elements of their checkout page. But this creates a common vulnerability: miscommunication.
This kind of thing happens all the time. For example, a merchant is using an ecommerce shopping cart supported by a third party. The merchant thinks the TPSP is responsible for patching it; the TPSP assumes it’s on the merchant. No one patches it, and that’s all it takes for a breach to happen. We see the e-skimming threat in a similar light.
What merchants should be asking
To assess areas of responsibility and potential vulnerability, merchants should ask the following questions:
- Does my ecommerce set-up put those two new requirements in scope for me?
- If so, is my TPSP supporting me by covering requirements 6.4.3 and 11.6.1?
- For PCI compliance, is my business QSA-reviewed or relying on self-assessment?
- Can I identify which third parties are embedded in my customer experience—and what they’re doing?
Take control: Four steps to protect your business and customers
Complexity is unavoidable, but so is the need for vigilance. Merchants can keep this simple by focusing on what they can control:
- Review current PCI DSS compliance posture
- Ensure clear responsibility mapping with TPSPs
- Monitor scripts actively to reduce exposure
Monitor HTTP headers for unexpected changes
This isn’t just about ticking boxes. It’s about owning your security, even when third-party partners are involved. Security gaps can emerge quickly. Compliance doesn’t guarantee security, but visibility helps.
If you don’t know who’s monitoring your scripts or patching your payment tools, chances are no one is. Now is the time to find out.
As director, PCI compliance, Aperia Compliance, an IXOPAY company, Chris Bucolo helps merchants and partners navigate and stay compliant with PCI DSS requirements. He has served on PCI working groups and works closely with stakeholders to turn complexity into clarity. Please contact him by email at c.bucolo@ixopay.com or LinkedIn at www.linkedin.com/in/chrisbucolo.
Notice to readers: These are archived articles. Contact information, links and other details may be out of date. We regret any inconvenience.
