Do You Need PCI Compliance with Stripe, PayPal or Square? Yes — Here's What

'I use Stripe, so PCI compliance is handled — right?' It is one of the most common assumptions in modern payments, and you will hear the same about PayPal and Square. It is also, unfortunately, only half true. These providers make compliance dramatically easier — for some businesses, almost effortless — but the obligation itself never transfers to them. This article explains what Stripe, PayPal and Square actually take off your plate, what remains yours, and how your integration choices decide how much paperwork you face.

Doesn't my payment provider handle PCI compliance for me?

The myth usually starts with genuine marketing. Stripe, PayPal and Square are all validated as PCI DSS Level 1 service providers — the most demanding level of certification in the industry — and they say so prominently. But that certification covers their systems: their servers, their checkout pages, their card readers. PCI DSS applies to every business that accepts card payments, however those payments are processed, and using a certified provider does not move that obligation. As our PCI compliance guide explains, the standard follows the business taking the payment, not just the technology behind it.

Put simply: their compliance is a prerequisite for yours, not a replacement for it. What actually changes is scope — how much of the standard you personally have to evidence.

The assumption matters because it fails quietly. Nothing warns you that an SAQ was due; the first sign is usually a fee on a statement, an awkward question from your bank or a platform you sell through, or — worst case — a dispute after an incident, when your compliance status suddenly becomes very relevant.

What do Stripe, PayPal and Square actually do for you?

A great deal, to be fair. Used the right way, these providers:

• Capture card details on their own hosted pages, iframes or hardware, so raw card numbers never touch your website or systems.
• Tokenise cards, letting you handle refunds and repeat billing without ever holding a real card number.
• Encrypt card data inside their own readers for in-person payments.
• Maintain their own PCI DSS Level 1 validation for all the infrastructure that does touch card data.
• Shrink the questionnaire you face from potentially hundreds of questions to, in the best case, a short SAQ A.

What none of them can do is absorb your responsibilities under the standard. You remain the merchant, and it is the merchant who attests to compliance — even when the provider makes that attestation very easy.

How does your integration change your SAQ?

For online payments, the way you plug the provider in is the single biggest factor in how much work compliance involves. The difference between questionnaire types is enormous — see our comparison of SAQ A and SAQ D — and the boundary lines sit exactly where your integration choices are made:

• Hosted checkout or full redirect (Stripe Checkout or Payment Links, PayPal's standard buttons, a Square Online store): customers enter card details on the provider's page. This is the smallest possible footprint and typically qualifies for SAQ A, the shortest questionnaire.
• Embedded fields or iframes on your own pages (such as Stripe Elements): commonly still SAQ A territory, but PCI DSS v4.0.1 tightened the eligibility rules — scripts on your page can interfere with a payment iframe, so you are expected to keep your site's code and content secure.
• A payment form your own code builds and submits to the provider's API: generally SAQ A-EP, which is several times longer than SAQ A.
• Card numbers passing through your own server before reaching the provider: SAQ D — the full questionnaire, at well over 200 questions.
• In-person payments on a provider's reader: card data is encrypted in the hardware, keeping your footprint small, though questions about devices, staff and day-to-day process still apply.

The practical lesson: if you are building or rebuilding a checkout, choosing the hosted or redirect option is usually the difference between an hour of compliance a year and a genuine project.

What does each provider actually expect from you?

The three take noticeably different tones, which is part of why the confusion persists. Stripe asks merchants to validate compliance annually and, for the simplest integrations, can pre-fill much of the paperwork based on how your account is set up — but you are still the one attesting. PayPal's user agreement requires you to comply with PCI DSS; with fully hosted buttons there is little for you to evidence, while card-field integrations follow the same SAQ logic as anywhere else. Square goes furthest, saying that payments taken entirely through Square hardware and software are covered without separate validation — genuinely helpful, but a promise that stretches only as far as Square itself.

Notice the pattern: every one of these arrangements quietly assumes all of your payments flow through that one provider. Real businesses are messier — a terminal here, a website there, the odd phone order — and each extra channel brings its own obligations.

So when would you still be charged PCI fees?

Stripe, PayPal and Square are not known for charging separate monthly PCI fees — it is one of their selling points. The fees appear when there is a traditional acquirer in the picture, and there very often is. A shop that takes Stripe payments online but runs a countertop terminal from a conventional provider holds a standard merchant account for that terminal — typically with a compliance programme fee (commonly £3–£10 a month) and, if no SAQ has ever been filed for it, a non-compliance fee (typically £5–£25 a month, sometimes more). The Stripe side being 'handled' does nothing for the terminal side.

A worked example: the shop that thought Stripe covered everything

An independent homeware shop sells online through Stripe Checkout and in-store through a countertop terminal from a traditional acquirer. Online, life genuinely is simple: hosted checkout, SAQ A, no separate PCI fee from Stripe. But nobody ever filed an SAQ for the terminal account, and the acquirer has been charging £19.95 a month in non-compliance fees for the past 18 months — £359.10 spent on nothing, hidden in the same statement as the transaction charges. Validating that account stops the charge and saves £239.40 a year going forward. Even done through a managed service at £100 + VAT (£120), the shop ends the year £119.40 better off — with both channels properly evidenced for the first time.

Key takeaways

• Stripe, PayPal and Square reduce your PCI scope — they do not remove your PCI obligation.
• Their Level 1 certification covers their systems, not your business.
• Hosted checkouts and redirects usually mean SAQ A; embedded fields, custom forms and APIs mean progressively more work.
• Each provider's 'we handle it' promise stretches only as far as payments taken through that provider.
• PCI fees usually come from a traditional merchant account running alongside — validate it and the penalty element stops.

If your sales are mostly or entirely online, our guide to PCI compliance for e-commerce digs deeper into hosted versus embedded setups. And if you would rather have the whole thing dealt with — every channel, the right SAQ, the filing and the renewal — our fully managed PCI compliance service does exactly that for £100 + VAT a year.