A reader pointed out this merchant services provider to me, so I checked it out. I ran into some concerns as I reviewed their documentation that I want to share with you all so that you have a better understanding of what Stripe does and provides.
The first thing that I want to point out is why you need to carefully read a service provider’s Web site and understand what is what. If you look at the Stripe General Questions page there is a discussion of PCI compliance. Stripe states that they are a PCI certified Level 1 service provider. What that means is that Stripe’s backend processing of card payments is PCI compliant. This statement has nothing to do with their Javascript program or any other services that Stripe offers.
But, you say, Stripe provides a Javascript program for processing payments. What about its PCI compliance? Good question. Here is a gray area with PA-DSS compliance of applications. Because Stripe is not technically selling its Javascript file (it is provided free), I am sure they believe that the Javascript does not have to be certified. However, the General Questions page is very clear that “Use Stripe.js as the only means by which you accept payment information and transmit it directly to Stripe’s servers.” To me I would think the required use of the program would imply that the Javascript is required to be PA-DSS certified since developers have no choice but to use it.
That brings up how is Stripe’s Javascript maintained? What ensures that someone does not change the script and now it starts securely communicating with another server as well as Stripe’s? This is why PA-DSS certification is necessary for applications because there is too much risk if those applications are not properly maintained and controlled. All it takes is a single successful attack and every one of Stripe’s customers will pick up a new Javascript that will do whatever the attacker desires.
The next concern I have regarding Stripe is their statement that by using their process, “you completely avoid handling sensitive card data, and keep your systems out of PCI scope.” Wait a minute. Stripe states just above that that you need to, “Serve your payment page over SSL.” That implies that their Javascript runs on your server. This gets confirmed on their SSL page where they state that their Javascript only communicates with their backend servers over an SSL connection. It may be their code, but it is executing on your server and that means that your server is in-scope for PCI compliance.
The PCI SSC really needs to get on top of service providers and their claims. It troubles me that this service provider is making claims that are totally incorrect. It is these sorts of claims that get good people get into trouble. Most developers and their organizations do not have the necessary detailed understanding of the PCI standards and therefore trust service providers to be the experts which, in the case of Stripe, they are obviously not experts and are just as clueless.
PCI Guru 
Is there sombody here that knows how javascript works?
You should probably take this post down. It really represents a fundamental misunderstanding of how Stripe, Javascript, and SSL work.
I went back and re-read this post along with reviewing Stripe’s claims and it is all accurate. The Javascript runs on a merchant’s server and that means that the cardholder data (CHD) is processed and transmitted from that server. That fact puts the server in-scope for PCI compliance which is totally opposite of what Stripe claims.
Billy is correct, you have misunderstood how javascript works, regardless of how many times you re-read anything. Javascript runs in the customers web browser, not the merchants server.
So protecting that script from being modified and invoking “bad Stripe” is whose responsibility?
It doesn’t matter if the .js is hosted on the merchant or at Stripe. SAQ-A EP specifically states that you must fill out this SAQ if :
“Your e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are REDIRECTED to a PCI DSS validated third-party payment processor; ”
This is exactly what’s happening with Stripe. The CHD is not transmitted through the merchant’s servers, but they do control how it’s redirected. The reason this is important is because the end-user is trusting the merchant. And if the merchant says “go here to make your payment”, the end user is going to trust that.
If the server get’s compromised, it’s trivial for an attacker to change were that redirect sends the consumer. They put in the their own .js. So now the CHD is going to the attackers who just forwards everything on to Stripe and all looks well to everybody.
It looks pretty clear to me that the merchant is still responsible for SAQ A EP, which includes questions for most of the full PCI-DSS.
I’d love for someone to help me understand were a merchant can use Stripe or any other SaaS and not have to at least fill out SAQ A-EP
Redirects are where a lot of QSAs disagree with the Council and card brands over the risk. I agree with your analysis of the threat presented by redirects. All it takes is someone to manipulate the redirect and the game is over. That is why I recommend that, at a minimum, merchants using redirects still do quarter external scanning (no ASV required), patch their servers doing the redirects on a regular schedule and monitor the code/script/executable/etc. that issues the redirect for any change.
However, the Council and the card brands say that servers that issue a redirect are out of scope for PCI compliance and all that is needed is SAQ A.
Until the Council sees a rise in such attacks on redirects, it will remain this way. Smart merchants will take our approach and the “box checkers” will keep doing nothing until they are required to do something.
First, thanks for your time in maintaining this site and replying back to posts. It helps tremendously to have these healthy discussions about the “gray” areas of PCI.
So when you state:
“the Council and the card brands say that servers that issue a redirect are out of scope for PCI compliance and all that is needed is SAQ A.”
-where does that come from? Can you point me to some documentation?
The reason I ask is that I have several customers and other QSA’s saying the same thing, but have not been able to show me any statement backing that up. The release of SAQ A-EP obviously states otherwise since it specifically calls out redirects.
For my knowledge, can you point me somewhere that backs up that statement?
See my post on the subject. The Council adopted the same bad and inaccurate language from the Visa Europe white paper, but the yellow chart in my post does accurately reflect the Council and card brands view. The link to the Visa Europe PDF is also there for your reference. (Sorry, but the link to the original post did not come through right in my response.)
Page 5 of the PCI SSC doc, Understanding the SAQ’s for PCI DSS v3.0, where they list examples of merchant requirements appears to contradict the requirements listed in SAQ A and SAQ A-EP. The examples also contradict the statements in the table on Page 4 of the same doc where the requirement for SAQ A-EP it states:
“controls how consumers, or their cardholder data, are REDIRECTED” (key word, REDIRECTED)
Then the example in page 5 that states you can use SAQ A if:
“Merchant website contains a URL link REDIRECTING” (key word again, hence the contradiction)
So even if you took the road “most likely to be traveled” and decided that if you’re redirecting or using an iFrame then you only have to do SAQ A, this still doesn’t apply to Stripe Connect because they are using javascript, which clearly is stated as an example of a merchant that would need to fill out SAQ A-EP.
Do you agree with this? Or the better question is, does anyone disagree with this.
This seems clear to me and I would like to hear a genuine argument against it, if there is one, with some PCI SSC or card brand documentation to support it.
Thanks again for taking the time to engage in fruitful discussion.
As I stated in my response, the Council used the same bad language that Visa Europe used in their whitepaper. I would rely on the matrix that is in my post as that is the one that portrays what the Council and the card brands really are trying to convey.
I am tired of providers stating that because they are a SAAS solution, they are out of scope for PCI.. Please educate yourself on PCI. IF you transmit DATA you are in scope and if you intend to sell this product to merchant, you should understand that PCI is not only storing data…
Likely the SaaS provider is working from the pre-January 2013 issuance of the eCommerce information supplement as their basis for stating they are not in-scope. However, even then, we are still encountering service providers that are still telling prospects and customers that they are out of scope when they are not.
To be fair, a lot of QSAs did not jump on the eCommerce bandwagon until after last year’s Community Meeting because a lot of us were afraid of misinterpreting what it stated. However, the PCI SSC did a pretty good job of answering our questions and clarifying their positions. As a result, a merchant has to totally outsource their eCommerce to be totally out of scope. Anything else has some sort of PCI compliance implications.
I’m Darragh; I’ve helped with our Level I audits here at Stripe for the past few years.
I think you bring up many good questions and the fact that they’re not quickly and easily addressed on our site is definitely something I’ll take onboard. Many of the pages of our site are built with our main users — developers — in mind and you’re completely correct that it’s perhaps not as easy for QSAs to find what they need. Thanks for the input!
As for helping our users with their PCI compliance, we’ve worked closely with PCI Council members, banks, and our auditors to make the requirements manageable for them. Hopefully we’ve made it so that fewer businesses need to store, transmit, and process cardholder data which should make the payment card industry as a whole more secure. It’s also been genuinely great seeing many of Stripe’s practices adopted by other folks — including the card brands themselves.
It’s unfortunate that many of the original comments on this post were lost because I think they had addressed most of the concerns (things like cardholder data passing directly from the customer’s browser to Stripe, Stripe’s hosting of Stripe.js, Java being different to JavaScript, etc.) If any further clarification is useful though, please feel free to reach out to darragh@stripe.com!
I think you have misunderstood how Stripe works. The javascript is not executed on any server, but the clients browser. The clients browser send the card number using an asynchronous call to Stripe’s endpoint over HTTPS, and a random generated token is returned. After that, the form is submitted to the merchants webserver, but with the token instead of the raw card number. The merchants server side then make a call to Stripe’s API with the token to finalize the payment. Thereby the card number never touches the merchants server, and is out of scope.
I also believe that PA-DSS is not required as Stripe is a SaaS product. The merchant doesn’t download the javascript and host it on their own server. It is served directly from Stripe’s server to the clients browser.
By the way I’m a big fan of your blog and learned a ton reading your posts, but I don’t agree that Stripe is making claims that are totally incorrect. I think this actually shows that sometimes the innovation is ahead of the standards, and despite it is the QSAs job to be conservative they also have to open their eyes to new ways of doing things.
Don’t get me wrong, I love finding out that my understanding is wrong.
However, if what you say is accurate, then why doesn’t Stripe clearly say that on their Web site or publish a whitepaper stating just that? If it were my company, I’d be broadcasting those facts all over the place to show people that you’re looking out for their interests and shrinking their PCI compliance scope. Just seems odd that they wouldn’t be blasting those details all over and to explain to QSAs how it truly works.
Why would the fact it is a SaaS solution make something out of bounds for PA-DSS certification? Just because it’s a service does not rule out PA-DSS certification. There are a lot of hosted/outsourced/etc. solutions that are PA-DSS certified. This BS that it is supplied as part of the service at no cost is just that, BS. It’s not Stripe that will end up fined if a breach occurs.
Well I think it is pretty clear explained here https://stripe.com/docs/tutorials/forms but I agree that something illustrating the flow would be nice.
I may be wrong about my PA-DSS argument, as you probably know more about this than I, but I’m referring to #11 in https://www.pcisecuritystandards.org/documents/which_applications_eligible_for_pa-dss_validation.pdf and also this question http://security.stackexchange.com/questions/2042/does-pa-dss-apply-to-a-saas-ecommerce-system