"My Platform Is PCI Compliant" — Why That's Not the Whole Story

It's one of the most common things we hear from merchants: "We don't need to worry about PCI DSS — our platform handles it." They're talking about Shopify, WooCommerce, Magento, BigCommerce, or any of the other major e-commerce platforms. And they're not entirely wrong.

Their platform does handle PCI compliance. For certain things. In certain places. On certain servers.

The problem is that "PCI compliant platform" and "PCI compliant store" are two completely different statements — and the gap between them is exactly where Magecart attacks happen, where compliance failures occur, and where merchants get blindsided by QSA findings they genuinely didn't see coming.

What Your Platform's PCI Compliance Actually Covers

When Shopify, WooCommerce, or any major platform says they're PCI compliant, they're telling you something true and important: their infrastructure — the servers, databases, networks, and systems that store and process payment card data — meets PCI DSS requirements.

Depending on the platform, that typically includes:

This is real, meaningful coverage. It means the servers holding your customers' card data — or the tokenization layer that replaces it — are protected to PCI DSS standards. That matters enormously. But it's server-side.

The Gap Nobody Talks About

Your checkout page is not a server. It's a browser experience — a collection of HTML, CSS, and JavaScript that executes in your customer's browser on their device. And the moment that page loads in their browser, it is outside the scope of your platform's PCI compliance certification.

The platform controls the server. You control — or are responsible for — what loads in the browser.

This isn't a technicality invented by PCI DSS 4.0.1. It's always been true. What PCI DSS 4.0.1 did was formalize it with Requirements 6.4.3 and 11.6.1 — creating specific, testable, enforceable controls around browser-layer script management and tamper detection that no platform compliance certification covers.

Who Owns What — The Full Responsibility Map

What a Real Breach Proves

If you need a concrete illustration of this gap, consider what happens in a typical Magecart breach on a Shopify or WooCommerce store. The platform is not compromised. The payment gateway is not compromised. Card data is properly tokenized on the backend. The platform's PCI certification is intact and accurate.

What's compromised is the checkout page — a piece of JavaScript that intercepts card data as the customer types it, before it ever reaches the tokenization layer. The attacker never touched the platform's servers. They exploited the browser layer, which the platform's PCI compliance doesn't cover and never claimed to.

After the breach, the merchant discovers they have a finding — not because the platform failed, but because the merchant had no script inventory, no tamper detection, and no awareness of what was loading on their checkout page. The platform was fully compliant. The merchant was not.

Platform by Platform: What Each Leaves to You

Shopify

Shopify is a Level 1 PCI compliant service provider — the highest level. Their infrastructure is genuinely well-secured. What Shopify does not control: the apps you install from the Shopify App Store, the custom code in your theme, the Google Tag Manager container you set up, the third-party tracking pixels your marketing team added, or the security headers your Shopify store sends. All of those load in the browser. All of those are your Req 6.4.3 responsibility.

WooCommerce

WooCommerce is a plugin running on WordPress. Your hosting environment, server configuration, security headers, and WordPress plugins are entirely your responsibility. Your payment gateway (Stripe, PayPal, Square) handles card data, but the scripts that load on your checkout page — including WooCommerce's own JavaScript, every plugin you've installed, your theme's scripts, and anything in GTM — are all in scope for 6.4.3. WooCommerce also has no tamper detection mechanism for Req 11.6.1 — that's your problem to solve.

Magento / Adobe Commerce

Magento's compliance posture varies significantly depending on whether you're on Adobe Commerce Cloud (managed) or self-hosting. Even on the cloud version, your extensions, custom modules, and third-party integrations load scripts in the browser that are entirely outside Adobe's compliance scope. Self-hosted Magento adds server-level PCI requirements on top of browser-layer obligations — it's the most demanding platform to run compliantly.

What You Actually Own — and What to Do About It

Accepting that browser-layer compliance is your responsibility isn't bad news — it's clarity. Once you know what you own, you can fix it. And the list of things that need fixing is finite:

• Script inventory — know every script loading on your payment pages
• Authorization documentation — business justification for each one
• Integrity controls — SRI hashes where possible, CSP everywhere
• Security headers — CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy
• Tamper detection — automated monitoring that alerts when scripts or headers change
• App/plugin review — audit what scripts your installed apps are loading on checkout

None of these require replacing your platform. None of them require rebuilding your store. They require visibility — knowing what's actually happening in the browser on your payment pages — and then addressing the gaps systematically.

Start With Visibility

The merchants who are most exposed aren't the ones who chose a bad platform. They're the ones who assumed their platform's compliance covered everything and never looked at what was actually loading in their customers' browsers.

The first step is looking. Run a scan on your checkout and payment pages and find out how many third-party scripts are loading, which security headers are present or missing, and what your current browser-layer exposure actually is. That's the baseline you need before you can close any gaps.