6 ms·
Now if Stripe could practice truth in advertising that would be great. SpecificallY: "Anyone accepting credit card payments must be PCI compliant. Stripe make
by patcheudor 13y ago
Now if Stripe could practice truth in advertising that would be great. SpecificallY:
"Anyone accepting credit card payments must be PCI compliant. Stripe makes it easy to do so:
Serve your payment page over SSL, i.e., the page's web address should begin with “https”, not “http”.
Use Stripe.js or Checkout to accept payment information and transmit it directly to Stripe's servers.
And you'll be PCI compliant!"
https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do https://support.stripe.com/questions/do-i-need-to-be-pci-com...
If it were only so easy. I guess there's no need for the merchant to have a PCI program, properly implement SSL/TLS, have anti-virus, change default passwords, protect agains SQLi, XSS, command injection or any number of other flaws which would give an attacker access to modify the Stripe.js code or the DOM for the page used for the collection of card information within the merchant's same origin. Nope, none of this is necessary because Stripe says that a merchant only needs to use HTTPS & implement their Stripe.js to be PCI compliant.
It's interesting that this isn't how the PCI council sees things:
https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf https://www.pcisecuritystandards.org/documents/Tokenization_...
- pc 13y agoHm, it looks like that support forum answer needs to be updated -- we actually support filling out PCI SAQs right from our dashboard (and automatically ask users to do so). We'll go update it. Also, if you'd like to drop me an email at patrick@stripe.com, would be happy to chat about PCI more.
- pc 13y ago(Updated.)
- patcheudor 13y agoConfirmed.
- JunkDNA 13y agoInstead of just down voting this post, it would be helpful to know what specific parts of it are incorrect. This is the first I've heard of these objections.
- pbreit 13y agoI think the downvotes have to do with what is a pretty serious accusation and not apparently backed up with facts. What would be helpful is if the accuser produced a better description of what he feels is out of compliance, wrong or misleading.
- patcheudor 13y agoBecause the PCI guidance isn't factual enough? An essay could be written about the problems with broad statements like merchants only needing to worry about the inclusion of Stripe.JS and the use of HTTPS to be PCI compliant. Luckily those already exist. This one covers it pretty well: http://pciguru.wordpress.com/2013/06/30/developers-beware-stripe/ http://pciguru.wordpress.com/2013/06/30/developers-beware-st...
- ricardobeat 13y agoThat article is wrong on the technical implications, like "It may be their code, but it is executing on your server" (cc data is sent directly to Stripe's servers, never touching your own).
- patcheudor 13y agoThat was maybe not quite the right language, but is easily salvageable. What the author was trying to convey is that the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant. The actual credit-card form is delivered by the merchants server & therefore they own all the PCI DSS related controls surrounding ensuring that the payment form code delivered via their HTTP response is secured. If instead of referencing Stripe.js, the merchant instead sent the user directly to https://stripe.com/payment.. https://stripe.com/payment... and the user could validate they are at stripe.com by looking in their address bar & checking the SSL/TLS security by clicking on the lock then that's a different story and the merchant would have far less exposure to the requirements outlined in the PCI DSS.
- deleted 13y ago[deleted]