FAQ 1588 Just Landed: SAQ A Clarifications and Questions

On 28 February 2025, the PCI SSC released FAQ 1588 to clarify the new eligibility criterion in SAQ A for e-commerce merchants. In particular, the FAQ aims to clarify how a merchant can “confirm that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).”

“The merchant can confirm that the merchant’s webpage is not susceptible to script attacks by either:

Using techniques such as, but not limited to, those detailed in PCI DSS Requirements 6.4.3 and 11.6.1 to protect the merchant’s webpage from scripts targeting account data. These techniques may be deployed by the merchant or a third party.

Or

Obtaining confirmation from the merchant’s PCI DSS compliant TPSP/payment processor providing the embedded payment page/form(s) that, when implemented according to the TPSP’s/payment processor’s instructions, the TPSP’s/payment processor’s solution includes techniques that protect the merchant’s payment page from script attacks.”

FAQ 1588

The FAQ, therefore, clarifies that merchants can meet the eligibility criterion and confirm that their webpage is not susceptible to attacks in one of two ways. 

Either

• by deploying controls like 6.4.3 and 11.6.1 that prevent and detect script attacks,
  
  or 
  
  

• by obtaining confirmation from providers of the iframed/embedded payment page that their solution protects the merchant’s payment page from malicious script-based attacks.

Given the unclear wording of the eligibility criterion this is potentially a helpful clarification. 

The first option validates Jscrambler’s position that implementing controls to manage and mitigate the risk of malicious JavaScript in the parent page is the best way to ensure that a merchant meets the eligibility criterion that “their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” 

What’s also encouraging is that the Council has specified “techniques such as but not limited to …” which means that merchants can choose to meet requirements 6.4.3 and 11.6.1 as they are written, or they could deploy something like Jscrambler’s Iframe Hardening and Webpage Integrity to the parent page which will protect the iframe integration from attacks while not having the same compliance overhead (authorize, inventory and justify) of requirement 6.4.3.

The second option, of obtaining confirmation from the TPSP/payment processor that their iframed payment page is not susceptible to attacks, is intriguing. We understand what the Council is trying to accomplish here, especially in respect of smaller merchants. However, we’ve seen many viable attacks launched from the parent page against TPSP’s iframe solutions. Jscrambler’s CTO, Pedro Fortuna, demonstrated such attacks at the PCI Community Meeting last year.

 It will be interesting to see:

• The extent to which TPSPs are prepared to provide such a confirmation.

• What these techniques that protect the merchant’s page are, whether they really exist, and how have they been validated?

• Whether the legal, risk, and information security departments of risk-mature merchants are willing to rely on such a confirmation without it being backed up by contractual clauses and associated warranties.
  

It should also be noted that, once again, the PCI SSC drafting is debatable. The second option to confirm non-susceptibility refers to “the merchant’s payment page.” In this architecture, the merchant does not have a Payment Page based on the PCI DSS glossary definition: the Payment Page comes from the TPSP/payment processor, not the merchant and it is embedded in the merchant's non-payment page.

We’re assuming that the FAQ meant to say something like “the TPSP/Payment Processor’s Payment Page(s) in the iframe within merchant’s non-payment page” — although I admit that while this is technically accurate, and is consistent with the PCI DSS glossary, it is incredibly dense!

If I was still working for a brand and had input into how these things were worded, I’d have said:

(The merchant) Obtains documented confirmation from the TPSP/payment processor which provides the embedded payment page/form(s) that, when implemented according to the TPSP’s instructions, cardholder data intended to be captured by the TPSP/payment processor cannot be accessed by scripts executing in same execution context of the page(s) on the merchant’s website that include(s) the embedded payment page/form(s).

Which again is a bit dense but more represents the threat that we’re all trying to protect against.

SAQ A Clarifications and New Questions

To say that it isn’t ideal that the SSC removed two requirements from SAQ A just two months before they became applicable — and then replaced them with an inelegantly worded eligibility criterion — is an understatement. 

This FAQ goes a long way to clarify that eligibility criterion but asks new questions. 

• Firstly the degree to which TPSPs/Payment Processors will be prepared to offer the confirmation of non-susceptibility to attacks that merchants will demand. 

• Secondly, whether the underlying technical techniques actually work.

• And finally what form of confirmation will be sufficiently robust to allow risk-mature merchants to accept it.

When the revised SAQ A came out, Jscrambler advocated that meeting requirements 6.4.3 and 11.6.1 was the best way to confirm that the merchant’s site was not susceptible to attacks from scripts. FAQ 1588 has now clearly validated that approach. If you are already in the process of implementing tools such as Jscrambler’s Webpage Integrity to meet requirements 6.4.3 and 11.6.1, your safest approach is to continue on this path. 

If you are still considering your options, starting a discussion with your TPSP/payment processor and with your own internal risk and legal teams should be carried out alongside a review of the technical solutions open to you. 

My final thought is that taking the second option of just relying on the TPSP or payment processor is a real example of working out if you only want to be compliant, or whether you actually want to secure your customers' payment card data?