Shopify PCI DSS 4.0 compliance: what merchants actually own

Shopify is a PCI DSS Level 1 service provider. That is the highest certification level, and Shopify's compliance page prominently states that all merchants on the platform "inherit" this compliance. Many Shopify merchants interpret this to mean their store is covered. It is not quite that simple.

Shopify's certification covers Shopify's infrastructure, the hosted checkout, and Shopify Payments processing. It does not cover the JavaScript your store loads from third-party vendors, the apps you install, your theme customizations or the scripts those apps inject onto your payment pages. PCI DSS 4.0 requirements 6.4.3 and 11.6.1, mandatory since March 2025, place specific obligations on merchants that Shopify cannot satisfy on their behalf.

This article explains the boundary between what Shopify owns and what merchants own, how SAQ eligibility works for Shopify stores, what PCI DSS 4.0's script requirements mean for Shopify merchants specifically and what has changed with Shopify Plus checkout extensibility.

What Shopify's PCI Level 1 certification actually covers

Shopify completes an annual Report on Compliance assessed by a Qualified Security Assessor. This covers Shopify's data centers, network infrastructure, the Shopify platform itself and the payment card data that flows through Shopify Payments. When a customer enters card details into the native Shopify checkout, those details are handled entirely within Shopify's certified environment.

The certification means Shopify has implemented the administrative, technical and physical controls required by PCI DSS across its own environment. It says nothing about what happens on the merchant-controlled portions of the page before the customer reaches the checkout, and it says nothing about the scripts individual merchants add.

Think of it this way: Shopify certifies that the vault is secure. Merchants are responsible for what they put in the hallway before the vault door.

The cardholder data environment boundary

PCI DSS defines a cardholder data environment (CDE) as the systems and processes that store, process or transmit cardholder data, plus any systems connected to it. For Shopify merchants using the native checkout, Shopify's hosted checkout is the CDE. The merchant's storefront pages are not directly within the CDE.

However, the storefront pages are considered "connected to" the CDE because they load in the same browser session as the checkout. A script injected on the product or cart page can persist into the checkout session and exfiltrate data entered there. This is exactly the attack vector that PCI DSS 4.0 requirements 6.4.3 and 11.6.1 address. The full guide to requirements 6.4.3 and 11.6.1 explains the technical scope in detail.

SAQ eligibility for Shopify merchants

Self-Assessment Questionnaires are the compliance validation mechanism for most merchants who are not required to complete a full Report on Compliance. The SAQ you qualify for determines how much compliance work you need to do. The changes to SAQ A in PCI DSS 4.0 are particularly relevant for Shopify merchants.

SAQ A: the standard Shopify merchant path

SAQ A applies to merchants who fully outsource all cardholder data functions to PCI DSS compliant third parties and have no electronic storage, processing or transmission of cardholder data on their own systems or premises. For Shopify merchants, this means:

• Using Shopify Payments or a fully hosted third-party payment page (Shopify Checkout handles everything).
• No custom scripts on the checkout page that could intercept or transmit card data.
• No redirect to a self-hosted payment page.
• Card data never touches merchant-controlled servers.

If this describes your store, SAQ A is your likely path. SAQ A has 22 requirements. It is the simplest questionnaire and covers physical security, vendor management and ensuring your outsourced payment environment is properly certified.

The important caveat: SAQ A merchants still have obligations under PCI DSS 4.0 that were added specifically to address script threats. Requirement 6.4.3 and 11.6.1 were added to SAQ A in version 4.0. This was a significant change from PCI DSS 3.2.1, where SAQ A merchants were largely exempt from script monitoring. Even the simplest Shopify merchant now has script inventory and monitoring obligations.

When SAQ A-EP or SAQ D applies

SAQ A-EP applies when merchants redirect customers to a third-party payment page but the redirect is from a merchant-controlled page that could affect the payment form. If your checkout involves any merchant-side JavaScript executing before the redirect, you may fall into SAQ A-EP rather than SAQ A.

SAQ D is the most comprehensive questionnaire, covering all 12 requirement domains. Shopify merchants who process card data in ways that go beyond fully hosted payment typically need SAQ D. This includes merchants who use direct post methods, iframes from non-Shopify payment processors or any configuration where card data could pass through or be accessible to merchant-controlled code.

Understanding which SAQ applies to your Shopify configuration is not always obvious. The hosted payment page architecture is covered in depth in our guide on hosted payment pages and PCI compliance.

Shopify Plus checkout extensibility and PCI implications

Shopify Plus merchants have access to checkout extensibility, Shopify's framework for customizing the checkout experience. This replaced the older checkout.liquid approach and changes the PCI picture significantly.

checkout.liquid vs checkout extensibility

The older checkout.liquid approach allowed Shopify Plus merchants to modify checkout HTML directly. It was flexible but created significant PCI risk because arbitrary code could be inserted into the checkout template. Shopify deprecated checkout.liquid for new customizations and required migration to checkout extensibility for all Shopify Plus stores by August 2024.

Checkout extensibility uses a sandboxed UI extension model. Merchants build checkout customizations as Shopify Functions and UI extensions that run within Shopify's controlled environment. The extensions execute in a Shopify-controlled sandbox, limiting direct DOM access and reducing the risk of script injection compared to raw checkout.liquid modifications.

From a PCI perspective, this is a significant improvement. The sandboxed model means that well-built checkout extensions are much less likely to introduce scripts that can intercept card data. However, the sandbox is not a complete control boundary.

Shopify Functions and their PCI scope

Shopify Functions run server-side within Shopify's infrastructure. They handle logic like discount calculations, shipping rules and payment method customization. Because they run on Shopify's servers rather than in the customer's browser, they are within Shopify's certified scope and do not introduce client-side script risks.

UI extensions are different. These are client-side components that render within the checkout UI. They load JavaScript in the customer's browser within a Shopify-managed sandbox. The key question for PCI compliance is what that JavaScript can access. Shopify's checkout extension sandbox restricts access to cardholder data fields, which is the right design. But extensions can still make network requests and interact with the checkout context in ways that require review.

Merchants using checkout extensions need to treat each extension as a third-party script for the purposes of requirement 6.4.3. Each extension installed on your checkout requires documentation of its purpose and verification that it is from an authorized source. The guide to third-party scripts and PCI DSS 4.0 explains how to approach this inventory process.

Third-party apps and scripts on Shopify payment pages

This is where most Shopify merchants are non-compliant with PCI DSS 4.0 without knowing it. Shopify's app store contains over 8,000 apps. Each app that is installed on a Shopify store has the potential to inject scripts onto storefront pages, cart pages and in some cases the checkout page.

How Shopify apps inject scripts

Shopify apps use several mechanisms to add JavaScript to store pages. The ScriptTag API allows apps to register a URL that Shopify will include as a script tag on all storefront pages. This is the most common and most broadly scoped mechanism. A script registered via the ScriptTag API loads on every page of your store unless specifically restricted.

Theme app extensions allow apps to add content to specific theme templates. Merchants add app blocks to their theme in the theme editor. These inject code into the pages where the blocks are placed.

Checkout extensions allow apps to add functionality specifically to the checkout. These are gated by Shopify's review process for Shopify Plus stores.

The ScriptTag API is the most problematic for PCI compliance. Scripts registered this way load on all storefront pages, including the cart. If a customer has items in their cart and browses product pages, scripts from every installed app that uses the ScriptTag API are present in that browsing session. Any of these scripts could potentially persist into the checkout session.

The app review process is not PCI authorization

Shopify reviews apps before listing them in the app store. This review checks that apps follow Shopify's API usage guidelines and do not engage in clearly malicious behavior. It is not a PCI DSS security assessment. Shopify does not verify that app code is free of vulnerabilities that could be exploited for card data theft, and it does not certify apps as compliant with requirements 6.4.3 or 11.6.1.

Merchants are responsible for authorizing every script on their payment pages. Authorizing a script for PCI purposes means documenting its presence, its purpose and confirming it is intended to be there. It does not mean trusting that because an app is in the Shopify app store it is implicitly authorized.

Additionally, apps can update their scripts at any time. A script that was authorized at app installation may not be the same script running six months later. This is exactly the continuous monitoring problem that requirement 11.6.1 addresses. The broader context of script-based attacks is covered in our guide on Magecart attacks and ecommerce prevention.

Shopify's Script Manager and what it does

Shopify introduced Script Manager as a tool for merchants to view and manage scripts loaded on their store. It provides visibility into which apps are loading scripts and on which pages. This is a useful starting point for the inventory required by requirement 6.4.3.

Script Manager shows which apps have registered scripts, but it has limitations for PCI compliance purposes. It shows the scripts registered through Shopify's app infrastructure, but it does not capture all scripts that may load on your pages. Scripts loaded by other scripts, scripts loaded from Shopify theme code and scripts loaded via liquid includes may not all appear in Script Manager.

A complete inventory for requirement 6.4.3 requires loading your payment pages in a browser and capturing every script that executes, regardless of how it was loaded. The browser developer tools Network panel filtered to JavaScript requests gives an accurate picture. Script Manager is a useful administrative view, but it is not a compliance tool.

CSP headers on Shopify

Content Security Policy is one of the primary technical controls for satisfying requirement 6.4.3's integrity requirement. Shopify's approach to CSP differs between the checkout and storefront.

Checkout CSP

Shopify enforces a Content Security Policy on the native checkout. This CSP restricts which origins can load scripts on the checkout page. Merchants who attempt to inject arbitrary scripts into the native Shopify checkout will find them blocked. This is a significant protection for SAQ A merchants.

For Shopify Plus merchants using checkout extensibility, the CSP allows extension scripts loaded through Shopify's managed framework. Scripts that are not part of an authorized checkout extension will be blocked. This is by design and is part of what makes checkout extensibility safer than checkout.liquid from a PCI perspective.

Storefront CSP

Shopify does not enforce a strict Content Security Policy on storefront pages (product pages, collection pages, cart). This means that scripts loaded on storefront pages are not restricted by CSP in the way checkout scripts are. Merchants who want to implement CSP on storefront pages need to do so through their theme or through a Shopify app that modifies response headers.

Implementing a strict CSP on Shopify storefront pages is technically possible but practically difficult. Every app that injects scripts needs to have its origins whitelisted in the CSP. Many apps load scripts from multiple CDN origins or dynamically generate script URLs, making static CSP rules challenging to maintain.

Our guide on CSP headers for PCI DSS ecommerce compliance covers the implementation details, including how to handle third-party script origins and how to test CSP in report-only mode before enforcing it.

Requirement 6.4.3 applied to Shopify stores

Requirement 6.4.3 requires that all scripts on payment pages are authorized, have their integrity verified and are documented in an inventory with business justification.

For a typical Shopify merchant, the payment pages in scope are the cart page and any page containing a payment widget or form. The checkout page itself is within Shopify's scope for SAQ A merchants, but the scripts on pages leading to checkout are the merchant's responsibility.

Building the inventory for a Shopify store involves loading the cart and checkout pages in a browser and recording every script. A mid-market Shopify store typically runs between 15 and 35 scripts on the cart page, sourced from analytics platforms, marketing pixels, chat tools, session recording tools, review apps and tag management systems. Many merchants are surprised by the count.

Tag managers complicate the picture significantly. If your Shopify store uses Google Tag Manager, Segment or a similar tool, the tag manager itself counts as one script but it dynamically loads additional scripts based on its configuration. For PCI compliance, you need to inventory and authorize every script loaded by the tag manager, not just the tag manager container itself. Our guide on tag managers and PCI compliance covers this in detail.

Subresource Integrity provides a mechanism to verify that scripts have not been modified since you authorized them. For scripts loaded from external CDNs where the provider does not update the URL when updating the script, SRI hashes confirm content integrity at load time. The practical application and limitations of SRI are explained in our guide on subresource integrity for ecommerce scripts.

Requirement 11.6.1 applied to Shopify stores

Requirement 11.6.1 requires a mechanism to detect unauthorized changes to HTTP headers and page content on payment pages as received by the consumer browser, checked at minimum every seven days.

For Shopify merchants, this means monitoring the actual state of payment pages as a browser would see them. This cannot be satisfied by checking what your Shopify admin shows you. It requires loading the page as a browser would, capturing the full set of scripts and headers and comparing against a known-good baseline.

The requirement applies even for SAQ A merchants. This was a deliberate change in PCI DSS 4.0 to address the reality that Magecart attacks often compromise storefront pages rather than the checkout itself, using the browsing session to establish persistence before card data is entered.

Shopify app updates can change which scripts load on your pages without any action on your part. An app installed months ago may have been updated to load additional scripts, change the origin of existing scripts or modify how it interacts with the page. Automated monitoring that alerts when the script inventory changes is the only way to catch these changes reliably.

The seven-day cadence is a minimum. For merchants with higher transaction volumes or who have previously experienced security incidents, daily monitoring provides substantially better detection windows. The guide to JavaScript supply chain attacks in ecommerce explains why faster detection matters: the average Magecart compromise runs for 22 days before detection.

What a compliant Shopify store looks like

A Shopify merchant who has addressed PCI DSS 4.0 requirements 6.4.3 and 11.6.1 has done the following.

They have audited every script on their cart page and any page containing payment interactions. They have removed scripts that do not need to be present on payment pages. Marketing pixels that only need to fire after purchase confirmation have been moved to the thank-you page. Chat widgets have been suppressed on the checkout flow.

They have documented each remaining script: its source, its purpose and why it is authorized to be present. This inventory is maintained and updated when apps are added or removed.

They have implemented integrity controls. For scripts loaded from external sources, they have applied SRI hashes where the vendor supports it. They have implemented a CSP for checkout pages that restricts script sources to authorized origins.

They have deployed browser-based monitoring that loads their payment pages on a schedule, captures the script inventory and alerts when anything changes from the baseline. The alert reaches someone who can investigate within the timeframe needed to stay within the seven-day detection window.

They have confirmed their SAQ eligibility based on their actual checkout configuration. If they are using Shopify Plus checkout extensions, they have reviewed each extension as a third-party script and documented it in the inventory. The payment page security guide covers the full range of controls relevant to this configuration.

Common gaps in Shopify PCI compliance

Based on the most common patterns we see, Shopify merchants typically have these gaps.

First, they have no script inventory. They know they have installed 15 apps but have not checked how many scripts those apps collectively load on payment pages, what origins they load from or whether any of those apps have changed their scripts since installation.

Second, they assume Shopify's certification covers them. The PCI FAQ on the Shopify help center encourages this belief. Shopify says merchants can "inherit" PCI compliance. This is true for the narrow scope of Shopify's hosted services. It is not true for the merchant's responsibilities around script management.

Third, they have never checked what their cart page looks like from the outside. When we scan Shopify stores, we consistently find scripts that the merchant was unaware of: old analytics tags from previous agencies, scripts from apps that were uninstalled but whose ScriptTag registrations were not cleaned up and scripts loaded by tag managers that the marketing team added without IT awareness.

Fourth, they have no monitoring. Even merchants who have done a one-time audit have no mechanism to detect changes. The PCI DSS 4.0 requirement is for ongoing, automated, browser-based monitoring. A spreadsheet from last quarter is not compliant.

Frequently asked questions

Does Shopify's PCI Level 1 certification cover my store?

Shopify's PCI Level 1 certification covers Shopify's own infrastructure, the hosted checkout and Shopify Payments. It does not cover the scripts your store loads, the apps you install, your theme customizations or any third-party integrations. Merchants remain responsible for their own scope.

Can Shopify merchants use SAQ A for PCI DSS compliance?

Most standard Shopify merchants using Shopify Payments or a fully hosted payment page qualify for SAQ A, which is the simplest self-assessment questionnaire. Merchants using Shopify Plus checkout extensibility with custom scripts, or merchants who redirect to self-hosted payment pages, may need SAQ A-EP or SAQ D depending on how card data flows.

Do PCI DSS 4.0 requirements 6.4.3 and 11.6.1 apply to Shopify merchants?

Yes. Requirements 6.4.3 and 11.6.1 apply to any merchant with a payment page that loads scripts, regardless of platform. On Shopify, this means the checkout page, cart page and any page where a payment widget appears. Shopify apps, theme scripts and checkout extensions all fall within merchant scope for these requirements.