PCI DSS v4.0.1
The question everything else hangs on, in plain words. It decides how much of the standard applies to you, and most shop owners have never been told which they are.
Last reviewed against PCI DSS v4.0.1 in September 2026.
We are not a qualified assessor and this page is not advice. It exists so you can arrive at the conversation with your acquiring bank knowing what to ask. It will not tell you which questionnaire applies.
Not your size, your turnover or your store software. It turns on how much control your website has over the page where the customer types their card number.
If your site plays no part in capturing card details — the customer leaves for the gateway entirely — you are at the light end. If your site serves the page the card fields live on, even when the fields themselves are in an embedded frame you do not own, you are at the heavier end, because a script on your page could tamper with them.
A starting position, not a determination.
| How your checkout works | Card fields are served by | Usually |
|---|---|---|
| Customer is sent to the gateway's own website, comes back after paying | The gateway, on its own domain | SAQ A |
| Shopify hosted checkout | Shopify | SAQ A |
| Gateway iframe embedded in your own checkout page | The gateway, inside a page you serve | often SAQ A-EP |
| Stripe Elements or Braintree hosted fields on your page | The gateway, inside a page you serve | often SAQ A-EP |
| WooCommerce checkout with the gateway's fields inline | Your own site | SAQ A-EP or heavier |
| Your server receives the card number at any point | You | SAQ D — much larger |
"Usually" is doing real work in that table. Two shops with identical setups can be told different things by different acquirers, and the criteria were revised in v4.0.1. Treat this as a starting position, not an answer.
Using a well-known gateway says nothing on its own. Stripe Checkout as a redirect and Stripe Elements embedded in your page are different answers. It is where the fields are rendered that matters, not whose logo is on them.
A script on the parent page can replace the frame, overlay it, or read what is typed before it reaches it. That is precisely how most skimming works, and it is why the embedded case is treated more heavily than the redirect.
Your acquiring bank decides which questionnaire they will accept from you. A developer opinion is not a determination and will not help if you are asked for evidence.
Version 4 changed what is required, including the script inventory and change detection that came into force in March 2025. An answer from before then is out of date.
Three sentences. Send them by email so you have the answer in writing.
Which self-assessment questionnaire do you expect from us for the coming year? Our checkout is at [address] and the card fields are [rendered on our own page / in an embedded frame / on your domain after a redirect]. Do requirements 6.4.3 and 11.6.1 apply to us, and what evidence will you want to see?
That last sentence is the one that saves you time. Some acquirers ask for the evidence annually, some on request, some not at all until something goes wrong.
You need a list of every script on your payment pages with a reason each one is there, and something that notices when one changes. Both are dull to keep by hand and impossible to reconstruct after the fact.
The approved list itself. In plain words.
Spotting a change. In plain words.
How payment-page script monitoring produces that evidence.
Tagnovo is not a QSA and does not certify compliance. If your checkout is hosted by your store software we will say so rather than guess.