PCI Compliance for Online Merchants: Which SAQ You File and What the SAQ A Script Rule Requires

Every merchant that accepts cards is required to comply with PCI DSS, and every year your acquirer can ask you to prove it. The short answer to what that proof looks like: for many online merchants it means filing a Self-Assessment Questionnaire (SAQ) and an Attestation of Compliance, and the SAQ you are allowed to file depends almost entirely on how your checkout page is built. Pick the wrong one and you are either doing far more work than you need to, or attesting to something that is not true.

The rules changed in 2025. The PCI Security Standards Council added two requirements aimed at scripts running on payment pages, then rewrote the shortest questionnaire, SAQ A, so that most merchants using an embedded payment form have to confirm their site is protected against script attacks. This guide explains which SAQ fits which checkout, what the 2025 change actually asks of you, and why getting it right carries more weight on a high-risk account. The documents cited are the versions current in the Council's document library as of September 2026.

What PCI DSS Is, and Who Makes You Comply

The Payment Card Industry Data Security Standard is written and maintained by the PCI Security Standards Council, founded in 2006 by American Express, Discover, JCB, Mastercard and Visa. The Council develops the standard but, in its own words, does not monitor how it is implemented. Enforcement runs through the card brands and, in practice, through your acquiring bank. Visa's compliance page puts it plainly: acquirers must ensure that their merchants validate at the appropriate level and obtain the required compliance validation documentation from them.

The version that matters is PCI DSS v4.0.1. The Council published it in June 2024 as a limited revision of v4.0, and v4.0 itself was retired on 31 December 2024, leaving v4.0.1 as the only active version. Of the 64 new requirements v4.0 introduced, 51 were future-dated, which means they were best practice until 31 March 2025 and mandatory after it. Most of the practical change merchants felt in 2025 comes from that date.

Your validation level, which decides whether a self-assessment is enough or you need a formal assessment by an auditor, is set by the card brands based on transaction volume. Visa bases it on a merchant's total Visa transaction volume over 12 months, counted in one country or with one acquirer. Many merchants validate with an SAQ, but your acquirer tells you which method applies, and its instruction is the one that counts.

Compliance and Validation Are Two Different Things

Merchants often treat the annual questionnaire as the compliance itself. It is not. Compliance means meeting the applicable requirements every day. Validation is the paperwork that proves it, usually once a year: the completed SAQ, the Attestation of Compliance (AOC) that you sign, and, where the questionnaire requires them, quarterly external vulnerability scans run by a PCI-approved scanning vendor (ASV). The SAQ's own instructions tell merchants to submit the SAQ and AOC, along with any other requested documentation such as ASV scan reports, to the organization that requested them.

That distinction matters because a signed AOC is a statement of fact. If the eligibility criteria at the front of the questionnaire do not describe your checkout, the rest of the form does not protect you.

Which SAQ Fits Your Checkout

The Council currently publishes ten SAQs. For merchants they are A, A-EP, B, B-IP, C, C-VT, D for Merchants, P2PE and SPoC, plus a separate SAQ D for service providers. B, B-IP, C, P2PE and SPoC are built around physical equipment: imprint machines and terminals, point-of-sale systems and mobile card readers. B, B-IP, C and P2PE can also cover mail and telephone orders keyed into that equipment, and all four state they do not apply to e-commerce. For online merchants, and for phone-order teams working in a browser, the choice usually comes down to four:

• SAQ A: all processing of card data is outsourced to a PCI DSS compliant processor or service provider, and your systems never store, process or transmit card data electronically. For e-commerce, every element of the payment page delivered to the customer's browser must come only and directly from that compliant provider. In practice this means a full redirect to a hosted payment page, or a payment form embedded in an iframe served by the processor. It also covers mail and telephone order merchants who have fully outsourced card handling.
• SAQ A-EP: your website does not receive card data, but it controls how customers or their card data are sent to the processor, and elements of the payment page can come from your own site. This is the questionnaire for checkouts where your own page builds or serves the payment form, while the card data still goes to the processor without ever reaching your systems.
• SAQ C-VT: you key transactions one at a time into a virtual terminal hosted by a compliant provider, on a computer isolated from your other systems, with no card readers attached and no software storing card data. It is explicitly not for e-commerce, so a phone-sales team using a virtual terminal and a website with its own checkout are two separate channels, and each has to meet the eligibility criteria of whichever SAQ covers it. Ask your acquirer how it wants more than one channel reported.
• SAQ D for Merchants: the catch-all for everyone who does not fit another SAQ, including any e-commerce merchant whose website accepts card data and any merchant storing card data electronically.

The workload difference is large. In the current editions, SAQ A runs to 38 pages, SAQ A-EP to 83 and SAQ D for Merchants to 118. Much of the value of a hosted or embedded payment form is that it keeps you on the short one.

One detail catches merchants who assume a redirect or iframe takes them out of scope completely. SAQ A states that requirements protecting computer systems still apply to the page on your site that performs the redirect, or that contains the embedded payment form, because those pages affect how card data is transmitted even though they never receive it. Only a merchant with no redirect and no embedded form at all, such as a fully outsourced phone-order operation, marks those requirements not applicable.

The 2025 Change: Scripts on the Payment Page

The requirements behind the 2025 change are aimed at script attacks on checkout pages, often called e-skimming, where malicious code on the page copies card details as the customer types them. Two of the future-dated requirements address them directly:

• Requirement 6.4.3: every script loaded and executed in the customer's browser on a payment page must be authorized, its integrity must be assured, and it must be listed in an inventory with a written business or technical justification for why it is needed. This covers your own scripts and those loaded from third and fourth parties.
• Requirement 11.6.1: a change- and tamper-detection mechanism must alert you to unauthorized changes to the security-impacting HTTP headers and script contents of payment pages as the customer's browser receives them. It must run at least weekly, or at a frequency set by a documented targeted risk analysis.

Both requirements were part of SAQ A from its v4.0 edition. Citing stakeholder feedback about how complex they were to implement, in January 2025 the Council published a revised SAQ A that removed Requirements 6.4.3 and 11.6.1, along with the related targeted risk analysis requirement 12.3.1. In their place it added an eligibility criterion: the merchant has confirmed that its site is not susceptible to attacks from scripts that could affect its e-commerce systems. The revised questionnaire took effect on 31 March 2025, when the earlier version retired. The Council was explicit that the change affects how merchants report on these requirements and does not remove or weaken the underlying requirements in PCI DSS.

How you confirm your site is not susceptible

A month later the Council published FAQ 1588 to explain what that criterion means. It applies only to merchants whose page includes an embedded payment form, such as an iframe. It does not apply to merchants that redirect customers to the processor's own page, or that fully outsource payments. For the merchants it does cover, the FAQ gives two ways to meet it:

1. Protect the page yourself, or through a third party, using techniques such as those described in Requirements 6.4.3 and 11.6.1.
2. Get confirmation from your PCI DSS compliant processor or service provider that supplies the embedded form that its solution, implemented according to its instructions, includes techniques protecting your payment page from script attacks.

The FAQ adds one qualification that matters to anyone running a marketing-heavy storefront: a company that only supplies scripts unrelated to payment processing, such as an analytics or chat widget vendor, is not a third-party service provider for this purpose. That vendor's assurances do not count as the confirmation described in the second option.

For merchants on SAQ A-EP or SAQ D, nothing was removed. Requirements 6.4.3 and 11.6.1 apply in full, and the A-EP questionnaire includes both.

Why the Paperwork Carries More Weight on a High-Risk Account

PCI obligations are the same for a high-risk merchant as for anyone else. The consequences of letting them lapse are not.

• Non-compliance fees. Acquirers commonly add a monthly charge while your validation is outstanding. The FAQ for Clover Security, First Data's PCI program for Clover merchants, describes it as a monthly non-receipt of PCI validation fee that continues until the merchant becomes compliant or reports its compliant status. The amount is set by your provider and appears on your own fee schedule and statement.
• Termination lists. Both networks' terminated-merchant databases have a reason code for PCI DSS non-compliance: code 12 on Mastercard's MATCH and code 32 on Visa's VMSS, where listings remain for five years. Code 12 is also the one MATCH reason with a defined way out. According to Stripe's documentation of the rules, the acquirer can remove a code 12 listing after verifying that the merchant has achieved full compliance.
• Closer scrutiny. A high-risk account already sits under closer monitoring for chargebacks and fraud. An expired AOC, or an SAQ that does not match the checkout an underwriter can see on your live site, is one more reason for the bank to take a harder look at the account.

High-risk merchants are also more likely to run more than one payment channel, for example a website plus a phone-sales team on a virtual terminal, or more than one merchant account. Each channel has to fit its own SAQ, and each acquirer you work with can ask for its own validation.

A Practical Checklist Before You Sign Your Next AOC

1. Ask your acquirer which validation method and SAQ it expects from you, and in what format and by what date. The Council encourages merchants to confirm their eligibility with the organization receiving the SAQ before they start.
2. Describe your checkout accurately: full redirect to a hosted page, embedded iframe, a form your own site serves, or card data posted to your server. That description, not your processor's marketing, decides between SAQ A, A-EP and D.
3. If you use an embedded form and file SAQ A, get your processor's written confirmation that its solution protects your payment page from script attacks when implemented to its instructions, and check that your integration follows those instructions. Otherwise, put script controls in place yourself.
4. List every third-party script on the page that hosts your payment form or redirect: tag managers, analytics, chat, A/B testing. Remove what the checkout does not need.
5. Check whether your SAQ requires quarterly ASV scans, and if so keep every passing scan report on file with your SAQ and AOC.
6. Treat phone orders, virtual terminals and any card-present locations as separate channels, and confirm each one is covered.
7. Put your validation date in the calendar, and watch your statement for a non-compliance or non-validation line item. If one appears, it usually means your acquirer has no current record of your validation.

None of this is exotic, and a well-built hosted or embedded checkout keeps you on SAQ A, the shortest questionnaire an online store can file. The expensive version is discovering during an underwriting review, or after a breach, that the questionnaire you signed described a checkout you do not actually run.