By Ivan Tsarynny, CEO / Co-founder, Feroot Security
Before you buy another security tool or remove an existing control, answer one question: how does your website actually present the payment form?
For e-commerce merchants completing PCI DSS Self-Assessment Questionnaire A (SAQ A), that architectural detail matters. An embedded payment form, a redirect, and a fully outsourced payment process are different arrangements, with different implications for how the SAQ A script-attack eligibility criterion applies. A provider’s product label alone may not tell you which arrangement your live checkout actually uses.
Start With the SAQ A Script-Attack Rule
PCI SSC FAQ 1588 explains how e-commerce merchants can address a specific SAQ A eligibility criterion: confirming that their site is not susceptible to script attacks that could affect their e-commerce systems.
Importantly, the criterion applies to merchants whose webpages include a third-party service provider (TPSP) or payment processor’s embedded payment page or form, such as an iframe. It does not apply to the redirect and fully outsourced payment arrangements described in the FAQ.
For merchants using embedded payment forms, PCI SSC describes two routes:
- Use protective techniques, including techniques such as those addressed by PCI DSS Requirements 6.4.3 and 11.6.1 for payment-page scripts and change detection.
- Obtain qualifying confirmation from the PCI DSS compliant TPSP or payment processor providing the embedded payment page or form that its solution includes techniques that protect the merchant’s payment page from script attacks when implemented according to the provider’s instructions.
The merchant should still consult its compliance-accepting entity to determine which SAQ is appropriate for its environment.
This distinction helps prevent two common mistakes: assuming every SAQ A merchant needs the same payment-page security controls, or assuming outsourced payment processing eliminates every security and validation responsibility.
Map Your Payment Flow Before Determining What Applies
Start with the production checkout, not just a product name, architecture diagram, or assumption about how the payment provider works.
Work with the people who maintain the site to identify where shoppers enter card data, which party provides the payment fields, and what the merchant’s own webpage controls around them.
Capture the flow in plain language. For example: “The shopper stays on our page, and the payment fields appear inside the provider’s embedded form.” Or: “The shopper leaves our site and completes payment on the provider’s site.” These descriptions are a starting point for review, not a self-issued scope decision.
Check the less obvious payment paths too. Does a saved-card flow use the same integration? Does a campaign landing page direct shoppers to a different checkout? Did a recent SDK migration change how the payment form is delivered? Has a checkout redesign introduced new scripts or components?
An old architecture diagram is useful only if it still reflects the live implementation.
If You Rely on Provider Confirmation, Make It Specific
If you rely on confirmation from your TPSP or payment processor, make sure you understand exactly what that confirmation covers. Ask the provider to identify the solution, configuration, and implementation instructions covered by its confirmation. Then establish what your team must do for that confirmation to remain applicable.
Then have the implementation owner compare those instructions with the live deployment. Useful questions include:
- Are we using the integration method addressed by the confirmation?
- Which required configuration settings have we verified?
- Have customizations changed the payment page or its surrounding behavior?
- Which changes require another review with the provider?
- Where will we retain the confirmation and the implementation check?
A general statement that a provider is PCI DSS compliant is not necessarily the same thing as confirmation that a specific implementation meets the conditions described in FAQ 1588. Treat those as different pieces of evidence.
If You Use Protective Techniques, Verify They Are Working
If your organization relies on protective techniques to address the script-attack criterion, define exactly what those techniques observe or control, and how you know they are functioning as intended.
Understand which payment-page variants are covered, how scripts and changes are evaluated, what triggers an alert or review, and what happens when unexpected activity is detected.
Your evidence should demonstrate that the process is actually operating. Depending on your approach, that could include script inventories, implementation records, observed changes, investigation decisions, and follow-up verification. Agree on the required evidence with the people managing your compliance program.
The goal is not simply to show that a security product was purchased. It is to demonstrate that the implementation and operating process support the validation route you are relying on.
Remember: Redirects Do Not Eliminate Every SAQ A Responsibility
The distinction in FAQ 1588 is specific to the SAQ A script-attack eligibility criterion. It should not be interpreted to mean that merchants using redirects have no remaining website-security responsibilities under SAQ A.
For example, PCI SSC clarified in FAQ 1604 that SAQ A e-commerce merchants are still subject to applicable external vulnerability scanning requirements, including merchants whose webpages redirect transactions to a TPSP and those that include an embedded iframe.
That is why understanding the exact architecture, and the exact requirement being evaluated, is more useful than broadly concluding that a checkout is simply “outsourced.”
Revisit Your SAQ A Approach When Checkout Changes
Payment architecture is not static. Make meaningful payment integration changes a trigger to revisit the flow description. A new payment provider, embedded component, domain, SDK, checkout experience, or customization may change the facts supporting your previous SAQ A determination.
You do not need to turn every cosmetic edit into a full reassessment. You do need a way to recognize changes that could affect the payment architecture or the assumptions supporting your validation route.
The question should not only be, “What did our checkout look like when we completed our SAQ?” It should also be, “Do we know when something changes?”
If payment-page monitoring is part of your approach, Request a Demo to see how Feroot PaymentGuard can help provide continuous visibility into payment-page scripts and changes across your live checkout.
