PCI Compliance on Shopify: What You're Actually Responsible For

Shopify's marketing pages around PCI compliance tend to leave founders with the impression that the platform takes care of everything. That is half true, and the half that is not true is the half that costs money when a card brand assessor starts asking questions. Shopify is a PCI DSS Level 1 Service Provider, which is genuinely the highest tier of platform certification available, but a Level 1 service provider certification does not transfer to the merchants running on top of it. The merchant still has their own attestation to file, their own responsibilities to discharge, and under PCI DSS 4.0 those responsibilities got meaningfully heavier.

This article is the version nobody selling you software will write. It covers where Shopify's scope ends, where yours begins, how the picture shifts the moment you install a third-party checkout app, and what Shopify Plus merchants in particular need to look at now that PCI DSS 4.0 is in force.

What Shopify Actually Handles

Shopify Inc. maintains a PCI DSS Level 1 Service Provider certification covering the hosted checkout, Shop Pay, Shopify Payments, and the POS hardware stack. What that certification means in practice is that the Cardholder Data Environment, the infrastructure where the primary account number and related sensitive authentication data actually live, sits entirely inside Shopify's network. The card data is encrypted in transit and at rest, tokenized for reuse, segmented away from non-payment systems, and logged and monitored under the controls required of a Level 1 service provider. Shopify runs the quarterly Approved Scanning Vendor scans against its own infrastructure and submits to an annual audit by a Qualified Security Assessor.

For POS merchants, Shopify's card readers are validated under the Point-to-Point Encryption standard, which means card data is encrypted inside the reader hardware before it ever touches the merchant's local network or the point of sale device. That is a genuinely strong control and it is the reason a coffee shop running Shopify POS does not have to think about network segmentation for their in-store Wi-Fi in the way a merchant on a non-P2PE terminal would.

You can request Shopify's Attestation of Compliance through the Shopify Trust Center. If your bank, your acquirer, or a large enterprise customer ever asks for proof that your processor is PCI compliant, that document is what you send them. It is not public-facing, and it is worth pulling once a year to keep on file.

What You Still Own

Here is where most merchants get tripped up. A Level 1 service provider certification protects the pipes, not the merchant. Every Shopify merchant processing card payments is still a merchant under the PCI DSS, and every merchant still has to complete a Self-Assessment Questionnaire annually. The specific SAQ that applies to you depends on how card data flows through your environment.

The vast majority of Shopify merchants fall under SAQ-A. SAQ-A applies to merchants who have fully outsourced all cardholder data functions to a PCI-compliant third party and who never electronically store, process, or transmit any cardholder data on their own systems. If you are running a stock Shopify storefront with Shopify's hosted checkout, you are an SAQ-A merchant. The SAQ-A questionnaire is the shortest of the set and most of its controls are about the security of the merchant's general environment rather than a cardholder data environment that does not exist on your infrastructure.

Even as an SAQ-A merchant you still have real obligations. You still need strong authentication and multifactor authentication on your Shopify admin accounts, your app accounts, and any staff access that could be used to change the checkout configuration or redirect customers. You still need a documented incident response plan. You still need vendor risk management over the third-party apps touching your store. You still need security awareness training for anyone with admin access. And under PCI DSS 4.0 you now need an inventory of the scripts loaded on your payment pages along with a mechanism to detect changes, which we will come back to.

One specific point worth clarifying because search results get it wrong. SAQ-A merchants on Shopify's hosted checkout do not need to run external vulnerability scans against their storefront domain. The ASV scan requirement applies to systems in the cardholder data environment, and a storefront that simply redirects or embeds an iframe to Shopify's checkout has no cardholder data environment. If you move off SAQ-A, that changes immediately.

How PCI DSS 4.0 Changed the Picture

PCI DSS 4.0 became mandatory on March 31, 2025. For Shopify merchants the most consequential changes sit in Requirements 6.4.3 and 11.6.1, which together address a category of attack that did not really exist when PCI DSS 3.2.1 was written. These attacks, sometimes called Magecart or web skimmer attacks, work by compromising a third-party script that the checkout page loads and using it to silently exfiltrate card data as the customer types it. The victim merchants in the original wave of these attacks were mostly large retailers running their own checkouts, but the attack class is broad enough that the PCI Council extended script controls to every merchant who has a payment page, including SAQ-A merchants.

In practical terms this means you now have to maintain an inventory of the scripts that execute on your payment page and you need some mechanism to detect when those scripts change in unexpected ways. On a stock Shopify checkout, Shopify controls the page and the scripts that load on it. That is good news. But if you have installed an app that injects a script into the checkout, or if you are on Shopify Plus and have configured custom checkout extensions, you own the inventory for those scripts. The SAQ-A 4.0 questionnaire asks you directly whether you know what is loading on your payment page and whether you would notice if it changed.

Requirement 12.3.1 under 4.0 introduces the Targeted Risk Analysis, which is a documented reasoning artifact for any control where you are using the flexibility that 4.0 allows in how a control is implemented. This is a paperwork requirement, but it is a paperwork requirement that did not exist before and that assessors will ask for.

Multifactor authentication has also expanded. Under 4.0 it is required on any account that accesses cardholder data and on any administrative access to systems in scope. For Shopify merchants this essentially means MFA on your admin, your staff accounts, and the accounts of third-party agencies who have access to your store.

Where Scope Expands Without You Noticing

The SAQ-A posture depends on a clean architectural fact: card data never touches systems you control. There are several ways a Shopify merchant can silently lose that property, and the most common ones are all driven by apps and customizations that seem innocuous at install time.

Third-party payment gateway apps are the first category to watch. If you are not using Shopify Payments and have installed a gateway app that renders its own card form on your storefront domain rather than redirecting to the gateway's hosted page or using a tokenizing iframe, that form is transmitting cardholder data through your merchant infrastructure. Depending on how the app is architected, this can push you from SAQ-A into SAQ-A-EP, which brings with it the full quarterly external vulnerability scanning requirement, web application controls, and a much longer questionnaire. Shopify-integrated gateways generally use iframe or redirect patterns to keep merchants in SAQ-A, but legacy integrations and some regional gateways do not, and it is worth verifying for your specific configuration.

The second category is custom storefronts. If you are running a Hydrogen or Storefront API headless build and the payment step is handled by redirecting to Shopify's checkout, scope is preserved. If, instead, you have built a custom checkout that calls payment APIs from your infrastructure, or that captures card fields before tokenizing, you have built a cardholder data environment and your SAQ changes accordingly.

The third category is subscription and recurring billing apps. Some historical subscription apps on Shopify ran their own checkout flow outside of Shopify's hosted checkout, and in those flows the app, not Shopify, was the processor of record for the card data. Newer versions of these apps have migrated to checkout extensions or native Shopify subscriptions, but merchants on older contracts sometimes do not realize they are on the legacy flow. If your subscription checkout looks different from your one-time checkout, that is worth asking about.

Shopify Plus and Checkout Extensibility

Shopify Plus merchants historically had access to checkout.liquid, which allowed direct template-level customization of the checkout page. This was powerful and it was also a PCI scope hazard, because any script or markup on the payment page that could interact with the card fields was effectively a script in scope under PCI DSS 4.0's new script requirements. Shopify has been migrating Plus merchants off checkout.liquid and onto Checkout Extensibility for some time now, with the Information and Shipping pages deprecated in August 2024 and the remaining Thank You and Order Status pages deprecated through 2025.

Checkout Extensibility is not just a developer experience change. It is a PCI architecture change. Extensions run in a sandboxed environment that does not have direct DOM access to the payment field. A Checkout UI extension cannot read or modify the primary account number field, which means extensions cannot be weaponized as skimmers even if the extension code itself were compromised. That is what keeps Plus merchants in SAQ-A scope even with customized checkouts.

If you are a Plus merchant still on checkout.liquid for any reason, you are in a different posture. You have custom code on the payment page, that code can in principle interact with the card fields, and under PCI DSS 4.0 you are carrying the script inventory and change detection obligations yourself for that code. Completing the migration is the single highest-leverage PCI action most Plus merchants have in front of them.

B2B checkout, wholesale checkout, and Shop Pay Installments all sit within Shopify's PCI scope. Shop Pay Installments and similar financing options are handled by regulated lenders who maintain their own PCI compliance, and the handoff between Shopify and those providers is structured to keep merchants out of scope for the financing flow.

The Third-Party App Scope Expansion Risk

Every app installed on a Shopify store gets reviewed by Shopify for its permissions, but permissions review is not a PCI scope review. An app that has permission to modify your theme, read your orders, or inject assets into your checkout can, depending on what it actually does, pull you into scope or create a script integrity obligation.

The practical question to ask about every app in your store is: does this app load any JavaScript on the checkout page, and if so, what does that script do? For apps built on Checkout Extensibility the answer is effectively that the scripts run in a sandbox and cannot interact with card fields. For apps that predate Extensibility and that inject scripts via the legacy mechanism, you own that script under PCI DSS 4.0 regardless of who authored it.

A defensible posture for most merchants is to maintain a short document listing every app that interacts with the checkout, the mechanism by which it does so (Checkout Extension, theme app extension, legacy checkout.liquid block, or script tag), and the date of last review. This document takes an hour to produce, lives alongside your SAQ-A, and is the single thing an assessor will ask for if the topic comes up.

What to Actually Do This Quarter

If you are on stock Shopify with Shopify Payments and no significant customization, your PCI work is real but bounded. Complete the SAQ-A for the current year. Confirm MFA is enforced on every admin and staff account. Pull Shopify's current AOC into your compliance folder. Inventory the apps that touch your checkout. Document a simple incident response runbook. You are done.

If you are on Shopify Plus, if you use a non-Shopify-Payments gateway, if you have custom checkout code, or if you run a headless storefront, the picture is more involved and it is worth an actual scoping exercise to determine which SAQ applies and what the script integrity obligations look like. Getting this wrong does not typically produce a fine the day you get it wrong, but it produces a painful conversation with an acquirer or an assessor in the aftermath of any incident, and in the worst case it produces personal liability for directors of companies that have attested to the wrong questionnaire.

WitsCode runs a PCI scoping consultation for Shopify and Shopify Plus merchants that maps your app inventory against PCI DSS 4.0 script requirements, confirms the correct SAQ for your architecture, and produces the documentation package your assessor will expect. If you are unsure whether your current setup is SAQ-A or something more involved, that is exactly the question the consultation answers.

The honest version of Shopify PCI compliance is that Shopify has done the hard part, which is building and maintaining a compliant Cardholder Data Environment at Level 1 scale, and that merchants still have a smaller but real set of responsibilities that PCI DSS 4.0 made slightly larger. Knowing which SAQ applies to your specific setup, keeping a defensible inventory of checkout scripts, and maintaining the baseline security hygiene that SAQ-A actually requires will keep you on the right side of the standard. Ignoring it because the marketing page implied there is nothing to do is how merchants end up surprised.