Skip to main content
Tessera
Requirements Free check Terms
PCI DSS reference

Which PCI SAQ applies to an e-commerce site?

SAQ A, A-EP or D depends on how payment data reaches the processor. Since March 2025, an SAQ A merchant embedding a processor form also has a script-security eligibility criterion; redirect and fully outsourced flows do not.

Standard: PCI DSS v4.0.1 self-assessment questionnaires. This is a plain-language reference, not legal advice, and it does not determine your PCI DSS compliance or which questionnaire applies to you. Your acquiring bank sets your reporting obligations.

The short checklist

  1. Establish how card data reaches the processor before choosing a questionnaire.
  2. A full redirect or a processor-owned iframe can point toward SAQ A if every other criterion is met.
  3. Fields served by your own page point away from SAQ A.
  4. The SAQ A script-security criterion applies to embedded processor forms, not redirects.

Start with where the card number is typed

If the customer is redirected to the provider, or types into an iframe the provider serves and controls, your page does not receive the data. If any field is served by your own page — including a hosted-field library that your page loads and lays out — more of the standard applies to you.

Then separate an embedded form from a redirect

Since 31 March 2025, a merchant page with an embedded processor payment form has an additional SAQ A eligibility criterion: confirm the site is not susceptible to script attacks that could affect its e-commerce systems. PCI SSC FAQ 1588 says the criterion does not apply to a processor redirect or a fully outsourced payment flow. For an embedded form, use protective techniques or processor confirmation and resolve any eligibility doubt with the acquirer.

  • Is the processor payment form embedded in a merchant-controlled page?
  • Or does the customer leave for a processor redirect or hosted payment link?
  • For an embedded form, which scripts can affect the e-commerce system?
  • Can you retain the evidence or processor confirmation supporting the criterion?

Your acquirer has the final say

Reporting obligations are set by your acquiring bank or the payment brands, not by a website. Use this to prepare the conversation, then confirm the questionnaire with them.

Primary source

Read the source rather than a summary of it, including this one: PCI Security Standards Council — FAQ 1588 — https://www.pcisecuritystandards.org/faqs/1588/.

What the free check can and cannot tell you

The free check reads the HTML your server returns. It inventories script elements and observed integrity attributes, but it does not inspect HTTP response headers or fetch remote script bytes. Live 11.6.1 monitoring separately fingerprints selected response headers and referenced script contents. The free check does not run the page in a browser, and neither does live monitoring. A script injected at runtime by another script is outside what Tessera can see, and no static check can tell you whether a script is authorized — only you know that.

Reviewed August 2026. The standard and the questionnaires change; confirm against the current text before relying on anything here.

Inventory the third-party scripts on your page

Preview the synthetic 6.4.3 remediation pack before deciding whether the paid artifact fits your review.

Related

  • SAQ A embedded payment forms: the script-security confirmation
  • PCI DSS 6.4.3: managing the scripts on your payment page
  • PCI DSS 6.4.3 payment-page script inventory template
  • PCI DSS 11.6.1: change and tamper detection on payment pages
Tessera
Independent software from Toledo Technologies LLC.
Terms Privacy Refunds