I have had a couple of readers ask this question, so I thought it was time to go back and take a look at it again. It has been since 2013 that I first brought up Stripe as a potential compliance scoping issue.
The question being posed is:
The first thing to notice is the sidebar regarding the various Stripe solutions. There are three distinct solutions offered by Stripe:
- Stripe.js (the original solution)
In the PCI DSS Guidelines section is the following:
“Elements and Checkout host all form inputs containing card data within an IFRAME served from Stripe’s domain.
As long as you serve your payment pages over TLS, and use either Checkout or Elements as the only way of handling card information, Stripe automatically creates a combined SAQ A and Attestation of Compliance (AOC) for you.”
The first important point is that, if a merchant is using the Stripe.js solution, it does NOT qualify for the SAQ A. This is the original solution that I wrote about back in 2013. But the fact that Stripe.js is not SAQ A eligible is an important point for all developers to note as it could easily be missed.
What has changed is Stripe has created two new methods for processing payments: Checkout and Elements. Those methods create an iFrame that, in theory, would comply with scope minimization and allowing SAQ A to be used by the merchant.
But, this statement “As long as you serve your payment pages over TLS, and use either Checkout or Elements as the only way of handling card information …” is all in the execution by the merchant’s Web site as not all iFrames are created equal. What a merchant and their developer must do is ensure that the iFrame is created ONLY on the customer’s PC and NOT on the merchant’s Web server. If done that way, then the statement regarding SAQ A is accurate.
The reason I bring this fact up is that I have encountered solutions using an iFrame but where the iFrame is built on the merchant’s server and not in the customer’s browser. The merchant points to the fact that the solution is an iFrame and therefore their Web server out of scope. However, since the iFrame is constructed on the merchant’s Web server and then sent to the customer, it is no longer eligible for SAQ A and the merchant must follow SAQ A-EP.
As a result, it is important that a QSA look very closely at how a merchant’s Web site executes to ensure that the iFrame is never created on the merchant’s Web server.
Based on the examples of what I saw regarding the Checkout and Element solutions, as long as the code samples for Checkout or Element only execute in the customer’s browser, SAQ A would be a valid assessment option.