Published and sources checked: 2026-09-24. Scope: choosing a PCI DSS v4.0.1 Self-Assessment Questionnaire (SAQ) for an e-commerce checkout that uses a hosted, embedded or self-built payment page, in a merchant environment that stores no cardholder data electronically. This is public-document research, not an audit, a QSA opinion or an acquirer decision. Which questionnaire an entity may use, and what validation format its transactions require, is set by the card brands and the acquirer and must be confirmed with them.
Fix the standard version before you argue about the questionnaire
PCI DSS v4.0.1 is a limited revision of v4.0, published in June 2024. The PCI Security Standards Council (PCI SSC) describes it as containing "corrections to formatting and typographical errors" that clarifies "the focus and intent of some of the requirements and guidance", and states plainly: "There are no additional or deleted requirements in this revision."[2] A revision with no new requirements still changes the paperwork, because the SAQ documents, attestations and supporting guidance are versioned alongside it.
The version timeline decides which template you may complete. PCI SSC reports that "As of 31 March 2024, the PCI Security Standards Council (PCI SSC) officially retired PCI DSS v3.2.1", and that of the requirements introduced with v4.0, "Of the 64 new requirements, 51 are future-dated and will be effective as of 31 March 2025."[3] The bulletin on the v4.0.1 questionnaires adds that "The SAQs for PCI DSS v4.0 will remain active until PCI DSS v4.0 is retired on 31 December 2024."[1]
Practical reading: check the version string printed on the questionnaire and on the Attestation of Compliance you are about to sign, confirm it says v4.0.1, and confirm the assessment period you attest to is one in which the future-dated requirements already applied. A correctly answered questionnaire attached to a superseded version is a documentation problem, not a rounding error.
Eligibility is a claim you have to be able to support
An SAQ is not a menu you pick from by product name. The PCI SSC bulletin is explicit: "Merchants should confirm they meet all eligibility criteria for a particular SAQ before commencing their self-assessment."[1] Each criterion has to be true for your environment; the moment one is false, you are describing a different environment and the questionnaire changes with it.
Where the criteria live is also stated in the same bulletin: the SAQ Instructions and Guidelines document "contains information about all PCI DSS v4.0.1 SAQs, including guidance on the intent of the SAQs, eligibility criteria for the SAQs, and how to complete an SAQ."[1] Those documents, plus the SAQ itself, are the criteria. A blog post, a vendor wizard or this article is not. The bulletin also records what changed in this round of questionnaires, including "Clarifying SAQ Eligibility Criteria in SAQs A, A-EP, and C-VT", "Adding a requirement to SAQ A and removing a requirement from SAQ C" and "Updating SAQ Completion Guidance in SAQs A and A-EP".[1] Criteria copied out of an older questionnaire are therefore not a safe guide to what applies now.
The integration boundary: who serves the payment page
The published Stripe mapping is useful because it states the boundary as an outcome rather than a brand preference. For its hosted and embedded card fields it says: "Checkout and Stripe.js and Elements host all card data collection inputs within an iframe served from Stripe's domain (not yours), so your customers' card information never touches your servers", and lists the result as SAQ A. For a form hosted on the merchant's own page it says: "Using Stripe.js v2 to pass card data entered in a form hosted on your own site requires completing the SAQ A-EP annually to prove your business is PCI compliant." For server-side collection it says: "When you pass card information directly to Stripe's API, your integration is directly handling that data, and you're required to annually prove your PCI compliance using the SAQ D".[5]
Read those three rows as one question: which origin serves the elements the customer interacts with, and does your server ever see the number. Processing is a separate question from delivery. A provider can process every payment while your own site still assembles the form, injects the script or hosts the field, and that is exactly the difference the questionnaire is trying to detect.
The cost of crossing the line is described in Stripe's own integration guide rather than in percentages: "If your business handles sensitive credit card data directly when accepting payments, you might be required to meet more than 300 security controls in PCI DSS", while its low-risk integrations "securely collect and transmit payment information directly to Stripe without it passing through your servers, reducing your PCI obligations."[4] Treat that as one provider's description of its own integration patterns, not as the count of requirements that apply to you.
Write down what your checkout actually serves
Before anyone answers a questionnaire, produce a short inventory of the payment page that a browser really loads:
- Every script, iframe, form action and image URL on the page where card data is entered, with the serving origin for each.
- Whether your server ever receives the primary account number, or only a token or a non-sensitive subset.
- Which of your pages redirect to the provider, which embed provider content, and which build their own fields.
- The provider's status for the specific services you use, because the SAQ criteria ask you to have confirmed it.
- Any script your own team deploys to that page, including tag managers, A/B tools, analytics and support widgets.
This inventory is editorial practice, not a numbered requirement. Its value is that it turns each eligibility criterion into a question with an observable answer, and it makes drift visible: a page that changed last sprint is a page whose questionnaire answer may have changed too.
Use the vendor mapping as an input, not as the attestation
Vendors publish these tables to reduce support load, and they are a reasonable starting point. Stripe's page says "If you are unsure what SAQ type is right for you, the Stripe PCI wizard will automatically determine the type of documentation that is appropriate for your business", and separately states that "PCI compliance is a shared responsibility and applies to both Stripe and your business", with Stripe "certified annually by an independent PCI Qualified Security Assessor (QSA) as a PCI Level 1 Service Provider meeting all PCI requirements."[5][4]
What a vendor mapping cannot do is accept your questionnaire. The bulletin puts the next step in your hands: "All entities completing SAQs are encouraged to first contact the entity to which the SAQ will be submitted to confirm they are eligible to complete a SAQ to validate PCI DSS compliance, and to understand any specific requirements or instructions."[1] Your acquirer may carry instructions that no public table contains.
What this does not decide
This article does not tell you which SAQ is correct for your environment; only your assessment against the published criteria, confirmed with the receiving entity, does that. It does not reproduce the criteria text, and it does not summarise merchant levels or validation frequencies, which differ by brand programme and change over time. It does not cover card-present channels, service-provider scope, or regional scheme obligations that sit alongside PCI DSS. Nothing here is a compliance opinion.
Sources and limits
Checked 2026-09-24. PCI SSC sources carry their stated publication dates; the Stripe pages do not state publication dates, and retrieval is not publication. Standard and programme versions must be re-checked at the time of your own assessment.
- [1] PCI Security Standards Council Bulletin: SAQs for PCI DSS v4.0.1 Now Available — Published: 15 October 2024; checked: 2026-09-24.
- [2] Just Published: PCI DSS v4.0.1 — Published: 11 June 2024; checked: 2026-09-24.
- [3] Now is the Time for Organizations to Adopt the Future-Dated Requirements of PCI DSS v4.x — Published: 20 August 2024; checked: 2026-09-24.
- [4] Integration security guide | Stripe Documentation — Published: not stated; checked: 2026-09-24.
- [5] What is PCI DSS compliance? | Stripe — Published: not stated; checked: 2026-09-24.