Do You Need PCI Compliance If You Use Stripe or Shopify?

Yes, and the processors say so themselves. Stripe's integration security guide states plainly that "PCI compliance is a shared responsibility and applies to both Stripe and your business," that Stripe "is certified annually by an independent PCI Qualified Security Assessor (QSA) as a PCI Level 1 Service Provider," and that "As a business accepting payments, you must do so in a PCI-compliant manner, and annually attest to this compliance." Their certification covers their systems. Yours covers yours. What a good integration buys you is a much smaller set of requirements, not zero, and Stripe puts a number on the difference: a business that "handles sensitive credit card data directly when accepting payments" may "be required to meet more than 300 security controls in PCI DSS," while a low-risk integration collects and transmits payment information directly to Stripe "without it passing through your servers, reducing your PCI obligations."

That is the entire answer, from the interested party. The rest is the part processors are less motivated to explain: how quietly you can lose the light integration, and what you still owe on your best day.

Key takeaways

• Yes, and the processors say so themselves. Stripe's own documentation calls PCI compliance a shared responsibility that applies to both Stripe and your business, and says you must attest annually.
• A good integration buys you a much smaller set of requirements, not zero. Four obligations stay yours: the annual attestation, everything around the payment page, transport security, and third-party management under Requirement 12.8.
• The failure we actually see is integration drift. A tag manager, a session-replay tool and a chat widget arrive one growth experiment at a time, and nobody makes a PCI decision.
• Card data appears where nobody designed it to: a support inbox, a phone refund workflow, a call recording, a chargeback spreadsheet, an error log that captured a form submission.
• Tokenization is real scope reduction, and it does nothing about those paths. A token in your database is irrelevant if an agent is pasting card numbers into a ticket.

What you still owe when the processor does the heavy lifting

Even on a fully outsourced checkout, four obligations remain yours.

An annual attestation. Whichever self-assessment questionnaire you are eligible for, someone at your company signs it, and the signature is a claim about your controls. Which questionnaire, and whether your acquirer requires it at all, is covered in which PCI SAQ do you need.

Everything around the payment page. Your site serves the page the payment form sits in. The scripts on it are yours. PCI DSS v4.x added Requirement 6.4.3 for managing payment page scripts and Requirement 11.6.1 for detecting unauthorized changes to payment page content, and both became mandatory on March 31, 2025. Our v4 future-dated requirements guide covers 11.6.1 alongside the rest of that deadline's requirements. Stripe's own guidance points the same direction: "Including JavaScript from other sites makes your security dependent on theirs and poses a security risk."

Transport security you control. Stripe's guide is specific: "Payment pages must use a recent version (TLS 1.2 or above)." Your certificate, your configuration, your responsibility.

Third-party management. Your processor is a third-party service provider, and PCI DSS Requirement 12.8 puts obligations on you as their customer: maintain the list, hold the written agreements, do the due diligence, monitor their compliance status at least annually, and know which requirements they manage and which are yours.

The trap: integration drift

Here is the failure we actually see, and it has nothing to do with the processor.

A company launches on a hosted checkout, correctly identifies itself as eligible for the lightest questionnaire, and attests. Eighteen months later the checkout has been customized. There is an A/B testing script on the payment page now, and a session-replay tool, and a chat widget, and a tag manager that a marketer can add scripts to without a deploy. Nobody made a PCI decision. Each addition was a growth experiment.

But the eligibility criteria for the lightest questionnaire turn on whether your site can affect the security of the payment transaction, and a tag manager on the payment page is a mechanism for third parties to run code on it. The Council maintains an FAQ on this specific question, numbered 1588 and titled "How does an e-commerce merchant meet the SAQ A eligibility criteria for scripts?", in its FAQ library. If your payment page has grown scripts since you last attested, that FAQ and the current questionnaire's eligibility section are what you should read before you sign the next one.

The practical control is unglamorous: make the payment page a protected surface. No tag manager. No marketing scripts. An allowlist enforced by content security policy, integrity attributes on what remains, and a review gate on changes. That is cheaper than moving to a heavier questionnaire, and it is the same work Requirement 6.4.3 asks for anyway.

Where the card data actually is, versus where you think it is

The second thing that moves companies into a heavier questionnaire has nothing to do with the website.

Ask where a primary account number could appear in your company. The honest list usually includes at least one of: a support inbox where a customer pasted a card number, a phone refund workflow where an agent types it somewhere, a call recording, a spreadsheet finance keeps for chargeback disputes, and an error log that captured a form submission before the redirect fired.

Every one of those is your systems storing or processing cardholder data. Any one of them can undo an architecture that was designed to keep card data out. Fixing them is mostly process and configuration rather than engineering, which makes it the cheapest PCI work available and the most commonly skipped.

Tokens, and what a token does not do for you

The other reassurance worth unpacking is tokenization, because it is genuinely powerful and routinely oversold.

When your processor returns a token in place of a card number, the primary account number stays in their vault and your database holds a reference. Stripe describes the adjacent case explicitly: the non-sensitive card information returned with a charge, such as the card type, the last four digits and the expiration date, "isn't subject to PCI compliance, so you can store any of these properties in your database." That is real scope reduction and it is the correct architecture.

Three limits are worth stating in the same breath.

First, a token is only as descoping as the boundary it sits behind. If your systems can exchange the token for a primary account number, or can initiate a transaction that reveals one, that capability is part of your environment and an assessor will ask about it.

Second, tokenization does nothing about the paths card data takes outside the checkout. A token in your database is irrelevant if a support agent is pasting card numbers into a ticket, and that is the more common problem by far.

Third, the token is your customer's identifier for a payment instrument, and it deserves the same access control and logging discipline as any other sensitive reference, even though it is not cardholder data. Treating it as public because it is not a PAN is how token-replay problems start.

Shopify, Square, and platform-specific claims

The pattern is the same across processors and the marketing is not.

A hosted platform that runs the checkout for you is doing genuine work, and it does remove a large amount of your obligation. What no processor can do is attest on your behalf, sign your questionnaire, or own the theme code, apps and scripts you install around their checkout. On an app-extensible platform, a third-party app with storefront script access is exactly the risk Requirement 6.4.3 exists for, and the app is your decision.

Read your platform's PCI page as what it is: an accurate description of their compliance, plus an inference about yours that they are not in a position to make. Where their documentation says what your obligations are, as Stripe's does, take it seriously. Where it implies you have none, check it against the questionnaire's eligibility criteria.

The honest caveat

If you take card-not-present payments through a fully hosted checkout, keep a clean payment page, hold no card data anywhere, and your acquirer has told you which questionnaire to file, you do not need a consultancy. You need an afternoon with the current questionnaire and a note in your calendar for next year.

Call someone when the picture changes: when you start storing anything, when a platform migration puts your code near the payment page, when you become a service provider by handling payments on someone else's behalf, or when an enterprise customer starts asking for an attestation of compliance rather than a checkbox.

Where Top Floor fits

Top Floor is not a QSA and cannot sign your Report on Compliance. Our PCI DSS work is scope and readiness: finding the card data paths nobody documented, arguing the environment smaller, hardening the payment page, and getting the evidence ready. Where the processor relationship itself is the question, our vendor risk management program guide covers how to assess and monitor a third party in general terms, though not the PCI-specific obligations in Requirement 12.8.

How to decide this week

Open your payment page in a browser and list every third-party script that loads on it. If you cannot produce that list in ten minutes, that is the finding.

Search your support inbox, ticket system and shared drives for card number patterns. What you find defines your real scope more accurately than any diagram.

Then confirm with your acquirer which validation type they expect, and check the current eligibility criteria against what you found in the first two steps rather than against what your architecture intended.

Frequently asked questions

Do I still need PCI compliance if Stripe handles the card data?

Yes. Stripe's own integration security guide states that PCI compliance is a shared responsibility that applies to both Stripe and your business, and that as a business accepting payments you must do so in a PCI-compliant manner and annually attest to this compliance. Stripe's Level 1 Service Provider certification covers Stripe's systems. Your validation covers yours. A well-chosen integration substantially reduces the number of requirements that apply to you, which is why Stripe contrasts handling card data directly, where more than 300 controls may apply, with a low-risk integration that reduces your obligations.

Does using a hosted checkout mean we automatically qualify for the lightest SAQ?

Not automatically, and not permanently. Eligibility turns on whether your own site can affect the security of the payment transaction, so the scripts on the page matter as much as where the form is hosted. The common failure is drift: a tag manager, a session-replay tool or an A/B testing script gets added to the payment page months after launch, and nobody re-checks the eligibility criteria. Read PCI SSC FAQ 1588 on how an e-commerce merchant meets the SAQ A eligibility criteria for scripts, and re-read the criteria before each annual attestation.

What are we responsible for if our processor is PCI compliant?

At minimum: your annual attestation, everything around the payment page including the scripts on it, transport security on your own pages, and third-party management under Requirement 12.8, which includes keeping the list of providers, holding written agreements, doing due diligence, monitoring their compliance status and knowing which requirements they cover versus which you do. If card data can also reach your support tooling, phone workflows, call recordings or finance spreadsheets, those systems are yours too, and they are where most unexpected scope comes from.

Can our payment processor's compliance certificate satisfy our customers?

It can answer a question about the processor, not about you. If an enterprise customer is asking for your attestation of compliance, forwarding your processor's certificate answers a different question than the one asked, and reviewers notice. If your product handles or can affect the security of cardholder data on someone else's behalf, you may be a service provider in your own right, which is a different validation path covered in our merchant versus service provider article.