Hacker News Reader

Comment by modoc | Hacker News Reader

Yes. People often make the mistake of thinking that if you aren't storing credit cards then you don't have to deal with PCI compliance. While it does remove a few requirements, if you accept/transmit the credit card through any of your systems (web server -> web-app -> 3rd party API) for instance, you're still on the hook for PCI compliance. Which is a huge pain.

View on HN

Thanks for clarifying. That's my understanding of it, too.

If the form that the user puts their credit card info into POSTs to your web server, then you are on the hook. Now that I think about it, the form may POST to a third party payment processing web service from your web app which prevents the user from feeling like they have left your web app. In that case, I think that your web app is off the hook for PCI compliance.

Is that true though? If you have XSS vulnerabilities on your website, someone can lift the CC info right from the form before posting of any data happens. I am not sure whether PCI talks about this but I sure would be worried about this.

I don't know if it's true. That's a great point that you raise. It'd be nice for a PCI expert to weigh in. :)

We (at Spreedly) have talked to several QSA's about this question, and their take is that using a redirect removes the application from PCI scope. It's a really good illustration of how PCI != security.

Thanks for pointing this out! This needs a lot more attention IMO! The PCI verbage is "store, process, or transmit", which means that if you host a payment form on your site, you are on the hook for SAQ-D.

Not if you host a form. But if the form's POST goes to your server.

Reply on news.ycombinator.com