PCI SSC Clarifies Obligations for Ecommerce Merchants That Outsource Payment Card Processing

The Payment Card Industry Security Standards Council (PCI SSC) has issued an FAQ for ecommerce merchants that outsource their payment card processing to a vendor using an embedded payment page or form (such as an "iframe"). FAQ 1588 clarifies eligibility criteria for Self-Assessment Questionnaire A (SAQ A)—a self-assessment form that eligible merchants can use to vastly simplify their obligations to comply with the Payment Card Industry Data Security Standard (PCI DSS).     

Background on SAQ A

PCI SSC has issued a set of 10 self-assessment questionnaires (SAQs) that eligible merchants, service providers, and others can use to demonstrate their compliance with PCI DSS in a streamlined manner. Each SAQ includes only the specific PCI DSS requirements applicable to specific eligible entities and those with a certain payment processing architecture. Entities can use these streamlined forms to demonstrate their compliance with PCI DSS, rather than performing a full compliance assessment.   

SAQ A is intended for ecommerce merchants that completely outsource their payment card processing operations to PCI DSS-compliant third parties. This includes merchants that have:

• An ecommerce site that is entirely hosted and managed by a PCI DSS-compliant vendor;
• A webpage that redirects users to a PCI DSS-compliant vendor to process the card payment; and
• A webpage that contains an inline frame (often called an "iframe") to a PCI DSS-compliant vendor to process the card payment. Where an iframe is used, a customer may navigate to a merchant's website to make a purchase, but the payment processing functionality is entirely loaded from a vendor's website.

In each of these cases, the merchant may not electronically store, process, or transmit any payment card data on its own systems or premises to be eligible to use SAQ A. Also, SAQ A cannot be used by merchants that process credit card transactions in person, such as through a physical point-of-sale (POS) system (although those merchants may be able to use a different SAQ, SAQ C).

New FAQ 1588

FAQ 1588 clarifies one of the eligibility criteria for SAQ A: that merchants must have "confirmed that their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)." This criterion has been a source of confusion for merchants and others, including because it has been unclear how merchants must perform this confirmation for operations they have outsourced to their PCI DSS-compliant vendors. The FAQ expressly applies to the version of SAQ A that is to be used with PCI DSS version 4.0.1, which goes into effect in April 2025. Even so, the FAQ's guidance also is relevant to the currently applicable version of PCI DSS and SAQ A.

The FAQ clarifies both the merchants to which this criterion applies and how applicable merchants can demonstrate that they satisfy that criterion. The FAQ states that the criterion only applies to merchants whose ecommerce websites include an embedded iframe or other page/form that is maintained by a PCI DSS-compliant vendor. It does not apply to merchants that have fully outsourced their payment functions to a compliant vendor or that redirect customers to the website of a compliant vendor to process the transaction. 

For merchants that must meet this eligibility criterion, the FAQ provides two options. Merchants may either:

• Use techniques, such as those defined in PCI DSS, to protect the page against malicious scripts targeting payment card data; these techniques may include permitting only authorized scripts to run on the website, alerting merchants of unauthorized changes to scripts and website headers, and using tools to confirm that scripts have not been tampered with; or
• Obtain confirmation from the merchant's PCI DSS-compliant vendor that the embedded iframe or other page/form includes techniques to defend against script attacks; merchants must confirm that they have implemented the iframe or other page/form according to the vendor's instructions.

Merchants that use iframes or other vendor-maintained pages/forms for card payment processing should carefully review their script security controls to determine whether they are eligible to use SAQ A. 

Additional Considerations

Merchants that use or that are contemplating use of SAQ A also should consider the following:

• Even if a merchant meets all the eligibility criteria listed in SAQ A (or another SAQ), whether a merchant actually can use that self-assessment form to demonstrate its compliance with PCI DSS is governed by specific payment card network rules. The payment card networks maintain requirements, based mostly on annual payment card transaction volumes, for determining whether a merchant can use SAQ A or must undergo a full PCI DSS assessment by a third-party Qualified Security Assessor (QSA).
• Merchants that have largely—but not entirely—outsourced their ecommerce payment processing operations to a PCI DSS-compliant vendor are not eligible to use SAQ A. However, they may be able to use SAQ A-EP. Specifically, if a merchant's website delivers any element of a payment page or form (for example, if the merchant website creates the payment form and then delivers the payment data to the merchant), the merchant cannot use SAQ A but may be eligible to use SAQ A-EP. As with SAQ A, merchants may not electronically access, store, process, or transmit any payment card data to use SAQ A-EP. All of those functions must have been outsourced to a PCI DSS-compliant vendor. SAQ A-EP includes requirements in addition to those in SAQ A for securing the merchant's website. PCI SSC's Self-Assessment Questionnaire Instructions and Guidelines provides additional guidance on using SAQ A vs. SAQ A-EP (and on using the other SAQ forms).

+++

DWT's information security team regularly advises financial institutions, merchants, service providers, and others on identifying and addressing their obligation to comply with PCI DSS. For more information about PCI DSS, please see our prior post and webinar on PCI DSS version 4.0.