Which Parts of PCI Compliance Are Yours on Shopify

The email is usually four lines long. Your acquiring bank, a B2B customer's security team, or the insurer quoting your cyber policy asks you to send your Attestation of Compliance — or your SAQ, or, most often, your PCI certificate. You have read a hundred times that Shopify is PCI compliant, so for a moment the request looks like a filing error at their end.

It is not an error. Two different obligations wear the same phrase, and almost everything written about this topic collapses them into one. This page separates them, names which parts of the second one are actually yours depending on how cards reach your store, and says plainly where the official documentation stops and your acquiring bank starts.

The Quick Verdict

Find your setup in the first column. Everything after this table is the reasoning underneath it.

Two Things Called PCI Compliance Here

The clearest way to see the split is to notice who each statement is about. When Shopify writes that it is certified, the subject of the sentence is Shopify. When your acquirer writes to you, the subject is your business — its transaction volume, its channels, and the code it runs. Neither statement is evidence for the other, which is exactly why one arrives while the other is already true.

Shopify's own blog states the merchant half of this without hedging, and it is worth reading before anything else on the topic. It does not say the obligation is small, or handled, or inherited. It says it exists and that its shape depends on facts about your business.

What Shopify's Certification Actually Covers

Shopify is certified Level 1 PCI DSS compliant — the tier the card schemes reserve for the largest processors — and the same page states that all Shopify stores using the platform are automatically PCI compliant by default. Read as a claim about the platform, both sentences are accurate and useful.

The step that causes the confusion is the next one: reading them as a claim about the store owner. The certification means the environment your checkout runs in has been assessed. It does not mean your company has been assessed, and it is not a document with your name on it — a distinction that only becomes visible when somebody asks you for one.

The same boundary runs through every platform, not only this one. On a self-hosted stack the merchant owns far more of the environment, so the same question has a much larger answer — the operational split between the two models is covered in our Shopify versus WooCommerce comparison, and the migration guides carry the detail. Here the point is narrower: hosting changes the size of your obligation, never whether you have one.

Why Outsourcing the Processing Does Not Remove You

This is the sentence that settles the argument, and it comes from the body that writes the standard rather than from any vendor. It also explains why the answer to am I in scope is stable while the answer to what must I produce varies so much between two stores that look identical from the outside.

So the first gate — does this apply to me — has one answer for every store that takes cards, and you check it by asking whether cardholder data is stored, processed or transmitted anywhere in your business. Failing this gate is not possible; you are either taking cards or you are not. The second gate, which decides what you produce and to whom, is where merchants actually differ, and it is the subject of the rest of this page.

How a Card Reaches Your Store, and What Each Route Leaves You

Most stores run more than one of these at once, and that is the detail worth holding onto: your obligation is the union of your channels, not the lightest one among them. The table below is the summary; the subsections after it explain what the official pages do and do not say about each route. Where the checkout itself sits in the wider architecture of a store is covered in our guide to how a Shopify store works.

Compiled from Shopify Help Center, shopify.com/security, shopify.dev and PCI SSC documentation read on August 26, 2026. The fourth column states what those sources leave unaddressed, not what is untrue.

Shopify Payments and the Hosted Checkout

The mechanics are worth knowing because they are what the paperwork describes. The buyer enters the number on a checkout Shopify operates, the data is handled inside Shopify's environment, and your theme never sees it — the flow itself is broken down step by step in our Shopify Payments guide.

That architecture is precisely what makes the lightest questionnaire relevant to you, rather than what makes questionnaires irrelevant. PCI SSC's eligibility criterion for SAQ A asks that account data functions be entirely outsourced and that, for e-commerce channels, every element of the payment page delivered to the customer's browser originate only and directly from a compliant provider. The shape of a hosted checkout is the shape that criterion describes — which is a smaller form, not an absent one.

A Third-Party Gateway: What Changes and What Does Not

We checked this specifically, because it is the first thing merchants assume must change. The current third-party payment providers page we read on August 26, 2026 carries no sentence about PCI, PCI DSS or a change in the merchant's obligations. That is worth stating rather than glossing, because most third-party writing on this topic asserts a change in either direction with equal confidence.

What demonstrably does change is commercial: Shopify adds its third-party transaction fee when sales are routed outside Shopify Payments, and the arithmetic of that is the subject of our guide to the third-party gateway surcharge. For the paperwork, the question to answer is the same one as before: whose page renders the field the customer types into.

When Your Own Front End Renders the Payment Field

Start with what is not affected, because the two get confused. Shopify states that checkout UI extensions run in an isolated sandbox, separate from the checkout page and other extensions, and that they do not have access to sensitive payment information or to the checkout page itself. Customizing the checkout through the supported extension model therefore leaves the payment field where it was.

A headless build is a different matter, and the difference is not about how modern the stack is. If the customer types the number into something your team ships, then the criterion PCI SSC publishes for SAQ A — every element of the payment page originating only and directly from a compliant provider — is no longer a description of your site. That is a question to put to your acquirer before you sign anything, not one to answer by analogy with a store that runs the standard checkout.

Cards in Person: What Shopify POS Leaves You

The in-person channel is where Shopify's documentation is most direct about the merchant's side, and the sentence below is the clearest statement of it anywhere in the Help Center. Note what it assumes: that you have an incident response process, and that PCI DSS is a live obligation of yours rather than a property of the platform.

The same page states that you are responsible for maintaining the POS card reader device inventory in the store administration interface. Hardware carries its own rhythm too: POS Go automatically reboots every 24 hours, and Shopify names meeting PCI requirements as the reason. That page also opens by stating that POS Go is no longer available for sale; the reboot line still sits on it, and it shows how a PCI duty can live in the device rather than in the paperwork. The wider retail setup — hardware choices, staffing, in-person fees — belongs to our Shopify POS guide.

One gap is worth naming rather than filling. No help.shopify.com page we read on August 26, 2026 uses the phrase PCI PTS, or describes the readers as a validated payment application. Third-party blogs state both freely. If your acquirer asks specifically about the reader's approval status, that is a question for Shopify support or the acquirer, not something to answer from a marketing page.

Bank Transfer, Invoice and Cash on Delivery

Manual payment methods move no card number at all, and PCI SSC scopes the standard to entities that store, process or transmit cardholder data — so nothing in that channel puts cardholder data in your hands. What it does not do is take your store out of scope if any of your channels still take cards; a manual channel narrows the picture, it does not empty it.

Which Document Are They Actually Asking You For?

This is the second gate, and unlike the first one it has different answers for different merchants. You check it by asking two questions about your own business — what volume band you are in, and which form your acquirer accepts — and the consequence of failing it is a request that keeps coming back until the right document arrives.

The definitions above come from the PCI SSC glossary, which is the reason they are worth quoting rather than paraphrasing: when a request and a reply use the same word for two different documents, nobody notices until the second round of email.

Who Signs an Attestation

PCI SSC describes two signature sections on the attestation that accompanies a Report on Compliance: Part 3b for the merchant or service provider executive officer, and Part 3c for the duly authorized officer of the QSA company. On the self-assessment route there is no assessor to sign, which makes the point bluntly — the signature on your attestation is yours.

Which Merchant Level Are You?

Visa counts the aggregate number of its transactions from a merchant, including credit, debit and prepaid, over twelve months. Two details in the table below routinely surprise people: levels 1 and 2 count all channels while level 3 is defined on ecommerce transactions, and a merchant that suffered an account data compromise may be escalated to a higher validation level regardless of volume.

One naming collision is worth clearing up before you read the rows. This is the merchant ladder, and it is not the ladder Shopify's Level 1 sits on — the standard treats merchants and service providers as separate categories, which is why PCI SSC reserves one questionnaire for service providers and states every other one is for merchant use only. A small merchant on a Level 1 platform is not a contradiction — the two uses of the word are counting different things.

Source: Visa — PCI DSS compliance validation, read August 26, 2026. Thresholds are Visa's own and count Visa transactions; other card schemes publish their own programs. This ladder is the one Visa's Latin America and Caribbean surface publishes; the paragraph below sets out what its corporate surface publishes instead.

One thing to check before you use the table: Visa publishes this ladder on its Latin America and Caribbean page, and a different one on its corporate page. The corporate page (visa.com/cisp) lists three levels and carries no 20,000 line at all — level 2 is defined there as 1 to 6 million Visa transactions annually across all channels, level 3 as less than 1 million Visa ecommerce transactions annually across all channels, and both of those bands list the questionnaire without a hedge: Every year: Complete and submit Self-Assessment Questionnaire (SAQ). Both pages were live when we read them. So the band you land in — and whether the annual questionnaire reads as a requirement or as a recommendation — depends on which Visa surface you open, which is one more reason the acquirer, and not a published table, is the party that settles what you file.

Shopify's own blog describes the Caribbean ladder from the merchant's side and adds a line worth quoting precisely, because it is the sentence that catches most store owners by surprise: level 3, it says, applies to all businesses and organizations processing 20,000 to one million card transactions per year, and all ecommerce merchants. On the same page, levels 2, 3 and 4 each name an annual self-assessment questionnaire.

If your volume puts you at the top of that ladder, the conversation stops being about forms and becomes an enterprise security review, where the platform's own reports do most of the work — the shape of those reviews is covered in our Shopify enterprise guide.

Which SAQ Applies to a Shopify Store?

This is the most valuable gap on the page, so it is stated rather than filled. Across the compliance reports page, the security page and the PCI blog post, read on August 26, 2026, no Shopify page we read names the SAQ a standard Shopify merchant should complete. The surfaces we checked are listed under What we looked for and did not find near the end of this page.

PCI SSC does say more than the criteria, and what it adds points the same way as the rest of this page. In its answer about merchants who outsource payment processing, it states that merchants are still required to validate PCI DSS compliance, typically through a Self-Assessment Questionnaire such as SAQ A, and that merchants should confirm their compliance obligations with the organization that manages their compliance program — their acquirer or payment brand. Read that as the standards body naming the typical instrument and the deciding party, not as an assignment of a form to your store.

What it publishes form by form is the criterion for each one. The table below carries the ones stated verbatim in its own guidance; the full set of questionnaires in version 4 is larger, and the post linked underneath enumerates them all. Read these as descriptions of channels, not as a menu to choose from.

Source: PCI SSC — what is new with self-assessment questionnaires in PCI DSS v4, read August 26, 2026. Forms whose criteria that post does not state verbatim are deliberately left out of this table rather than summarized from memory.

Where Shopify's Own Proof Lives

You reach them from Shopify's Compliance Reports page at shopify.com/legal/compliance/reports, which states that some reports are accessible only with an active Shopify account. Shopify's Help Center page listing the six documents puts it plainly: you have to log on to your Shopify account to view that report. One of the six — the SOC 3 report — the Compliance Reports page describes as publicly accessible, which makes it the easiest thing to send when a request is informal.

Read the wording of the attestation's description carefully, because it is doing precise work: Shopify calls the file its service provider PCI DSS AOC and the best evidence of the PCI DSS compliance of Shopify's services. Services, not stores. It is the right document to send about the platform and the wrong one to send about your company, and sending only this one is how a request comes back a week later.

Quarterly Scans: Whose Bill Is That?

Shopify's Compliance Reports page states that Shopify completes ASV scans quarterly, and the attestation covering them sits beside the PCI AoC. That answers the platform side. On your own side the form answers before the band does: SAQ A under version 4 carries requirement 11.3.2 — external vulnerability scans at least once every three months, by a PCI SSC Approved Scanning Vendor — and PCI SSC states that this holds for merchant ecommerce webpages even where payment processing is fully outsourced to a third party. What the band adds is what Visa lists beside it: on the Visa page in the table above, levels 1 to 3 list quarterly ASV scans, and level 4 lists a quarterly network scan by an ASV if applicable, with compliance validation requirements set by the acquirer.

On who pays, the ASV Program Guide — reference 1.0, dated March 2010 and written against PCI DSS v1.2, which PCI SSC still publishes — is explicit: the scan customer either pays all fees directly to the vendor, or pays them to the acquirer or another aggregating entity holding a contract on behalf of a group of merchants. The program defines the scan customer as the merchant or service provider undergoing the scan — the bill follows the entity being scanned. It predates version 4, where the scanning requirement is numbered 11.3.2; what it settles here is the fee, not the requirement number.

What Changes the Answer: Scripts on the Payment Path

This is where the topic turns from paperwork into something operational, and it is already overdue rather than approaching. A QSA-firm executive, interviewed on PCI SSC's blog, puts the scale of it this way: of the 64 new requirements in version 4, 51 were future-dated and effective as of March 31, 2025. Version 4.0.1, a limited revision published in June 2024, did not move that date: PCI SSC states that the limited revision does not impact the effective date of these new requirements.

The requirement's own text is the reason it matters to a store that never writes payment code: its scope is not limited to scripts you wrote or even to scripts you installed knowingly. An agency tag added two years ago is in scope, and so is whatever that tag loads.

What Requirement 6.4.3 Asks For

Stated in the standard's own terms, the three duties are:

• Authorization — a method is implemented to confirm that each script is authorized. In practice this means somebody decided it belongs there, and that decision can be shown.
• Integrity — a method is implemented to assure the integrity of each script, so a change made elsewhere does not pass unnoticed on the page that leads to payment.
• Inventory — an inventory of all scripts is maintained, with written justification as to why each one is necessary.

For SAQ A specifically, PCI SSC narrows where the requirement lands: it applies to the pages on the merchant's website that provide the address of the provider's payment page or form to the customer. That is a smaller surface than the whole storefront, and it is still a surface most stores have never inventoried.

When 11.6.1 Applies, and When It Is Not Applicable

The distinction the standard draws is between an embedded provider form and a plain redirect. Where the payment form is embedded, the page delivered to the browser is a surface worth watching for tampering. Where the merchant's page merely hands over an address and the customer leaves, PCI SSC itself directs the merchant to mark the requirement Not Applicable and document the reasoning in the appendix.

This matters more than it looks, because it is a rare case where the standard tells you what not to build. Reading it the other way — assuming every merchant needs tamper detection — produces a project nobody asked for.

What Adding a Pixel Does and Does Not Do

The claim that a marketing pixel escalates your SAQ type circulates widely, and we went looking for an official source for it: the web pixels documentation, the pixels overview in the Help Center, PCI SSC's own material on 6.4.3, and the SAQ A document itself. None of the pages we read on August 26, 2026 states that a pixel or an app changes the form — again, the surfaces are listed in the boundary block near the end of this page. What the SAQ A document does say on the point is an eligibility criterion about the payment page itself: for e-commerce channels, all elements of the payment page or form delivered to the customer's browser must originate only and directly from a PCI DSS compliant provider.

What the same search turned up is more useful than the escalation story. Because 6.4.3 reaches third and fourth-party scripts and appears in SAQ A itself, the pixel lands as a set of duties inside your existing form rather than as a promotion to a harder one. The practical consequence is an inventory line and a justification, not a different questionnaire.

The One Script Class You Do Not Validate

PCI SSC states that validation to 6.4.3 is not required for 3DS scripts, citing the inherent trust relationship between the 3DS service provider and the merchant established through due diligence, onboarding and the business agreement. The boundary is narrow and stated in the same answer: any script operating outside 3DS functionality remains subject to the requirement.

Which Route Is Yours?

The table at the top of this page answers by setup. This answers by combination — what actually happens to a card number across your whole business, crossed with your volume and with who is asking you for a document. Five questions, and no route here is a worse route than another; they are simply different obligations.

What to Send When Someone Asks

A note on order and weight before you start. Steps one and two are the same for every route, but step three is the one that decides all the others, so it is worth opening that conversation on day one rather than after you have prepared a document nobody asked for. If something you added sits on the payment path, step five is the longest item on the list by a wide margin — and it is also the only one with a deadline already behind it.

Where the Cost of Answering "Shopify Handles That" Is Written

Start with what is documented, because it points somewhere. Visa states that any merchant that has suffered a hack resulting in an account data compromise may be escalated to a higher validation level. And in the level 4 row of its Latin America and Caribbean compliance validation page, Visa lists the annual SAQ as recommended and ends the row with compliance validation requirements set by acquirer — the card scheme's own phrasing for who decides.

The consequence itself is published too, though not where most readers look for it and not in the shape they expect. Mastercard's Security Rules and Procedures — Merchant Edition of 4 August 2026 states that noncompliance with the SDP Program mandate on or after the required implementation date may result in an assessment: up to USD 25,000 for a first violation by a level 1 or level 2 merchant, up to USD 10,000 for a level 3 merchant, and noncompliance may also result in merchant termination. The same manual states that each level 3 merchant must successfully complete an annual SAQ although validation of compliance to Mastercard is not required of it, and that validation to Mastercard is not required for a level 4 merchant except as required by applicable law or regulation. Mastercard states it has the right to audit Customer compliance with the SDP Program requirements. We read that manual on August 27, 2026; the PDF mirrors refuse a direct request, so it was taken through a text-rendering proxy.

Visa publishes a consequence of a different shape, and it lands next door as well: if a service provider or merchant does not comply with the PCI DSS or fails to rectify a security issue, Visa may assess a non-compliance assessment to the issuer or acquirer, and that party is responsible for paying all assessments and must not represent that Visa has imposed any assessment on the merchant. Visa names a payer for its assessment; Mastercard's schedule names none — which is why the number that describes your account is in your merchant agreement rather than in a scheme's table.

The practical move is therefore not to estimate a risk but to remove the ambiguity: ask your acquirer what it expects and by when, in writing. Answering a documentation request with Shopify handles that is not dangerous because of a figure you can look up — Visa's assessment is paid by your acquirer, and Mastercard's schedule is written for its own program. It is dangerous because it answers a question about your business with a fact about somebody else's, and the request simply comes back.

When the Honest Answer Is "Ask Your Acquirer"

A page like this one earns its keep by being clear about where the documentation stops. Shopify publishes what Shopify is responsible for, thoroughly. PCI SSC publishes the standard and the eligibility criteria for each form, and for merchants who outsource their payment processing it goes one step further: they are still required to validate PCI DSS compliance, typically through a Self-Assessment Questionnaire such as SAQ A, and they should confirm their obligations with the organizations that manage their compliance program — the acquirer or payment brand, which PCI SSC also calls compliance-accepting entities. No Shopify page we read on August 26, 2026 names a questionnaire type for its merchants, and no source we read assigns a form to a specific merchant. That is not an omission, it is the design: the acquiring bank owns the relationship and therefore owns the determination.

The scan question is different in kind. PCI SSC states that SAQ A for PCI DSS v4.x includes requirements for external vulnerability scanning by a PCI SSC Approved Scanning Vendor for merchant e-commerce webpages, even where payment processing is fully outsourced to a third party. What PCI SSC does not settle is the deadline your acquirer sets for it. Who pays is not an open question either: the ASV Program Guide puts the fee on the entity being scanned.

So when a B2B customer's security team asks for a compliance package, the complete answer has two parts and one referral: the platform evidence from Shopify's Compliance Reports page, your own attestation on the form your acquirer accepts, and — for anything about your account's specific obligations — the acquirer itself. What such a security review looks like from the buyer's side is covered in our guide to enterprise security questions in B2B.

The Bottom Line

Almost every confusing sentence written about PCI on Shopify comes from one substitution: a fact about the platform standing in for a fact about the merchant. Once you separate them, the topic becomes unusually tractable — one gate that everybody passes the same way, and one gate whose answer depends on three things you can establish in an afternoon.

Frequently Asked Questions