Mention that you're a HN user when you email us :)

Any chance you're international or is it just US only for now?

It's only US right now.

Moving to other countries will take time as each country has their own banking/financial/etc issues that need to be dealt with.

It took years for PayPal's Web Payments Pro to go from US only to US, UK. And then a few more years to go to US, UK and Canada.

Amazon FPS has been around for ages and is still US only.

So it may be a while.

Can I suggest you announce loudly and publicly when you're ready to roll out in non-US countries (in my case, Australia), remembering that many of us will have already written you off as "US only" in our heads and will skip straight past future mentions of you, expecting to be disappointed.

3kMarlin isn't involved with Stripe. collision and I are the founders. (Good point, though.)

Grr. Argh. I don't know what the market outside of the US but since there's basically no one serving us in this space you would think it would be a huge opportunity if anyone figures out how to crack it.

Anyway Stripe can figure out a way to innovate around this?

How do your fees compare to that of PayPal's? Sounds great!

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.

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 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.

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.

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. :)

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.