He did a great job with the interview. I think Stripe will be the next big YC company, on the list with Heroku, Dropbox, and Airbnb.

I always find it a bit odd though, the claim that before Stripe you had to have a merchant account. I've signed up (on behalf of various projects) for PayPal's "Web Site Payments Pro" a half dozen times. It doesn't require a merchant account, the setup is quite quick, and it has a very simple API ("NVP"). It's pretty much everything Stripe is except less polished, with a slightly slower setup, and a $30/mo fee (insignificant for all my projects).

I'll definitely choose Stripe next time though just because they're at least 20% more polished on all fronts and I like them a lot more than PayPal. I can't help wondering whether they just didn't know about PayPal's product or they're ignoring it for marketing purposes.

Patrick from Stripe here. This is a really good point, and one that's worth clarifying. I'm just back from a run, and can't reply in depth right now, but wanted to add this comment as a placeholder before the thread falls off your radar. Will update here within a few hours.

(And, PS, thanks for the kind words.)

[Update follows]

I don't think we've ever claimed that before Stripe you had to have a merchant account. We're of course aware that there were a a bunch of services that didn't require a merchant account before Stripe (not just PayPal, but also Google Checkout and Amazon Payments).

The point we always do try to make is that the vast majority of sites (and, especially, the best sites) end up using their own merchant account. Whatever about the feature sets of PayPal and similar systems, people still ended up preferring merchant accounts, and the traditional merchant account infrastructure powers most of the e-commerce on the web.

It turns out that there are actually pretty good reasons for this: the merchant-account based solutions gave you the most control over the end-user experience, the most control over the relationship with your customers, and so on. Merchant accounts were the best solution and still are the most widely deployed option.

To the extent that Stripe is competing with anything, we're competing with that.

And so, to get back to your point: it is, overall, a pretty subtle situation, and how best to make the landscape clear in a few sentences to someone watching TV -- or someone who doesn't know much about the industry -- isn't easy. We want to be as accurate as possible without compromising clarity or brevity. If you've any suggestions as to how we could do it better, they'd be much appreciated: I'm patrick@stripe.com.

Now can you bring it to Europe, too ? :-)

We will build you a golden shrine and worship you every morning for doing so.

Working on it, I promise :-).

I wonder why it takes so long and how work on something like that looks like. Is is something you can share with us?

I guess it's like an army of lawyers trying to understand the part national, part european legislation of a couple of dozen countries ;-)

PayPal is a lot better than the older solutions (think Authorize.net). However, Stripe makes PayPal look just as bad and complicated as Authorize.net. With Stripe, you can seriously setup a site to start taking subscriptions under an hour. It's ridiculous just how easy it is. Their documentation is great too.

The first time I used Stripe, my jaw dropped when I figured out their implementation. It's just so obvious and makes so much sense (Javascript FTW).

With all due respect to all other YC companies, I think in the end, none of them will even come close to Stripe.

Stripe has one fairly major advantage over PayPal in its Javascript library which insulates the merchant from handling the credit card information thus making PCI compliance more realistic.

I've only encountered Stripe as a customer, and only once, so it may just be that the merchant (Browserling) was implementing it wrong. But the merchant asked me for my credit card number on its own domain, without SSL. I trusted the site enough to believe it really used Stripe (the only verification was text saying so), and that it was secure, but there was nothing there to prove it to me.

So maybe Stripe is secure, but they might want to work on appearing more trustworthy.

When I've used PayPal as a customer, it asked for my credit card on its own domain, not the merchant's. Doesn't that insulate the merchant from handling credit card details at least as well as Stripe's API does?

We actually require that our users use SSL on their payment pages. We describe the requirements (and motivations) in more detail at https://stripe.com/help/ssl.

I don't believe it's possible for a site accepting credit cards on a non-SSL page to be PCI compliant, period, no exceptions. It's trivial to MITM to steal your card info.

The merchant's page is loaded over an insecure connection, but the credit card details are sent to Stripe's servers over a secure connection using an iframe. So it's secure; the customer just can't verify that it is without looking at the source.

If the merchant's page include any Javascript over an insecure connection (for example, jQuery from a CDN) then an attacker can intercept this connection and replace the Javascript by a malicious script that will remove Stripe's iframe and replace it by any other iframe.

So yes, passive network sniffing won't work with Stripe's iframe being loaded over HTTPS, but this does not protect against any type of "active" man in the middle attack.

Not exactly. Iframes aren't involved (yuck how ugly!). Javascript is used to catch the form's submit, all the data on the form (credit card info) is sent straight to Stripe's server over https (via AJAX) and then their server sends back a response.

Their implementation is both elegant and smart. Even easier than Braintree.

There seems to be an iframe involved: http://i.imgur.com/R4efp.png

How does the customer know it's even Stripe's javascript running at all? There's nothing preventing the injection of malicious JS to capture the card number.

> I think Stripe will be the next big YC company, on the list with Heroku, Dropbox, and Airbnb.

I think so, too, and that makes rejection burn all the more.

One issue with Web Site Payments Pro that might affect some HNers is that Paypal will deny Third Party Payment Aggregation business models almost 100% of the time. Stripe has no issues with TPPA as long as you don't start getting tons of chargebacks. Stripe FTW.

That would be very cool. A company I contracted for had to abandon a product because of just that problem.

I could be misintrepreting it but the Stripe ToS seems to contradict you:

From https://stripe.com/terms

12. Restricted Use

In addition to any other requirements or restrictions set forth in this Agreement, you shall not: ...(iii) act as a payment intermediary or aggregator or otherwise resell our services on behalf of any third party...

Interesting - I wonder if that makes my weekend hack project http://hipay.me in violation of their terms...

Great interview - if only the interviewer wasn't trying to crack a joke at every opportunity.

The sooner they get into EU market, the better. I wish they already were here.

Is it a crazy idea to set up an account in the U.S. on behalf of non-U.S. sites and take payments via Stripe, with the caveat that the exchange rate might not be exact when you transfer funds a few days later? I can't imagine the many ways this could be found illegal and shut down, but with a small margin it could be profitable.

Yeah, profitable, but somewhat scammy and, as you pointed out, probably illegal too. Not worth the fuss if you ask me.

What tactics are used to defeat fraud?

I may start using stripe in the future. For right now we just left authorize.net (they suck) and moved to Samurai by FeeFighters: https://samurai.feefighters.com/ - I haven't heard much about them on HN but so far they seem great. Their implementation may not be as easy as stripe but they are slightly cheaper and, in our case, there was already a plugin for our shopping cart. Either way, I'm glad to see some changes in the payment industry.