The same document that has that above picture clarifies it even further with:
“If any element of a payment page delivered to consumers’ browsers originates from the merchant’s website, SAQ A does not apply; however, SAQ A-EP may be applicable. Examples of e-commerce implementations addressed by SAQ A-EP include:
- Merchant website creates the payment form, and the payment data is delivered directly to the
payment processor (often referred to as “Direct Post”).
“For context, the part of DSS 3.0 that’s most applicable to Stripe users is the new SAQ A-EP (Self Assessment Questionnaire), specifically aimed at businesses who accept payment data via a “direct post” (where cardholder data is sent directly to their processor, completely bypassing the servers of the business).
We’ve been working with our Qualified Security Assessor and others to update Stripe.js to meet the new requirements and security constraints, while still keeping it simple to use. The new version of Stripe.js meets these criteria by performing all transmission of sensitive cardholder data within an iframe served off of a stripe.com domain controlled by Stripe. This in turn allows our customers to continue to be eligible for SAQ-A (the older questionnaire) in most cases.”
While Stripe.js transmits the card data to Stripe through an iframe tunnel, the customer still has to enter their card data into the merchant’s site. In my opinion, transmitting the data through an iframe doesn’t meet the PCI requirements for SAQ A. Looking at SAQ A, merchants must confirm that:
“- Your company has no direct control of the manner in which cardholder data is captured, processed,
transmitted, or stored;
- The entirety of all payment pages delivered to the consumer’s browser originates directly from a
third-party PCI DSS validated service provider(s).”
By creating their own form and calling the Stripe tokenization API, the merchant has direct control on which cardholder data is captured. At least I would consider the inputs that asks for the card number, expiration, and CVC, which are developed by the merchant as direct control. Furthermore, it seems like it would violate the “entirety of all payment pages originates from the service provider” provision (though allowing an iframe is a bit of a loose interpretation of this). The card input is on the merchant’s website __not__ on the payment providers.
For comparison, Stripe and Braintree both offer iframe alternatives. With the iframe, the page that prompts the user for card info is loaded from the payment provider. Thus the payment provider, not the merchant, has direct control over how the data is captured, processed and transmitted. Also, because the card data is entered directly into the iframe, the merchant’s website can’t access the card number directly at all.
Stay tuned for my next post where I prove Stripe’s theory right and create a malicious iframe that would be invisible to your customers as well as provide some best practices for tokenization.