Which SAQ is easiest?

SAQ P2PE for in-person merchants using a PCI-validated point-to-point encryption terminal. SAQ A (around 24 requirements under v4.0.1) for online merchants who fully redirect to a hosted payment page. Both can typically be completed in a single afternoon.

How many questions are on SAQ D?

Under PCI DSS v4.0.1, SAQ D-Merchant has roughly 251 requirements and SAQ D-Service Provider around 269 (down from 329 and 347 respectively in the retired v3.2.1, which counted many sub-requirements separately). They cover all 12 PCI DSS requirements in full. Most merchants who land on SAQ D could move to a simpler SAQ via tokenization or a hosted payment page.

Do I need SAQ A-EP for iframe payments?

Not necessarily, and this is the question most often answered with an out-of-date rule. Under PCI DSS v4.0.1, the SAQ A eligibility criteria explicitly contemplate an e-commerce merchant whose page includes a provider's embedded payment page or form, including one or more iframes, provided the merchant has confirmed the site is not susceptible to attacks from scripts that could affect its e-commerce systems (PCI SSC FAQ #1588). SAQ A-EP remains the questionnaire for partially outsourced e-commerce where your own site can affect the security of the payment transaction without receiving card data, the classic case being a direct-post integration where your page builds the card fields itself. The gap between the two is large, around 24 controls against around 139, so it is worth reading the eligibility criteria in the current SAQ A document against your actual integration rather than assuming.

SAQ guide

Which PCI SAQ do you need?

Q: Can I do SAQ A if I use Stripe?

Yes for a redirect to Stripe Checkout or Payment Links, and Stripe's published position is that SAQ A also applies to Stripe.js and Elements, because those "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" (stripe.com/guides/pci-compliance, checked July 2026). Under PCI DSS v4.0.1 there is a condition attached to the embedded case: SAQ A eligibility asks you to confirm your site is not susceptible to attacks from scripts that could affect your e-commerce systems. PCI SSC FAQ #1588 sets out the two ways to satisfy that, either by protecting the page yourself using the techniques in Requirements 6.4.3 and 11.6.1, or by obtaining confirmation from your PCI DSS compliant provider that its solution includes those protections when implemented to its instructions. Confirm your own integration against the eligibility criteria printed in the current SAQ A document rather than against a rule of thumb.

Nine SAQ types exist. Most merchants land on the wrong one and pay for hundreds of controls they should never have been in scope for. Use the wizard to narrow it down, then confirm with the comparison table below.

Updated July 2026

Which numbers on this page are which

Card brand rules, merchant levels and validation requirements are quoted from Visa's and Mastercard's own current rulebooks and are facts. No card brand, QSA, acquirer or pen test firm publishes a price list for PCI compliance work, and only one ASV publishes any price at all. So this site does not print cost bands for that work: a range for a price nobody discloses would be a guess, and labelling a guess an estimate does not make it true. What you get instead is what each line is priced against, so you can go and get a real number from the only people who have one, and a calculator that does the arithmetic using rates you supply from your own quotes. Where a real published price does exist, such as the compliance platform list prices on AWS Marketplace or SecurityMetrics' published small-business bundle, we quote it to the source and say when we checked it.

Step 1 of 3

How do you primarily accept card payments?

All nine SAQ types compared

SAQ	Who it is for	Controls	What that means	Difficulty
SAQ A	Card-not-present merchants using fully hosted payment pages (redirect)	~24	Lowest control count of any SAQ	Low
SAQ A-EP	E-commerce merchants with website that affects payment page security (iframe/JS)	~139	Roughly 6x the controls of SAQ A	Medium-High
SAQ B	Merchants using imprint machines or standalone dial-out terminals only	41	Low control count, no internet-facing scope	Low
SAQ B-IP	Merchants using standalone IP-connected POS terminals (no electronic card data storage)	82	Doubles SAQ B, because the terminal is on the network	Medium
SAQ C	Merchants with payment application systems connected to the internet	160	Approaching SAQ D territory	Medium
SAQ C-VT	Merchants manually entering single transactions via virtual terminal on isolated computer	79	Isolation of the terminal is what keeps the count down	Medium
SAQ D (Merchant)	All merchants not qualifying for any other SAQ type	~251	The full standard, all 12 requirements	High
SAQ D (Service Provider)	Service providers eligible to self-assess	~269	SAQ D plus the service-provider-only controls	High
SAQ P2PE	Merchants using validated P2PE hardware terminals only	33	The validated terminal removes most of the scope	Low

Control counts are approximate and come from the SAQ documents in the PCI SSC document library. PCI DSS v4.0.x consolidated many of the separate sub-requirements counted under the retired v3.2.1 into single controls, so exact totals vary by counting method and are lower than the older v3.2.1 figures. Confirm the current count in the relevant SAQ document.

There is no cost column, and that is deliberate. Nobody publishes a price for completing an SAQ: not the PCI SSC, not a QSA firm, not an acquirer. A range here would be our guess at a market rate that is not disclosed anywhere, and it would read to you as a fact. The control count is published, it is checkable, and it is what the work actually scales with, so it is the column to reason about. To turn it into money, ask two or three firms the same seven questions.

Easiest path

SAQ A: fully outsourced

Around 24 requirements under v4.0.1, the lowest count of any SAQ. For merchants who use a hosted payment page (Stripe Checkout, PayPal, Shopify Payments) where customers are redirected entirely off your domain. Card data never enters your servers, and the controls you are not answering are the ones that would have applied to it.

The condition to check: since v4.0.1, SAQ A eligibility asks you to confirm your site is not susceptible to attacks from scripts that could affect your e-commerce systems. PCI SSC FAQ #1588 gives two ways to satisfy it: protect the page yourself using the techniques in Requirements 6.4.3 and 11.6.1, or get confirmation from your provider that its solution carries those protections when implemented to its instructions. Get that confirmation in writing.

Hardest path

SAQ D: the catch-all

Roughly 251 requirements under PCI DSS v4.0.1. The default for any merchant who stores card data, processes payments through their own server-side code, or fits no other SAQ. Many SAQ D merchants could move to SAQ A or SAQ A-EP through tokenization or a hosted payment page, and that architecture change is worth more than any negotiation over the fee to complete it.

When to skip the SAQ entirely: if you are heading toward Level 1 or your acquirer is asking for evidence beyond an SAQ, a QSA-led ROC may be a more efficient route than a 250-plus-requirement self-attestation.

SAQ A or SAQ A-EP: the e-commerce fork

This is the fork worth getting right, because it is around 24 controls against around 139. The dividing line is whether card data is collected by the provider or by your own page. Under v4.0.1 an embedded provider form or iframe can sit on the SAQ A side, provided you meet the script-protection eligibility criterion. Confirm your integration against the criteria printed in the current SAQ A document, and get your provider's confirmation in writing.

SAQ A territory

Customer redirected to a processor-hosted page
Full-page redirect to Stripe Checkout, Payment Links, PayPal, Adyen Drop-in
A provider's embedded payment form or iframe serving the card fields from the provider's domain, where you have confirmed the script-protection eligibility criterion (PCI SSC FAQ #1588)

SAQ A-EP territory

Partially outsourced e-commerce where your own site can affect the security of the payment transaction but never receives card data
Direct-post integrations where your page builds the card fields itself
Any flow where the card input is rendered by your code rather than served from the provider's domain

Need an independent assessment?

Our partner network includes QSAs and ISAs across all merchant levels. Costs vary by scope and QSA fees are quoted independently. We do not endorse a specific firm.

Find a QSA in the PCI SSC directory →

Frequently asked

SAQ A has around 24 requirements under PCI DSS v4.0.1 (up from 22 in the retired v3.2.1) and is for merchants who fully outsource payment processing to a hosted payment page (like Stripe Checkout or PayPal). SAQ D is the comprehensive default for any merchant whose environment touches card data directly, with roughly 251 requirements for merchants (down from 329 in the retired v3.2.1, which consolidated many sub-requirements in v4.0). The honest way to size the gap is that control count: SAQ D asks about ten times as much of you as SAQ A. We cannot give you the gap in money, because nobody publishes a price for completing either one, and any figure you find for them traces back to somebody's estimate rather than to a published rate.

Stop the processor fee

Complete the right SAQ to remove it.

Move down the SAQ ladder

Tokenization, hosted pages, P2PE.

Cost by merchant level

How SAQ choice changes by level.