I'm really disappointed in SAQ A-EP. I feel that as a web developer, there are just way too many questions that go over my head and I couldn't possibly know.
I use primarily Stripe and Braintree in my e-commerce solutions. So, there's this article of interest:
https://support.stripe.com/questions/what-about-pci-dss-3-0
They claim they're fully compliant under SAQ A. Stripe.js works by taking credit card data and passing it (via Javascript) directly to Stripe's servers, where the data is tokenized, and passed back to the merchant. Stripe says this makes a merchant eligible for SAQ A, however, SAQ A states:
The entirety of all payment pages delivered to the consumer's browser originates directly from a third-party PCI DSS validated service provider(s).
Furthermore this article states:
SAQ A:
Merchant website provides an iframe or URL that redirects a consumer to a PCI-compliant, third-party payment processor, where no elements of the page originate from the merchant website.
SAQ A-EP:
Merchant website provides an iframe or URL that redirects a consumer to a PCI-compliant, third-party payment processor, BUT some elements of the payment page originate from the merchant website. (Elements would be JavaScript, CSS or any functionality that supports how the payment page is created.)
To me, it sounds like Stripe still puts people under SAQ A-EP. Or PCI is very unclear, because both SAQ A and SAQ A-EP say that an iframe is acceptable.
But regardless of that, Stripe.js does not use iframes at all, so it seems to me it doesn't make one eligible for SAQ A.
Thoughts?
EDIT:
My mistake. After looking deeper into the Stripe.js code, I can see it's dynamically creating an iframe. I'm not sure what it's doing with it, but I'm sure they're performing some sequence of steps to be SAQ A compliant.
