Key takeaways

  • Which Self-Assessment Questionnaire applies depends on page architecture: a redirect to the provider, an embedded provider form (such as an iframe), or a payment form your own page controls.
  • SAQ A is for e-commerce merchants that fully outsource card entry. SAQ A-EP is for those whose website does not receive card data but can still affect how the transaction is secured.
  • PCI DSS requirements 6.4.3 and 11.6.1 address scripts on payment pages: keep an inventory with a justification for each script, and detect unauthorized changes to the page. Both became mandatory after March 31, 2025.
  • For SAQ A, the PCI SSC's FAQ 1588 (February 2025) frames the issue as an eligibility criterion: the merchant has confirmed that its site is not susceptible to attacks from scripts. It applies to an embedded payment page or form, not to a redirect.
  • You can confirm that either by using techniques such as those in 6.4.3 and 11.6.1, or by getting written confirmation from a compliant provider that its solution, implemented as instructed, protects the payment page.
  • Your acquirer or card brand decides which questionnaire is required. Ask them, and keep the answer in writing.

Start with how the page is built

A nonprofit taking donations, a club selling tickets and a small shop all face the same question: when a card number is typed, whose page is it typed on? The Payment Card Industry Data Security Standard (PCI DSS) is a contractual standard published by the PCI Security Standards Council (PCI SSC), and the merchant's acquiring bank decides which assessment is required. The questionnaire follows the answer to that question. Our general article on PCI DSS 4.0.1 for small merchants covers the standard. This one is about web payment pages.

Three page designs

  • Redirect. Your Donate button sends the visitor to the payment provider's own page. Card data never touches your site. The provider may send them back to you afterward.
  • Embedded provider form. Your page loads the provider's payment form inside an inline frame (iframe). The card is typed into the provider's content, but it appears on your page.
  • Your page, your form. Fields sit on your own page, and script from the provider reads them, or your server forwards the data, or your page builds the form and posts it to the provider. Your site's code can touch or influence the card entry.

Which questionnaire

SAQ A is the shortest, and it fits e-commerce merchants that have fully outsourced card data functions to PCI DSS compliant third-party service providers, with no electronic storage, processing or transmission of card data on the merchant's systems. Redirects and embedded provider forms are the usual designs. SAQ A-EP fits e-commerce merchants that outsource payment processing but whose website does not itself receive card data and can affect the security of the payment transaction. A page that controls how the form is built or submitted is the typical example. SAQ A-EP is much longer, with requirements on patching, vulnerability scanning, penetration testing and more. Check the eligibility text in the current SAQ documents in the PCI SSC Document Library before you decide. If you also take cards by phone, on a terminal or by email, other questionnaires may apply on top of these.

The script problem

Attackers have repeatedly stolen card data by adding malicious JavaScript to a merchant's payment page, through a compromised plugin, tag manager or analytics script. PCI DSS v4.0.1 answers with two requirements. Requirement 6.4.3 asks you to manage scripts loaded and executed in the consumer's browser on payment pages: authorize each one, confirm its integrity and keep an inventory with a business justification. Requirement 11.6.1 asks for a change- and tamper-detection mechanism that alerts on unauthorized changes to the headers and content of payment pages as received by the browser. Both were future-dated best practices until March 31, 2025, and are now required where they apply.

What changed for SAQ A

This is the point that trips people up, so read it closely. In February 2025 the PCI SSC published FAQ 1588, covering PCI DSS v4.0.1 SAQ A r1. It says SAQ A includes an eligibility criterion that the merchant has confirmed its site is not susceptible to attacks from scripts. The criterion applies only to merchants whose webpage includes the provider's embedded payment page or form, for example an iframe. It does not apply to a webpage that redirects customers, whether by an HTTP redirect, a meta redirect or a JavaScript redirect, nor to merchants that fully outsource, such as by emailing a payment link.

The FAQ offers two ways to make the confirmation. The first is using techniques such as, but not limited to, those in Requirements 6.4.3 and 11.6.1, either yourself or through a third party. The second is getting confirmation from your PCI DSS compliant provider that its solution, implemented as instructed, includes techniques that protect the payment page from script attacks. The FAQ does not change other eligibility criteria, and it points merchants to their acquirer or payment brands for which SAQ applies.

So for a donation page with an embedded form, SAQ A is still possible, but only if you can show the confirmation. For a redirect, the criterion does not apply, which is one reason redirects are the simplest design. For a form your own page controls, expect SAQ A-EP and the full set of script and scanning requirements.

Practical steps

  • Draw the page: which domain does the visitor see, and which frames and scripts load? Use the browser's developer tools to list every script on the payment page.
  • Remove what you do not need. Tag managers, chat widgets and analytics on the payment page are the usual extras.
  • If you embed a form, ask the provider in writing for its script-protection confirmation and keep it with your records.
  • If you cannot get that confirmation, consider a redirect. It removes the script criterion entirely.
  • If your page controls the form, set up the script inventory, content security policy and change monitoring that 6.4.3 and 11.6.1 describe.
  • Ask your acquirer which questionnaire it expects. Get the answer in writing.

Our Cybersecurity and Managed IT Services teams can map your payment flow, build the script inventory and help prepare evidence. We are not a Qualified Security Assessor, and the attestation is the merchant's own statement to its acquirer.

Sources

This article is general information, not legal advice or a PCI assessment. The merchant's acquirer or the payment brands decide which questionnaire is required. Last reviewed .

Keep reading

Need help with this?

We find out whether everything you run is safe from attackers, then we fix it.

Cybersecurity