PCI DSS SAQ A for e-commerce merchants: eligibility

Can an e-commerce merchant use PCI DSS SAQ A?

SAQ A applies only when every one of its eligibility criteria is met, and the merchant should confirm which Self-Assessment Questionnaire applies with its acquirer or payment brand before it starts work. A payment provider, acquirer or contract that asks for validation of an e-commerce site is usually asking the merchant to identify its validation type, so the first task is to read the eligibility criteria against the actual checkout design. Outsourcing payment pages does not by itself guarantee SAQ A eligibility. The merchant must also confirm that it stores no cardholder data electronically, that its payment function is fully outsourced, and that its website does not handle card data in a way that exposes it to the payment flow. The v4.0.1 SAQ A, effective since 31 March 2025, removed Requirements 6.4.3 and 11.6.1 and the related targeted risk analysis under Requirement 12.3.1 from the questionnaire. It added an eligibility criterion that the merchant confirms its website is not susceptible to script attacks that could affect its e-commerce systems. That criterion applies to merchants whose page embeds a provider's iframe or form. Merchants that only redirect customers to the provider or fully outsource payment do not face it, according to PCI SSC FAQ 1588. Confirm the answer for your own page structure, and record how the decision was made, because the assessor or your acquirer may ask for it. Quarterly external scans by an Approved Scanning Vendor still apply to redirecting or iframe-embedding pages, as explained in the scanning section. The merchant owns its controls and the eligibility decision. An implementation partner can help inventory every script, iframe and third-party tag on the checkout and gather evidence of how the provider's page is served, but the partner cannot attest to eligibility on the merchant's behalf. Validation comes from the merchant's own attestation process, completed on the SAQ and its Attestation of Compliance, or from an independent assessor where the merchant's validation path requires one. Ask any provider you engage to show, in writing, which parts of the checkout they control and which remain the merchant's responsibility.

Which SAQ A eligibility criteria must the merchant meet?

SAQ A is only available when every eligibility criterion holds at the same time. The cards below cover the core conditions that define the payment flow SAQ A assumes, and each one needs to be checked against how payments actually work on your site. Confirm the exact wording of the criteria in the official SAQ A text and with your acquirer.

Full outsourcing of payment functions

The merchant must hand all payment functions to a PCI DSS compliant payment provider, so that card entry and processing happen on the provider's systems rather than the merchant's. Check that the provider is validated for the service you use, and confirm that no card data handling remains in your back office, call handling or customer service tools. Ask the provider for its current Attestation of Compliance.

No electronic storage of cardholder data

Cardholder data must not be stored, processed or transmitted electronically on the merchant's own systems. This covers databases, logs, support tickets, spreadsheets, email and backups that might capture a card number. Search these locations for stray account data, because a single exported order file can disqualify the merchant from SAQ A.

Control limited to the payment page

The merchant's website must be the only point where it controls the payment page, meaning the merchant does not change the payment form or the code that collects card details beyond what the provider supplies. Review who can edit checkout templates, tag managers and page scripts, since any merchant-controlled change to the payment page moves the merchant outside this criterion.

Script attack susceptibility confirmed

Since January 2025, the merchant must confirm that its website is not susceptible to script attacks that could affect its e-commerce systems. This applies when the page embeds the provider's form or iframe, so the merchant should inventory every third-party script on checkout pages and document how each one is authorized and monitored. Record this confirmation as part of the annual validation evidence.

All criteria tested together

Eligibility is not a checklist where most items are enough. The merchant must meet every criterion at the same time, and a single unmet condition means SAQ A cannot be used even if the others hold. Walk through the real payment flow from product page to confirmation, and repeat the check after any site, provider or script change.

Acquirer confirmation of the right SAQ

SAQ A is one of several merchant questionnaires, so the merchant should confirm with its acquirer or payment brand that SAQ A is the correct validation type for its business. Keep a written record of that confirmation with the scope description and the provider's documentation, so the eligibility decision can be explained to an assessor or acquirer later.

What the January 2025 script-attack criterion asks of e-commerce teams

The script-attack criterion is an eligibility condition added to SAQ A on 30 January 2025. It requires the merchant to confirm that its website is not susceptible to script attacks that could affect its e-commerce systems. The updated SAQ A took effect on 31 March 2025, when the October 2024 version was retired. The criterion applies when your webpage embeds a payment provider's page or form, such as an iframe. It does not apply to merchants that redirect customers to the provider or that fully outsource payment, so first confirm which of those models describes your checkout.

To make that confirmation honestly, your team needs a current inventory of every script that loads on pages where the payment iframe or form appears, including tag manager containers, analytics, chat widgets, A/B testing and advertising tags. For each script, record who supplies it, who can change its code, and whether it can read or alter the payment fields. Review this list on a regular basis, and check that changes to tags go through a controlled approval step. Note that PCI SSC FAQ 1592 treats providers of non-payment scripts differently under Requirements 12.8 and 12.9, but only where their scripts cannot affect the security of account data. Whether a given script qualifies for that treatment is a judgment you should document and confirm with your assessor.

Ask your acquirer or payment brand which SAQ applies to your business, and ask your QSA or the ASV scanning vendor how they expect the script inventory to be evidenced before you attest. Because SAQ A also requires quarterly external scans under Requirements 11.3.2 and 11.3.2.1 for webpages that redirect or embed an iframe, the script review and the scan results should be kept together as part of your annual evidence set. If a script cannot be justified as incapable of affecting payment data, the safer route is usually to remove it from the payment page or to reassess whether SAQ A is still the right questionnaire.

How ASV scanning fits the SAQ A cycle

The sequence below takes a merchant whose payment page is outsourced through a redirect or iframe from confirming which webpages and IP addresses are in scope to holding ASV scan results that support the SAQ A attestation. Each step names who acts and what proves it is finished.

Confirm in-scope webpages and external IP addresses
Start by listing every webpage that redirects customers to the payment provider or embeds its iframe or form, along with the external IP addresses and hostnames that serve those pages. Your team owns this inventory because it reflects how your storefront is built and hosted. Confirm the list against your website build, hosting records and any third-party scripts that load on checkout pages. The output is a dated inventory that the ASV and your acquirer can both trace back to your e-commerce environment. Keep it with your SAQ A evidence so you can show later which assets the scans covered.
Engage a PCI SSC Approved Scanning Vendor
Select an ASV from the PCI SSC list of approved scanning vendors and agree the scope in writing before any scan runs. Your organization signs the engagement and pays the ASV, which is the independent party that performs the scans and issues the results. Ask the vendor to confirm the scan covers the hostnames and IP addresses from your inventory, how it handles findings it disputes, and how the report is delivered. The output is a signed scope that matches the inventory. Confirm the vendor's listing status directly on the PCI SSC site before you sign.
Run the quarterly external scans
The ASV runs external vulnerability scans against the in-scope addresses at the quarterly cadence required by Requirements 11.3.2 and 11.3.2.1. Your team schedules the scan windows, makes sure the target addresses are reachable from the scanning source, and tells the vendor about any planned changes that could cause a false result. The output is a scan report for each quarter with the findings and a pass or fail result. Track the scan dates on your compliance calendar so a missed quarter is visible early.
Review passing and failing results
Read each scan report and sort findings by severity and by whether they affect the webpages that handle the payment flow. A passing result means the ASV found no failing vulnerabilities for the scanned addresses in that run. A failing result means at least one finding must be fixed and the scan repeated before the quarter can be treated as compliant. Your team, not the ASV, decides how to fix each issue and documents the reasoning for any finding you contest through the vendor's dispute process. The output is a reviewed report with an owner and a status for each finding.
Remediate findings and rescan
Assign each failing finding to an owner, such as the web hosting provider, the platform team or the storefront developer, and fix the underlying configuration, software or exposed service. Where a fix depends on a third party, record that dependency and the date the change was requested. After remediation, request a rescan from the ASV and confirm the finding no longer appears. The output is a rescan report showing a passing result, which replaces the failing report for the quarter. Keep both reports so the history of the problem and its resolution is visible.
Retain scan results for the SAQ A attestation
Store the ASV reports, the signed scope, the inventory of in-scope webpages and addresses, and the remediation records together in your compliance evidence repository. These documents support the scanning answers in your SAQ A and the Attestation of Compliance you submit to your acquirer or payment brand. Confirm with your acquirer which records they expect and how long they should be kept. The output is a retrievable evidence set that an assessor or acquirer can review without asking your team to reconstruct the quarter.
Explain why the scan applies to outsourced payments
The PCI SSC added ASV scanning to SAQ A because a compromised merchant webpage can compromise the payment process even when card processing is fully outsourced. A script or page injected into your checkout can capture customer data before it reaches the provider, so the webpage itself stays in the security picture. Share this rationale with developers and hosting teams so they understand why a scan finding on a checkout page is a payment issue. This step produces shared understanding rather than a document, and it is worth repeating in each quarterly review.

Where requirements 6.4.3 and 11.6.1 still apply

If you validate on SAQ A and fully outsource payment pages through a redirect or an embedded iframe, Requirements 6.4.3 and 11.6.1 and the related 12.3.1 targeted risk analysis no longer appear in your questionnaire. Since 30 January 2025 the SAQ A eligibility criteria instead ask you to confirm that your site is not susceptible to script attacks that could affect your e-commerce systems. The requirements address payment page script inventory and integrity monitoring, so the removal does not mean scripts stop mattering. Your obligation is to be able to answer the eligibility question honestly.

Eligibility confirmation: Document why your pages are not susceptible to script attacks, including which scripts load and who controls them.
Quarterly ASV scans: Requirements 11.3.2 and 11.3.2.1 still apply to your redirecting or iframe-embedding webpages, as explained in the SAQ A guidance.
Stored account data: Paper records and retention rules added in the v4 SAQs still apply to SAQ A merchants.
Third-party script review: Confirm with your provider which scripts can affect account data, since providers of non-payment scripts may fall outside the third-party service provider duties in 12.8 and 12.9.
Evidence: Keep a script inventory, your provider's responsibility statement and scan reports, so the eligibility answer can be supported.

Confirm with your acquirer or payment brand that SAQ A is the correct questionnaire for your payment flow before relying on this tab.

What SAQ A still asks about paper records and stored account data

Even when a merchant outsources every payment page, SAQ A does not let it ignore card numbers that sit on paper or in files it controls. The v4 SAQs added requirements on the retention and protection of stored account data for merchants with paper records, and SAQ A merchants are included. The first task is to find out whether any such records exist at all. Walk through every place a card number could land outside the payment provider's page: printed order forms, receipts kept for returns, call-center notes, mail-order slips, handwritten phone orders and scanned images in shared folders. Illustrative example: a merchant whose staff write a customer's card number on a phone order sheet that is filed in a back office cabinet has stored account data on paper, even though the website never touches it.

Where the merchant confirms that no card data is stored in those records, it should document how that check was done, who performed it and when it was repeated. Where card data does exist, the merchant must show that it is protected and kept no longer than needed. In practice that means setting a retention period for each record type, locking paper in a secured location with restricted access, shredding or otherwise destroying records at the end of the retention period, and recording the destruction. The reader should ask the acquirer or payment brand which retention and protection evidence it expects for SAQ A, because the questionnaire's wording is the reference point for the assessment.

A merchant that moves card data onto its own systems, such as storing card numbers in a customer database, a spreadsheet, a helpdesk ticket or a call recording, usually stops qualifying for SAQ A, because the SAQ assumes the merchant does not store, process or transmit account data itself. Treat any such change as a scope change. Confirm the change with the acquirer before the next validation cycle, and do not wait for the annual attestation to discover it. The reader should also check whether a new process, such as a manual fallback for failed payments, quietly creates a path for card data to enter internal systems.

SAQ A and the other options for e-commerce merchants

This table compares SAQ A with the other validation paths an e-commerce merchant may need when its checkout does not fit SAQ A, showing the checkout pattern, the validation document, and the scanning and testing implications of each. Read each row against your own payment page design, then confirm the choice with your acquirer or payment brand before you start the assessment.

Checkout pattern	Validation document	Scanning and testing implications	What to confirm with the acquirer
Full redirect or fully outsourced payment page, with no card data touching your systems	SAQ A with an Attestation of Compliance	Quarterly ASV scans of the merchant webpages that redirect or embed the provider's iframe, plus the SAQ A requirements that remain	That all SAQ A eligibility criteria are met, including the script-attack criterion for embedded pages
Website controls how payment data is handled before it reaches the provider, such as scripts that collect or pass card fields	SAQ A-EP with an Attestation of Compliance	Broader testing than SAQ A, since the website can affect payment data before it reaches the provider; confirm which requirements apply to your page design	Whether your website's handling of payment data before transmission places you in SAQ A-EP rather than SAQ A
Systems in your own environment store, process or transmit card data, such as on-premises terminals or internal databases	A different SAQ type matched to your payment channel and systems, with an Attestation of Compliance	Testing scope depends on the systems involved and the SAQ type; confirm scanning and penetration testing obligations for that type	Which SAQ type matches your environment and whether any eligibility criteria rule out the SAQ types you are considering
Environment that does not fit any SAQ, or a merchant the acquirer or payment brand requires to validate through an assessment	Report on Compliance completed by a Qualified Security Assessor, with an Attestation of Compliance	Full assessment by a QSA, with the testing and scanning the ROC requires, typically the most effort of the options	Whether a ROC is required, the validation deadline, and whether the QSA must be independent of any consulting work you commission
Any pattern where the merchant is unsure which option applies	Confirmation from the acquirer or payment brand before choosing a document	No testing is chosen by default, so the selected option sets the scanning and testing obligations	Written confirmation of the SAQ or ROC type and the validation level that applies to your business

Where SAQ A projects stall and how to avoid it

Most SAQ A problems do not come from the questionnaire itself. They come from changes to the checkout after the assessment, from assumptions about what a provider covers, and from scan and storage routines that drift out of schedule. The cards below pair each pitfall with the usual effect and the control that keeps it from happening.

Adding scripts without rechecking eligibility

Each new analytics tag, chat widget, A/B testing library or marketing pixel loaded on the checkout can change whether your page is susceptible to script attacks. Since the January 2025 SAQ A update, the merchant must confirm that its site is not susceptible to script attacks that could affect its e-commerce systems. Keep a current inventory of every script on payment pages, and re-run the eligibility check before a script goes live. The usual effect of skipping this step is a failed eligibility check at the next validation, which can push you toward a larger SAQ.

Changing the iframe or redirect

SAQ A depends on the payment page being fully outsourced. A developer who moves the payment form onto your own domain, adds a field that collects card data, or changes the iframe source or redirect target can silently move the page out of SAQ A's scope. Treat the iframe URL, redirect logic and any payment-related templates as controlled configuration, and require review for changes that touch them. The usual effect is an unplanned SAQ upgrade, because the payment flow no longer matches what you attested.

Assuming provider status covers your site

Your payment provider's PCI DSS validation covers its own systems, not the web page your customers see. The merchant still owns the webpage, its hosting, its content management system and any scripts it loads. Ask your provider for its current Attestation of Compliance and responsibility matrix, then document which SAQ A requirements remain yours. The usual effect is a gap found at assessment time, when no evidence exists for the merchant side of the page.

Missing ASV scan timing and fixes

SAQ A requires quarterly external vulnerability scans by an Approved Scanning Vendor for merchant webpages that redirect to a payment provider or embed its iframe. The scan must be run on schedule, and a failing scan must be remediated and rescanned before it counts. Put the scan dates in your compliance calendar, assign an owner for each failed finding, and keep the passing scan reports with your validation evidence. The usual effect of a missed or failing scan is a late validation and a gap in the evidence trail.

Card data in tickets and paper

Customers often paste card numbers into support emails, chat transcripts, helpdesk tickets or order notes, and staff sometimes keep handwritten records for phone or mail orders. SAQ A also covers how stored account data is retained and protected, including for merchants that keep paper records. Set up a rule that support staff never request or record full card numbers, redact existing tickets, and limit paper records with a retention schedule and secure disposal. The usual effect is stored account data found outside the planned environment, which can expand scope and trigger remediation.

SAQ A questions e-commerce merchants ask before validating

Can an e-commerce merchant use SAQ A if its checkout embeds a payment provider's iframe?

Yes, an iframe can fit SAQ A, but only if every SAQ A eligibility criterion is met, including the script-attack criterion added in January 2025. The merchant's payment page is embedded from the provider, so the merchant must still confirm that its site is not susceptible to script attacks that could affect its e-commerce systems. The merchant must also run quarterly external vulnerability scans, because a compromised merchant webpage can affect the payment process even when processing is outsourced. Confirm with your acquirer or payment brand that SAQ A applies to your setup, since they decide which SAQ you submit.

Does the script-attack criterion apply if customers are fully redirected to the provider?

No. The PCI SSC has said the script-attack eligibility criterion applies to merchants whose webpage embeds a payment provider's page or form, such as an iframe. It does not apply to merchants that redirect customers to the provider or fully outsource payment. Redirecting customers still leaves the merchant's own webpage in the picture, so ASV scanning of that page still applies. A redirect merchant should not assume the scanning rule disappears, and should confirm the setup with its acquirer or payment brand.

How often do ASV scans have to run for SAQ A, and who runs them?

SAQ A requires quarterly external vulnerability scans for merchant webpages that redirect to a payment provider or embed its iframe, under Requirements 11.3.2 and 11.3.2.1. The scans must be performed by a PCI SSC Approved Scanning Vendor (ASV), not by an internal team. A passing scan result from the ASV is part of the evidence you keep and provide. Ask your ASV which of your hostnames and IP addresses are in scope, and check that the scan covers the public-facing pages that load payment content.

Can the merchant prepare the SAQ A itself?

Yes, the merchant can complete the SAQ A itself, because it is a self-assessment on an official PCI SSC template. The merchant's authorized officer then signs the Attestation of Compliance. Completing the questionnaire does not mean the merchant has validated correctly, so the merchant should be able to show the evidence behind each answer. Many merchants still ask an outside party to review their answers before signing, and that review is a separate engagement from the self-assessment itself.

What must the merchant's team provide to complete SAQ A?

The team typically needs to provide a set of working documents that support the questionnaire answers:

Payment flow diagrams showing how a customer reaches the provider's page or iframe and where card data never touches the merchant's systems
A script inventory listing every script and tag loaded on the payment pages, with its source and owner
Quarterly ASV scan results and evidence of remediation for any failed findings
The signed Attestation of Compliance and the provider's responsibility documentation

Ask your acquirer which evidence format it expects, since requirements for retained records can differ.

How long does SAQ A preparation take for a checkout?

The time depends mainly on how many pages and third-party scripts the checkout uses, and on how quickly the team can confirm who owns each script. A simple redirect to a hosted payment page usually needs less work than a checkout with several embedded iframes and marketing tags. The PCI SSC does not publish a standard duration for SAQ A preparation, so ask your team to estimate based on an inventory of its own pages. Build in time for the first ASV scan and for any remediation it triggers.

Can an implementation partner or QSA attest the SAQ A result?

An implementation partner cannot attest the result. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue reports, attestations or certifications. The merchant owns the answers and signs the Attestation of Compliance. A Qualified Security Assessor is needed only when the merchant's validation path requires a Report on Compliance, so confirm the required validation type with your acquirer before engaging anyone. Keep the consultant's review separate from any assessor work to protect independence.

How DeployOpen prepares e-commerce payment evidence

DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For SAQ A merchants, we prepare the systems, controls and evidence that the merchant's acquirer or payment brand will ask for, while the merchant owns its controls and an independent assessor or the merchant completes and signs the SAQ and Attestation of Compliance.

How we scope

Confirm with the merchant's acquirer or payment brand that SAQ A is the correct questionnaire before work starts.
Document how the checkout page redirects to or embeds the payment provider's page, including every script and iframe source.
Set out in the written scope which SAQ A criteria the merchant must confirm, including the script-attack eligibility criterion.
Record which systems, hosts and third parties are in scope and which are excluded, with the reasons.

How we build

Configure the self-hosted web platform and its hosting so that payment pages stay under the merchant's control and the provider's hosted fields or iframe.
Harden web servers, administrative access and logging in the client's cloud account or data center.
Set up script inventory and change monitoring for the merchant's own payment-related pages where SAQ A still requires it.
Prepare external scanning access and remediation tracking so the merchant can run quarterly ASV scans where SAQ A requires them.

How we hand over

Deliver written configuration records, the script and third-party inventory, and the data-flow description used to answer SAQ A.
Provide evidence packs that map each SAQ A requirement to the artifact, owner and review date the assessor or acquirer will request.
Document the procedures, roles and recurring tasks the merchant must run after go-live, so the merchant can keep the evidence current.
Hand over runbooks and training notes to the merchant's own staff, with clear statements of what DeployOpen does not certify.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask any provider, including DeployOpen, to state in writing which evidence it prepares and which parts the merchant or an independent assessor must complete.
Confirm the current SAQ version and any changes with the acquirer before each annual validation cycle.

PCI DSS SAQ A for e-commerce merchants