What is a “payment page”?
A simple question? Maybe not. I think a layperson would say that its the webpage where you input your payment details. A merchant completing an SAQ-A compliance assessment might disagree. Merchants load these pages with scripts to enable marketing analytics, conversion trackers and chatbots to increase conversion and help consumers complete their orders. SAQ-A eligible merchants generally load the payment collection form in an iframe supplied by their PCI DSS compliant payment service provider and consider the iframe itself to be the “payment page” not the hosting page.
Is “payment page” what is inside the iframe or is it the page that hosts the iframe is the “payment page”?
PCI DSS version 4 does not allow for “unnecessary” scripts on the “payment page”. 
And unecessary is not a very flexible term. Necessary to the merchant and its customers is not considered. It must be necessary for the payment to occur.
FAQs 1292, 1293 and 1348 seem to support the definition “payment page” as what is inside the iframe, not the page that hosts the iframe.
FAQ 1292 – “payment page” can be embedded in an iframe
- A merchant website can either redirect the consumer to a third-party payment page, or embed the third-party payment page in an iFrame.
FAQ 1293 – no part of outsourced “payment page” from merchant
- To be eligible for SAQ A, all elements of the payment pages must only originate from PCI DSS compliant service provider(s), and no single element of a payment page can originate from the merchant’s website.
FAQ 1348 how to determine the payment page
- To be eligible for SAQ A, all elements of the payment page delivered to the consumer’s (cardholder’s) browser must originate only and directly from a PCI DSS validated third-party service provider(s). The term “payment page” refers to a collection of web elements used to collect and/or process payment card data. Payment pages can exist as a standalone web page or be embedded into another web page using iframe.
Ad below this line:
