Do I need PCI compliance if I use Stripe?

The email usually comes from the bank, not from Stripe. Something about your annual PCI DSS validation, a portal login you have never used, and a line saying charges may apply. Or it is a notice in the Stripe Dashboard asking you to complete a questionnaire. Either way the next question is the same one. We never see card numbers. Stripe does all that. So why is this our problem?

Short answer: you still need to be PCI compliant, and for most small shops on a hosted checkout it is a questionnaire rather than an audit. The longer answer is where people come unstuck, because that questionnaire covers your website as well as the payment page, and part of it changed in 2025.

Who is actually asking

PCI DSS is written by the PCI Security Standards Council, which American Express, Discover, JCB, Mastercard and Visa founded in 2006. The Council doesn't enforce it. Its own announcement of the 2025 SAQ A changes says it sets no compliance requirements for anyone, and that the card brands, acquirers and payment facilitators do. An acquirer is the bank that gives you a merchant account. A payment facilitator is a company like Stripe that lets you take cards without one.

So it isn't UK law. It's a term in your contract, and whoever holds that contract is the one who asks.

If you're on Stripe, Stripe asks. Its integration security guide calls PCI compliance a shared responsibility. Stripe itself is certified every year by an independent Qualified Security Assessor as a Level 1 service provider. You, as the business taking payments, have to accept them in a compliant way and attest to it annually. What Stripe wants from you, and by when, is listed in the compliance documents section of the Dashboard.

If you have a merchant account with a bank, the bank asks, and it can attach a price to not answering. Barclaycard's own pages are a good example. New merchants are enrolled automatically in a self-service tool at £4.80 a month plus VAT per attestation and get 90 days to complete the self-assessment. Miss that and a managed service switches on by itself, at £15 a month plus VAT per outlet. Other acquirers run their own versions. Read your merchant agreement rather than guessing.

That is money leaving the business every month whether or not anybody is ever breached.

Three ways a card number reaches the payment company

Everything else follows from one question. Whose page does the customer type the card number into?

The first way is a redirect. The customer presses Pay and leaves your site for a page the payment company hosts, then comes back when it's done. Stripe's hosted Checkout page works like this, and so do payment links sent by email.

The second is an embedded form. The card fields sit on your checkout page, but they are an iframe served from the payment company's own domain, so your site never handles the digits. Stripe Elements is this.

The third is your own form. Your page collects the card number and passes it on, either through JavaScript you host or by your server calling the payment API.

Stripe's guide to PCI DSS maps these to the questionnaires. Checkout or Elements: SAQ A, the shortest. The older Stripe.js v2, where you host the form: SAQ A-EP. Sending card data directly to the API: SAQ D, which Stripe describes as the most demanding of them. The integration guide adds that handling card data yourself can mean meeting more than 300 security controls, with dedicated security software and outside auditors to match.

No five-person business should be on route three. If a developer built you a card form that posts to your own server, fix that before you worry about any questionnaire. The Council's own guide for small merchants says much the same thing: in most cases, handing payment capture wholly to a PCI DSS validated third party is the safest option.

Why your website is in scope when it never sees a card

This is the bit that surprises people. The SAQ A the Council published in April 2022 for PCI DSS v4.0 spells it out in its own notes. For an e-commerce merchant, the requirements that talk about the cardholder data environment apply to the website that gives the customer the address of the payment page. The reason it gives is plain: your site affects how the card data is transmitted, even though it never receives any. The requirements about protecting computer systems apply to the web server that holds the redirect.

Look at it from the attacker's side. They don't need your database if they can change your Pay button. One edited line in an out-of-date plugin, and customers are sent to a lookalike payment page on somebody else's domain. They type their card details in, get an error, go back and pay again on the real page. Nothing on your side looks broken.

So "Stripe handles the card data" is true, and it isn't the whole answer. Your website is the part an attacker can edit, and it's the part the questionnaire asks about. If that sounds familiar, the hacked website article covers what the clean-up looks like when it has already happened.

What SAQ A asks of a small online shop

The April 2022 SAQ A runs to 40 pages, and most of that is instructions and attestation forms. The requirements that land on a small shop's website are few. Read through, they're the things any decent website care should be doing anyway:

• 2.2.2: vendor default accounts on the web server either get their password changed or get disabled. The "admin" account a platform created on install counts.
• 6.3.3: critical and high-severity security patches go on within one month of release.
• 8.3.6: passwords are at least 12 characters and mix letters with numbers. It was a best practice until 31 March 2025 and has been required since.
• 11.3.2: an external vulnerability scan at least once every three months, by an Approved Scanning Vendor, with a passing result. Under 11.3.2.1, a rescan after any significant change, fixing anything scored 4.0 or higher on CVSS.
• 12.8: a list of your payment and hosting providers, written agreements with them, and a check that they are compliant, which in practice means reading their Attestation of Compliance.

The scan is the one people have never heard of. The Council's FAQ 1604 removes any doubt: SAQ A merchants need ASV scans "even where payment processing is fully outsourced", and that includes sites that redirect and sites that embed the provider's iframe. An ASV is a company on the Council's approved list. A free scan from your web host, or from us, is not an ASV scan unless the company doing it is on that list. We aren't.

The patching line is worth a second look too. One month for critical and high patches is a real deadline, and on a WordPress or WooCommerce shop it covers plugins as well as the core. Our patch management article explains why "automatic updates are on" rarely means everything is up to date.

The 2025 change to scripts on the checkout page

PCI DSS v4.0 brought in two requirements aimed at e-skimming, where malicious JavaScript on a payment page copies card numbers as customers type them. Requirement 6.4.3 is about managing every script on the payment page: each one authorised, integrity-checked and justified. Requirement 11.6.1 is about detecting unauthorised changes to the page and to the HTTP headers that protect it. Both became mandatory on 31 March 2025.

The Council doesn't treat this as theoretical. Its payment page security supplement says e-skimming attacks have increased significantly, and that scripts running in the customer's browser are now a significant target.

Merchants told the Council the two requirements were too complicated, and it listened. In January 2025 it took 6.4.3, 11.6.1 and the related targeted risk analysis in 12.3.1 out of SAQ A. It added a new eligibility criterion in their place. To use SAQ A you now confirm that your site is not susceptible to attacks from scripts that could affect your e-commerce system. The October 2024 version of SAQ A was retired on 31 March 2025, the day the new one took effect.

What that sentence means for you depends on your route, and the Council's FAQ 1588 sets it out. If you redirect, by an HTTP 30x redirect, a meta tag or a JavaScript redirect, or you send customers a payment link by email, the criterion doesn't apply to you at all. If you embed the provider's form in an iframe, it does, and you meet it one of two ways. Either you put script controls in place like those in 6.4.3 and 11.6.1, yourself or through a third party. Or you get confirmation from your payment provider that its solution, set up the way its instructions say, protects your payment page from script attacks.

The second route is the realistic one for a small shop. Notice the condition, though: set up the way the instructions say. Stripe's own guide says that including JavaScript from other sites makes your security dependent on theirs, and recommends keeping it to a minimum. A checkout page carrying a chat widget, two analytics tags and a marketing pixel is not what the provider's confirmation was written about.

One more line from the Council's announcement matters. Taking the requirements out of SAQ A doesn't remove or diminish them in PCI DSS. It changes how a small merchant reports, not what an attacker can do.

Which checkout to choose

For a small shop, a redirect to the payment company's hosted page is the easiest one to defend. It keeps you on SAQ A, takes the script question off your plate entirely, and leaves you with the website basics and the quarterly scan. The price is cosmetic. Customers see a different page for thirty seconds, with your logo on it if you've set that up.

An embedded form looks tidier and keeps people on your page. With Stripe Elements it's still SAQ A by Stripe's reckoning, but it brings the script criterion along, and the checkout page has to stay clear of stray third-party code for as long as the shop runs. That's fine if someone is watching the page. It isn't if the marketing agency can add tags to it without asking anybody.

A card form you host yourself is the one to walk away from.

Whoever builds your shop, us included, should be able to tell you which of the three it is before you pay a deposit. If they can't answer, that is the answer. The same goes for who holds the Stripe account and the domain it's attached to, which is the subject of who owns your business website.

Two smaller points from Stripe's guide apply to every route. Payment pages must use TLS 1.2 or above, and so must everything the page loads, or browsers start showing mixed-content warnings. And if your site receives webhooks from Stripe, it should check their signatures, so that nobody else can tell your shop an order has been paid.

What we do, and what we don't

We aren't a Qualified Security Assessor and we aren't an Approved Scanning Vendor. We don't fill in or sign your SAQ. It's your attestation to your acquirer or payment provider, and only the business can make it.

What we do is build the shop on a low-risk checkout and keep the website side of the questionnaire in a state you can answer honestly. Our Complete Digital package is £900 plus VAT for up to ten pages, with basic e-commerce, payment gateway integration and a performance and security pack. Care after launch is £84 a month for the first year, because the £15 hosting portion is free in year one, and £99 a month after that. It covers UK hosting, SSL, daily backups kept for 30 days, uptime monitoring and security updates, plus forty-five minutes of changes a month, e-commerce monitoring and a quarterly performance and SEO check. All web prices are plus VAT, and care runs month to month on thirty days' notice.

To be clear about what that isn't: the e-commerce monitoring on the care plan is not the payment-page change detection in requirement 11.6.1, and we don't sell it as PCI validation. Nothing on our price list is.

Already have a shop somebody else built? Working out which route it uses, what loads on the checkout page, and whether the admin accounts and patching would stand up to SAQ A is hourly work. That's £126 an hour without an agreement, £86 an hour on a managed plan, and £167 an hour out of hours with a two-hour minimum. Ask for an estimate first. For a small shop on a hosted checkout it isn't a long job.

Checking where you stand this week

Start with the payment provider, not the developer. On Stripe, the compliance documents section of the Dashboard shows what's being asked of you. With a bank merchant account, find the portal login in the welcome pack and check whether a 90-day clock has already run out and a monthly charge has started.

Then find out your route, which takes a minute. Go to your own shop, put something in the basket and press Pay. If the address bar changes to the payment company's domain, you're on a redirect. If it doesn't, the card fields should be a frame loaded from the payment company's domain, which your browser's developer tools will show. If they're neither, you have the problem from the third route, and that comes first.

After that, count what else loads on the checkout page, in the same developer tools, and ask who put each script there. Then log in to the shop's admin and look at the accounts. An admin account left over from the install, still on a nine-character password, fails two lines of SAQ A on its own, and a password manager is the cheapest fix available.

Leave the ASV scan till last if you like, but don't leave it out. SAQ A expects a passing scan every three months. In your first year the Council only needs the most recent scan to have passed, as long as you have a documented quarterly schedule and have fixed what the scans found, so starting late is allowed. Starting never isn't.