Tessera
PCI DSS reference

SAQ A embedded payment forms: the script-security confirmation

Requirements 6.4.3 and 11.6.1 were removed from SAQ A on 31 March 2025 and an eligibility criterion was added for merchant pages with embedded processor forms—not redirects. What that confirmation asks and how PCI SSC says it can be supported.

Standard: PCI SSC FAQ 1588 and PCI DSS v4.0.1 SAQ A r1. 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. Confirm which SAQ you are actually eligible for before assuming SAQ A.
  2. The script-security criterion applies to a processor form embedded in your page.
  3. It does not apply to a processor redirect or fully outsourced payment flow.
  4. For an embedded form, support the confirmation with protective techniques or processor confirmation.

What actually changed

Most write-ups still say SAQ A merchants must comply with requirements 6.4.3 and 11.6.1. That stopped being true on 31 March 2025. The SAQ A revision published in January 2025 removed both requirements, and removed the targeted risk analysis under 12.3.1 that 11.6.1 depended on. The October 2024 version was retired on the same date.

The flow determines whether the new criterion applies

For a merchant webpage that embeds a processor-owned payment form, such as an iframe, SAQ A asks the merchant to confirm that its site is not susceptible to script attacks that could affect its e-commerce systems. PCI SSC FAQ 1588 says this criterion does not apply when the merchant redirects the customer to the processor or fully outsources payment, such as by sending a processor-hosted payment link. Do not combine those flows.

  • Identify whether the payment form is embedded, redirected, or fully outsourced.
  • For an embedded form, map which merchant-page scripts can affect the e-commerce system.
  • Keep the evidence or processor confirmation used to support the criterion.
  • Confirm the applicable questionnaire with the acquirer or payment brand.

Two ways PCI SSC says an embedded-form merchant can support it

FAQ 1588 gives two routes: use protective techniques such as those in requirements 6.4.3 and 11.6.1, deployed by the merchant or a third party; or obtain confirmation from the compliant processor that its embedded solution includes script-attack protections when implemented as directed. If neither route supports the confirmation, ask the acquirer which SAQ applies rather than letting a website choose one. SAQ A-EP and SAQ D retain 6.4.3 and 11.6.1 where applicable.

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.

Check which third-party scripts your pages load

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

Related