PCI DSS 4.0.1 and SAQ A for hosted checkout merchants

Most cross-border merchants never see a card number. The customer types it into a payment page or an embedded form run by a provider, and the merchant gets back a token and a status. That design was chosen partly to keep PCI DSS work small, and it does. It does not make it disappear, and the rules for the smallest questionnaire, SAQ A, changed twice in the move to PCI DSS 4.0.1.

This article explains what SAQ A covers, who qualifies with a redirect or an iframe checkout, what the January 2025 revision changed, how SAQ A compares with SAQ A-EP and SAQ D, and what the merchant still has to do every year. For the integration choice itself, see our comparison of hosted checkout and direct API integration; for saved cards, see network tokens vs PSP tokens.

What is SAQ A, and who can use it?

SAQ A is the PCI DSS self-assessment questionnaire for merchants whose account data functions are completely outsourced to PCI DSS validated and compliant third parties. The current form is SAQ A for PCI DSS v4.0.1, Revision 1, published by the PCI Security Standards Council (PCI SSC) in January 2025. It applies only to card-not-present merchants, e-commerce or mail and telephone order, and it is not for face-to-face channels or for service providers.

To use it, the merchant confirms that:

• it accepts only card-not-present transactions;
• all processing of account data is outsourced to a PCI DSS compliant third-party service provider (TPSP) or payment processor;
• it does not electronically store, process or transmit any account data on its own systems or premises;
• it has confirmed its TPSPs are PCI DSS compliant for the services it uses;
• any account data it keeps is on paper and not received electronically.

E-commerce merchants confirm two more things: that all elements of the payment page or form delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP or payment processor, and that their site is not susceptible to attacks from scripts that could affect their e-commerce systems.

What changed in the January 2025 SAQ A?

Three requirements left the form and one eligibility criterion arrived. PCI SSC announced on 30 January 2025 that it had removed Requirements 6.4.3 and 11.6.1, which cover payment page script management and change detection, and Requirement 12.3.1, the targeted risk analysis that supported 11.6.1. In their place, merchants must confirm their site is not susceptible to script attacks. The October 2024 version of SAQ A was retired on 31 March 2025.

PCI SSC’s FAQ 1588, published in February 2025, narrowed where the new criterion applies. It covers merchants whose webpage includes a provider’s embedded payment page or form, such as an iframe. It does not apply to merchants that redirect customers to the provider, or that fully outsource payments, for example by emailing a payment link. An iframe merchant can meet it in one of two ways:

1. Use script-protection techniques such as those described in Requirements 6.4.3 and 11.6.1, deployed by the merchant or a third party.
2. Obtain confirmation from its PCI DSS compliant provider that the embedded payment form, implemented according to the provider’s instructions, includes protections against script attacks.

PCI SSC was clear that the change does not remove or diminish the underlying requirements in PCI DSS. Adyen’s guide makes the same point from the other side: 6.4.3 and 11.6.1 remain applicable to merchants filing SAQ D.

Which deadlines came with PCI DSS 4.0.1?

The big date was 31 March 2025. According to PCI SSC, 51 of the 64 new requirements introduced in PCI DSS v4.0 were future-dated and became effective that day. Until then they were best practice and could be marked not applicable.

Date	What happened	Source
31 March 2024	PCI DSS v3.2.1 retired	PCI SSC
October 2024	SAQ A for v4.0.1 published	SAQ A r1 document changes
30 January 2025	SAQ A Revision 1: 6.4.3, 11.6.1 and 12.3.1 removed, script criterion added	PCI SSC
February 2025	FAQ 1588 limits the script criterion to embedded forms	PCI SSC
31 March 2025	Future-dated requirements effective; October 2024 SAQ A retired	PCI SSC

For SAQ A merchants, the most visible future-dated item is password length. The SAQ A form notes that until 31 March 2025, passwords needed at least seven characters under the older standard; since then Requirement 8.3.6 applies in full.

How do redirect, iframe and direct post compare?

The test is who produces the payment form the customer’s browser receives. PCI SSC’s FAQ 1291 explains it: with a redirect or an iframe, the provider produces the page that accepts payment data. With a direct post, the merchant’s website produces some or all of that page and sends the data straight to the provider, so the customer never leaves the merchant’s site. SAQ A needs every element to come from the provider; SAQ A-EP allows elements from the merchant’s website as well.

Integration	Who serves the card form	Usual questionnaire	Script criterion
Full redirect to the provider’s page	Provider	SAQ A	Does not apply (FAQ 1588)
Provider’s iframe embedded in your page	Provider	SAQ A	Applies to the page hosting the iframe
Direct post or your own form posting to the provider	Merchant website, at least in part	SAQ A-EP	Not an SAQ A question; SAQ A-EP has its own website requirements
Card data sent to your own servers or API	Merchant	SAQ D	6.4.3 and 11.6.1 apply in full

Stripe’s PCI guide maps its own products the same way: its hosted Checkout and Elements fit SAQ A, an older Stripe.js form hosted on the merchant’s site fits SAQ A-EP, and a direct API integration where the merchant’s systems handle card data needs SAQ D. Stripe’s guide notes that PCI DSS as a whole contains more than 300 security controls, which is what a merchant handling raw card data takes on. Our hosted checkout comparison covers the build effort on each side.

What does the merchant still have to do under SAQ A?

Look after the webpage that sends customers to the payment form. The SAQ A form says that Requirements 2, 6, 8 and 11 apply to the merchant webpage that redirects to the provider or includes its iframe, because that page affects how account data is transmitted even though it never receives it.

Requirement	What it asks for in SAQ A
2.2.2	Change or disable vendor default accounts on web servers
6.3.1 and 6.3.3	Track new vulnerabilities and install critical patches within one month of release
8.2.1, 8.2.2, 8.2.5	Unique user IDs, shared IDs only by exception, immediate removal of leavers
8.3.6	Passwords of at least 12 characters (8 if the system cannot support 12), with letters and numbers
8.3.7 and 8.3.9	No reuse of the last four passwords; where a password is the only factor, change it at least every 90 days or analyse account access dynamically
11.3.2 and 11.3.2.1	External ASV scans at least every three months and after any significant change
12.8.1 to 12.8.5	A list of providers, written agreements, due diligence, yearly monitoring of their compliance and a record of who does what
12.10.1	An incident response plan that covers notifying the card brands and acquirers

Requirements 3 and 9 apply only if the merchant keeps paper records with account data. On multi-factor authentication, SAQ A contains no standalone MFA requirement; MFA matters mainly because 8.3.9 does not apply to systems where it is used. Using it on the admin accounts for the web server and content system removes the 90-day password rotation.

Scanning is the item merchants most often miss. PCI SSC’s FAQ 1604, from June 2026, says SAQ A merchants must have their redirect or iframe webpages scanned by an Approved Scanning Vendor even when payment processing is fully outsourced. Adyen says it provides scanning guidance for its online integrations to meet 11.3.2, and an annual Attestation of Compliance (AOC) covering its products.

How do merchant levels change who validates?

Volume decides whether a self-assessment is allowed at all. Visa’s compliance validation page sets the levels by Visa transactions over 12 months:

Visa level	Annual Visa transactions	Validation
1	More than 6 million, all channels	Annual Report on Compliance by a QSA, quarterly ASV scans, AOC
2	1 million to 6 million, all channels	Annual SAQ, quarterly ASV scans, AOC
3	20,000 to 1 million e-commerce	Annual SAQ, quarterly ASV scans, AOC
4	Under 20,000 e-commerce, or up to 1 million other	SAQ recommended; requirements set by the acquirer

Stripe’s guide adds two points: Level 1 merchants cannot use an SAQ, and Visa no longer recognises a separate Level 4 and treats merchants under 1 million transactions as Level 3. Stripe also says that at Level 2, SAQ A, A-EP and D must be signed by a Qualified Security Assessor or an Internal Security Assessor. Visa notes that a merchant whose data is compromised may be moved to a higher level. In every case the acquirer is responsible for making sure its merchants validate, so the acquirer has the final word on level and questionnaire.

Worked example: one retailer, three storefronts

Example figures, for illustration only.

A fashion retailer runs three storefronts under one legal entity and counts its Visa transactions for the year.

Storefront	Visa transactions a year	Card integration	Questionnaire it points to
Main shop	640,000	Full redirect to the provider’s hosted page	SAQ A, no script criterion
Outlet shop	410,000	Provider’s iframe in the merchant’s page	SAQ A, script criterion applies
Gift card shop	130,000	Own form posting card data to the provider	SAQ A-EP
Total	1,180,000

At 1,180,000 Visa transactions, the retailer is Level 2: an annual SAQ, quarterly ASV scans and an AOC. Because Stripe’s guide says Level 2 SAQs must be signed by a QSA or ISA, that cost goes in the budget too. The gift card shop is the problem. Its direct post form pulls that channel into SAQ A-EP, with more website requirements than the other two. Moving it onto the same hosted page or iframe as the main shop would let all three storefronts point to SAQ A. Before deciding, the retailer asks its acquirer how it wants the channels reported.

What are the common mistakes?

• Assuming a hosted checkout means no PCI work. SAQ A says plainly that using a compliant provider does not make the merchant compliant. The questionnaire, attestation and requirements remain.
• Skipping ASV scans. FAQ 1604 confirms scans apply to redirect and iframe pages, every three months and after significant changes.
• Loading the card form through your own scripts. If any element of the payment form comes from your site rather than directly from the provider, SAQ A eligibility is gone.
• Ignoring the script criterion on iframe pages. Get the provider’s written confirmation, or deploy your own script controls, before signing.
• Not tracking providers. Requirement 12.8.4 asks for monitoring of each provider’s PCI DSS compliance at least every 12 months. Keep the AOCs on file.
• Choosing the SAQ yourself. The acquirer or card brand accepts the validation, so confirm the questionnaire with them first.

How does Omno fit into SAQ A?

Omno’s hosted checkout is opened from your frontend with the Web SDK or embedded in an iFrame, and card numbers go straight to Omno’s PCI DSS compliant environment without passing through your servers. Saved cards are stored there as tokens, so your systems handle only references. That supports a redirect or iframe integration, but the SAQ A work on your own webpage stays with you: scans, patching, access control, provider monitoring and confirming the questionnaire with your acquirer. The hosted checkout page explains the integration.