Stripe Questions Come Back

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:

“How can Stripe claim on its Web site that its JavaScript checkout solution allows for a merchant to use SAQ A?”

The first thing to notice is the sidebar regarding the various Stripe solutions.  There are three distinct solutions offered by Stripe:

  • Checkout
  • Elements
  • 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.

15 Responses to “Stripe Questions Come Back”

  1. 1 Mike
    June 20, 2018 at 4:22 PM

    I have one question, when using stripe with iframe, for recurrent payments it generate a token so the end customer can be billed monthly, is this still SAQ A or should be another SAQ?

  2. August 28, 2017 at 12:39 PM

    Is hosting just the iframe tags on the merchant server – something like this SAQ-A compliant?

  3. March 29, 2017 at 1:31 AM

    Good guideline from VISA Europe which displays the different solutions…

    Click to access processing%20e-commerce%20payments%20guide-73-17337.pdf

  4. 7 Andy
    March 23, 2017 at 11:19 AM

    “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.”

    Are you referring to the content of the IFrame, or the IFrame tag in the embedding e-commerce checkout page?

    • March 24, 2017 at 7:32 AM

      The entire iFrame is actually built on the merchant’s Web server and NOT in the customer’s browser. Not the elements that are used.

      • 9 Shawn Wright
        April 18, 2017 at 11:04 AM

        If the developer implements this as suggested, would they be technically out of scope? I understand that the merchant and Stripe would still fall in scope.

      • April 19, 2017 at 1:36 PM

        As long as the payment page is built on the customer’s PC and NOT on the merchant’s server, then the merchant’s server is NOT in scope.

  5. 11 Wastedwords
    March 21, 2017 at 8:46 AM

    Thanks for clarifying things. I can see how an IFRAME created server side would be different.

    Speaking of Stripe, where would a company fall who is using Stripe swipe readers attached to one of their devices? How do they validate compliance?

    • March 21, 2017 at 10:14 AM

      Are you thinking of Square in regards to POI (aka terminals)? Stripe does not have/support physical POI as far as I am aware.

      • 13 Wastedwords
        March 21, 2017 at 3:10 PM

        Yes I am indeed getting Stripe and Square confused!

      • March 22, 2017 at 7:36 AM

        Square does what it does because of two big points. The first point is that Square is actually the merchant of record to the card brands. So Square is accepting the risk of their solution for their customers. But the larger reason they can do what they do is that Visa USA is their largest investor. 😉

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.


March 2017

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 2,422 other followers

%d bloggers like this: