PCI Security Standards Council FAQ 1588 addresses the script-related eligibility criterion in SAQ A. It says the criterion applies to merchant pages containing a processor’s embedded payment form, such as an iframe. The FAQ distinguishes those arrangements from redirects to a processor and fully outsourced payment functions. That distinction concerns this specific criterion; it is not a blanket exemption from payment security responsibilities.
The council describes two routes to confirmation: techniques protecting the page against account-data-targeting scripts, or confirmation from the compliant payment provider that its solution includes protective techniques when implemented according to its instructions. It also directs merchants to their compliance-accepting entity, typically an acquirer or payment brand, to determine the appropriate questionnaire.
Describe the checkout that customers actually use
AMS analysis: start with a short record of each payment journey, including mobile checkout, express payment buttons and any separate invoice-payment page. Record whether the customer remains on the store domain, sees an embedded form or moves to another site. Appearance alone may be misleading, so have the developer or provider confirm the architecture.
Attach that record to the provider discussion. A generic statement that a gateway is compliant does not answer whether the store has implemented the relevant configuration correctly. Ask which integration the statement covers, which instructions the merchant must follow and whether the confirmation addresses the script criterion for the page in use.
Give every checkout change an owner
Maintain a plain-language list of tools allowed to appear near checkout. Include what each tool does, who requested it, which supplier maintains it and who can remove it. Marketing tags, customer-service widgets and testing tools should have a business reason and an accountable owner. The list supports a technical review; it is not itself proof of compliance.
Before installing a seasonal add-on, ask the developer whether it changes the payment journey or the assumptions behind the existing provider confirmation. Keep the answer with the change record. If the effect is unclear, resolve that question before putting the change in front of shoppers. A busy trading period is a poor time to discover that nobody owns the integration.
Keep an evidence file that survives staff changes
Store the current integration instructions, dated provider responses, the acquirer’s questionnaire guidance and the record of approved changes together. Mark which checkout version those documents describe. An old confirmation can become difficult to rely on if the site has since moved to another plugin, theme or payment configuration.
Use a release check that follows the whole customer journey without retaining sensitive card data in screenshots or support tickets. Confirm that shoppers reach the intended payment provider, receive the expected order result and have a clear route to support. Ask the appropriate technical specialist to assess the security controls; a successful purchase alone does not establish that those controls work.
The merchant’s practical objective is an explainable checkout: a known integration, a named owner and evidence that applies to the deployed configuration. That is a stronger basis for a provider conversation than assuming that an embedded form makes every surrounding script someone else’s problem.
Primary source: PCI SSC FAQ 1588, SAQ A script eligibility. Operational recommendations are AMS analysis; confirm validation requirements with the entity accepting your assessment.
Eric Kuvykin
Publisher and editorial director covering payments, fintech, merchant services, banking, AI, technology and operating strategy for small and medium-sized businesses.
