Hacker News Reader

Comment by 3kMarlin | Hacker News Reader

On the surface they are more expensive than PayPal (2.9% + $0.30) Fees.

The fees for Stripe are 5% + $0.30.

However when you take a deeper look you see that things are not so simple. Compared to PayPal's free product, you are not forced to leave your website and go to a 3rd party site to complete the transaction. Compared to PayPal's Web Payments Pro product, you don't have the $30 monthly fee.

Also this doesn't even taken into consideration the complexity and cost of implementing PayPal's Payments Pro api vs Stripe's simpler JSON api.

View on HN

We haven't publicly announced any pricing yet. Stay tuned.

I await with ears wide open... and will keep my eyes open for a beta slot. I suspect that this would scratch a rather itchy itch that I have at the moment with my app.

There are also lots of hidden costs around maintaining a merchant account, which lots of other payment gateway systems require.

"you are not forced to leave your website and go to a 3rd party site to complete the transaction"

I understand this is a usability win, but doesn't this subject the original web app to PCI compliance rules?

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.

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.

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.

Reply on news.ycombinator.com