Hacker News new | past | comments | ask | show | jobs | submit login
Stealth Payment Startup Stripe Backed By PayPal Founders (techcrunch.com)
132 points by parth16 on Mar 29, 2011 | hide | past | web | favorite | 54 comments

We (awe.sm) have been using Stripe for our payments since last November. They are great: a simple, tiny API that abstracts away huge chunks of the complications around taking credit cards -- you don't need a merchant account, they handle 99% of PCI compliance, they handle pro-rating and recurring billing natively. We got our payments system to market way faster than we could have otherwise.

Anywhere us HN folks can go to request early access? :)

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.

Anyone else just not trust 100% the paypal folks?

Just from a subjective perspective based on the history PayPal has had with withholding funds etc...

How does WePay compare to Stripe?

The lowdown on Stripe:


PHP, Ruby, Python and JavaScript Support

Setup in 5 minutes.

No branding requirements or redirects.

5% + $0.30 per transaction.

US Based Sellers Only.

Recurring Billing Support.

Data Portability if you ever want to leave.

You pay all initial fees (5% + $0.30) if you issue a refund.

You will only receive money at the end of the next month.

Other neat features:

WS callbacks (aka webhooks) that notify you before a recurring payment happens, and after success/failure.

Incremental billing support, so you can e.g. tack on overage charges or small micro-charges to the next upcoming bill without needing a separate transaction for each one. Depending on your business model this could save you a lot of transaction fees.

Sounds like one problem is solved - but the big one for many is that "US Sellers only." Fix that one and expect demand to go nuts.


Edit: Oh, deleted. Now I'm really curious. (The parent originally claimed that launch pricing is going to be cheaper. Cat out of the bag, much?)

Well I doubt it'll be any lower than the industry standard of 2.9% + $0.30 for < $3k/month. If it is, that would be pretty disruptive.

What will be more interesting is if they can match both Amazon and PayPal's microtransaction rate of 5% + $0.05 for products under $10 (Amazon) to $12 (PayPal).

If that's the payment/billing API, I hope it goes over https and not http...

+ .Net support please. Not that it matters being US only.

5% is horrendously expensive. Just the other week I was ragging on Braintree for being very slighty above wholesale merchant rates.

Stripe is quite literally double Braintree's rates, with no value-add.

And on top of that, they hold the float for up to thirty days?

Good luck, guys. You're going to need it.

Does Braintree eliminate the need for a merchant account, with all the complexity that entails? Do they offer a developer API that's super-friendly to write for, allowing for weird use cases like processing payments from native BlackBerry apps without exposing you to PCI requirements or risks of publicly exposing your API keys by shipping them in apps?[1] And most importantly, is it a piece of cake to communicate directly with Braintree's founders?

'Cause that's what I've seen so far from Stripe. They're incredibly responsive and helpful. They even changed their SSL cert provider for me because older BlackBerries had a rough time with their prior cert provider.

Not to rag on Braintree, they've sounded like a good choice for a long time, but Stripe's changing some of the rules of the game. Killing the need for a merchant account is a really big deal and I'm happy to pay their rate.

[1] This isn't a rhetorical question, actually. I'd be interested in whether you can do this with Braintree.

Braintree's API is crazy simple. You can do pretty much anything you need with a single call to a well-designed endpoint using a sane object model. They have working client libraries for pretty much every tech too.

All designed and written in the last few years, and thus completely free of legacy insanity from the 70s.

You need your own Merchant Account though. They'll find you a provider if you need one.

I'm certain that when Braintree had 2 customers it was also very easy to talk to their founder and get them to change their SSL certificate provider.

I can't speak to Braintree because we don't use them. I do believe that they will set up a merchant account for you as a proxy or agent, IIRC.

But I can speak to the economics of all this "complexity" of which you speak.

We currently use CyberSource for our gateway and associated banks for our Merchant Accounts, and we maintain several accounts. Each account takes less than a day to set up, with our representatives at each company.

Integrating with the CyberSource API takes roughly 20 developer-hours.

An increase in transaction costs to 5%+0.30, would cost us roughly the salary+benefits+taxes+overhead of two fulltime developers, per year. That's a cost that's simply unacceptable.

There is also the issue of "killing the need for a merchant account", being problematic from a number of legal/accounting angles( tracing this transaction from A to M, entity separation and identifcation ), as well as customer service angles( what is this PAYCSTRIPE_TCMERCH charge on my card?? ).

You've got what's called a nice problem to have. At that rate you must be charging many millions per year, so sure, it's all about minimizing your fees. But for those of us with much smaller-to-nonexistent revenues, wondering whether our app will even make money at all, Stripe makes all kinds of sense and is a prefect place to start.

If that logo in the TC article is accurate, you may be getting a call from Deutsche Bank http://www.db.com/en/img/logo.gif

I'm pretty sure TC just made up that logo because they couldn't find one on the Stripe website. These guys are too canny to come up with a logo that shitty.

We (Simplenote) have been using Stripe since summer also, it's awesome. At least an order of magnitude easier than Paypal api and the merchant account process was completely transparent, we actually have no idea what's involved with getting a merchant account because they just handle it all and payments show up in our bank account.

Do you know if you actually have a merchant account somewhere (created by stripe)? Or does everything go through stripe?

Everything goes through Stripe.

There is no way that any merchant account provider would allow you to sign up and start charging customers in 5 minutes like Stripe lets you.

We've been using Stripe since August and couldn't be happier. They are super-responsive, do things right and make it incredibly easy to get up and running.

What did that domain cost?

Since they're not answering I'll take a guess: $80k - $140k

They went through YCombinator for Auctomatic, but not to for this company it appears. I wonder what what led them to that decision.

For Stripe, YC was actually the first firm we took investment from. Doing so was a very easy decision.

Well there ya go.

A 5 million dollar exit and previous YCombinator experience (and the network that comes with that) would by my guess.

Steve Huffman did Reddit through YC and then Hipmunk again. I'm sure you would get an even better deal on the second round, so not sure what the downside is. The upside is still big.

Stripe is also funded by YC.

Thank God that YC backed a company taking on Paypal for consumer 2 business and business 2 business.

About time a YC quality company gets in that space.

So i'm assuming this is the YC company in this batch that didn't present in Demo Day?

I would be interested to know how the rates look for high dollar transactions.

It's not really about 'stealth payment' but rather a startup in a 'stealth' mode (for those confused by the title as myself).

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact