> So, yeah. What exactly is it that's so amazing about stripe?

You have to remember, they are a Y Combinator funded start-up and this is a Y Combinator site, so there is a fair amount of hype on here about Stripe.

That said, I think they are doing something interesting and useful (in a real-world commerce sense), and wish them well with it.

Oh, likewise - I think they've real promise, but they're in a crowded marketplace with a lot of really entrenched players.

I guess their principle differentiator is the market they target - but pitching to developers is a big bet. If you've worked around enough enterprises you know by now that developers have little say in business decisions - meaning that their main opportunity is to be chosen by startups, and to hope to high hell that one of them makes it big, and piggyback - and hope to high hell that a big player doesn't use their clout and cash to undercut them and shoulder them out.

Either way, kudos to them for building what's undeniably a good product, but I just don't see it as a gamer-changer in the same way as others seem to.

Honest questions: what percentage of Paypal's revenue comes from eBay? Is Stripe's pricing model unsustainable at the lower tiers? In other words, what's stopping them from serving millions of small merchants instead of a few giant ones?

Paypal/eBay - couldn't find any published figures on this, but looking at eBay's revenues vs. PayPal's revenues, it'd appear that it's a substantial but not dominant share of their revenue.

Pricing model - no, it's great, but as you grow, it becomes uneconomical.

What's stopping them? Fraud. Fraud fraud fraud. They will end up with an approval process, as if they get hit big a few times (they will), their merchant acquirers/clearers will insist on it.

I am still amazed Stripe is around with the huge fraud potential. Paperwork sucks, but its needed.

The thing is, most paperwork doesn't actually help eliminate fraud. It just creates inefficiency and friction.

They were also the first (or one of the first) to (nearly) eliminate the approval process. You could go from registration form to accepting payments in hours rather than the old process of getting merchant service account and then payment gateway.

Braintree, which was the "pro-developer" option has only recently followed suit and begun offering this "instant underwriting".

http://pandodaily.com/2012/10/01/a-new-twist-in-the-three-wa...

They also eliminated the need for merchant accounts which is a pretty big benefit compared to Braintree. One could also use Paypal but...

But CC bill had all that before, and before CC bill Ibill had it, and before Ibill DMR had it and so on.

In fact, if there is one Achilles heel in Stripe it is that they don't segregate their merchant accounts. In other words, as far as I understand their set-up, if they lose their merchant account the whole thing goes up in smoke.

You make it sound like the banking equivalent of running on a single Slicehost VPS, which I think does a disservice to the incredibly smart people running Stripe. I doubt there is any risk at all of "if they lose their merchant account the whole thing goes up in smoke".

It doesn't do a disservice to them at all. It's just that there are a few inherent risks to this model and I can't see how 'no merchant account' is a plus for any serious business.

A merchant account is expensive and integration can be a pain but there are also distinct advantages to having your own. That does not mean that I underestimate the smarts of the people running Stripe, anything but.

I don't understand what the risk is. Can you go into more detail?

Sure. Fraud is one of the bigger risks when you deal with non-segregated merchant accounts. This basically means that when it comes to fraud there is an overall chargeback limit that you share with all the other merchants in the same cluster, as well as the risk that one or more of the merchants are processing so-called high risk transaction on a non-high-risk merchant account (or maybe even downright illegal transactions). If one of those merchants is substantially larger than the rest or if you are in a group that has a higher risk profile than you yourself have chances are that at some point VISA/MC/Whichever will fine the holder of the merchant account or will shut down the merchant account altogether. These fines can be substantial (sometimes in the millions) and this can cause the whole thing to collapse. If you're even more unlucky the money that was still pending deposit on the merchant account will be used to pay off part of the fine. If you have your own merchant account then if the payment service provider (Stripe in this case) makes a bad decision with acceptance of a particular merchant then that will only affect one merchant.

Exactly what the fall-out of such a problem is is highly dependent on the acceptance policy and the level of fraud prevention in place to make sure that bad apples are detected before it becomes a problem for a larger group of merchants as well as the size and composition of the clusters (sometimes there is only one such as was the case with IBill). This is - obviously - not under the control of the individual merchants so you have absolutely no guarantee that there is no risk from this angle and it is not in the interest of an IPSP using this model to disclose who their customers are and what the exact setup is (since this would give bad merchants a leg up on how to game the system).

The IPSP game is complex, there are lots of gotchas and there are a ton of things that have been tried in an arms race that is now roughly 18 years old. A late entrant to this arms race will find a lot of opposition armed to the teeth and battle hardened.

This is the reason why it is very hard to displace paypal, for all the flak they're getting they have the fraud angle under control. Stripe is still young and they are probably learning valuable lessons at a very fast rate. I have all the faith in them coming through this in one piece but that still does not detract from the fact that this particular model carries an extra risk.

If stripe were to offer an option (which likely would have to have better rates than their current plan) where higher volume merchants would be able to bring their own merchant account to the party then I think that would be positive for everybody. I'm not sure if they are thinking in this direction or if that option is even on the table for them. But it would make me feel a lot better about putting my apples in the stripe basket. And I really like the founders.

After having been bitten twice by the shared merchant account model I hope you'll forgive me my reservations, IBill and DMR cost me a very large amount of money and I'm not about to risk that once more. If you have $50 in sales every month then I can understand that a merchant account is not worth it but as soon as a business is more serious then your merchant account becomes your lifeline. IBill used some pretty dumb strategies for risk mitigation (such as adding low dollar amount charity charges into the mix to offset the high chargeback risk because the chargebacks were taken as a fraction of the total number of charges rather than of total charge volume which helped to mask a problem). Regardless of the rest of the setup, a merchant account you share with others translates into a (substantial) extra risk.

Another aspect here is that if your IPSP goes under that you lose access to your renewals, for a subscription based service that is lethal. And IPSPs are not usually allowed to give you a copy of the subscriber data because of card company regulations (PCI).

I hope that's detail enough for you.

I work at Stripe, and I can assure you that the situation you described would not apply to any of our users. All Stripe accounts are independent of each other, and the actions of one user do not affect anyone else. We've worked closely with our banking partners to ensure that this is the case in the US and Canada, and we're working to make sure we can provide the same level of service and ease of use in other countries as well.

Separately, Stripe is allowed to transfer customer data to other PCI-compliant providers. So if you ever want to move to another provider, we'll happily move your customer information to your new payment provider (or your own systems, if you are PCI-certified): https://stripe.com/us/help/faq#export-card-data

That last paragraph is really good news.

So do you or do you not have separate merchant accounts per customer?

And if they're not separate do you have multiple merchant accounts or just a single one?

> I can assure you that the situation you described would not apply to any of our users. All Stripe accounts are independent of each other, and the actions of one user do not affect anyone else.

If one stripe account maps onto one merchant account then I can see how that would work, but if that's not the case then I really fail to comprehend how you could make that claim.

I wouldn't quite think about it in terms of a merchant accounts -- it's an old term in a changing industry, and it doesn't apply to Stripe users. They get the same benefits that they'd get with a merchant account (independent reputation, fund segregation, your own name on card statements) and none of the associated hassle.

In fact, thinking about merchant accounts for your Stripe account is like thinking about the physical address of one of your AWS instances - it doesn't really matter.

I'm a 15 year veteran of the internet payment industry, I have yet to see a single cc transaction without a merchant account, as far as I know this is not some 'antiquated term', but simply how business is done.

> it doesn't apply to Stripe users.

But it does presumably apply to stripe.

I like stripe - a lot - but I really wished that you would separate marketing from fact here and make it plain whether or not transactions for multiple stripe account holders are passed through the same merchant account or not. If no merchant accounts are involved at all then that is also a valid answer but again, I fail to see how this is possible.

My direct experience is limited to:

  - DMR (gone out of business)
  - CCBill (barely survived after a buy-out but left 
    1000's of merchants stranded with their funds
    confiscated by the card companies)
  - Virtual Access
  - PaySquare
  - paypal
  - and quite a few others besides on behalf of customers
  - PayBuyNet (since gone out of business)

For most of those I have a pretty good idea of what happened behind the scenes. Either stripe has a new model or I am still not understanding you.

Thinking about merchant accounts matters because payments are the lifeblood of a company and not understanding how service provider implements such details can be the difference between surviving and getting caught up in something beyond your control.

Your AWS suggestion implies 'merchant account hopping' where transactions are processed through a variety of merchant accounts, is that what you are getting at?

> I like stripe - a lot - but I really wished that you would separate marketing from fact here and make it plain whether or not transactions for multiple stripe account holders are passed through the same merchant account or not.

That's fair (and thanks!)

Depending on the context, we use both individual merchant accounts as well as shared accounts with unique merchant identifiers. I should add that this model isn't unique to Stripe, but it's still a relatively new model in the industry.

A Stripe account is perhaps best thought of in terms of its properties rather than as a traditional, segregated merchant account or a shared account. The typical benefits of a traditional merchant account are:

1. Your name shows up on customers' statements.

2. Your funds are clearly segregated from those belonging to other users (and from the payment provider's as well).

3. Your account's reputation is independent of other users.

Let me know if I've missed any properties that you think are important. Stripe gives you all of these properties, with the added bonus of not requiring a lengthy form faxed in with a copy of your driver's license.

I completely agree with the concerns around merchant accounts. It's probably worthwhile noting that even with a segregated merchant account, it's important to make sure you're actually getting all the properties mentioned above.

Ok, that clears it up.

I've shot John an email reply outlining some new fraud developments (new to me, that is) which might impact this particular model in a negative way.

For now I'll be keeping my recurring income in my known-to-be-good merchant account(s) with standard IPSP hookup, we'll see how this plays out in the mid term and at some point I'll probably switch a portion of my volume over to stripe to see how it goes.

I'm fully aware of the model you are employing and its possible consequences, it has a lot of the benefits of segregation but not all of them, and it is still very much dependent on one important single variable, which is how many merchant accounts you have. Keep in mind that from the financial institutions point of view (even if you have multiple banks in multiple countries) Stripe is still a single entity and that if transactions from Stripe taken as a group carry too much risk then Stripe as a whole can be cut off from their processing ability. All it takes is one directive from VISA/MC and you will find it very hard to open new accounts or maintain existing ones. There are a lot of people that were the subject of such directives racking up huge amounts of air miles flying to exotic places (Cyprus, Antiqua and a whole bunch of others) trying to stay one step ahead of the grim reaper.

The bigger you are the more you'll be a target for fraudulent merchants, and the harder it will be to spot the fraud or money laundering before it hurts.

The best ways to mitigate those risks are to grow your merchant base slowly (somewhat contradictory to most business goals), to be absolutely top notch in your fraud detection and to review your existing customers as well as the new ones periodically to spot any abrupt changes in account activity.

I'm sure that's all old hat to you but just in case it isn't it might save you some grief.

Best of luck, and thanks for the candor.

Feature suggestion: allow large merchants to 'bring their own' to offset any or all of these worries.

> It's nicely written - but a nicely written API doesn't make a product.

I believe you should revisit that assumption. Stripe is successful because of its API and UI. Likewise, Facebook and the iPhone largely succeeded because of their UI and API.

The Stripe API is really good...but it's not perfect. It still requires a huge amount of manual development that services like Recur.ly and Spreedly already implement.

Having implemented several Stripe sites, I found I preferred more of an automated recurring subscription management service, and then Stripe is just a gateway at that point.

That being said, I use Stripe extensively and love it.

Facebook succeeded because they got the network effect right, and Zuck chose the initial rounds of members at Harvard carefully (mostly girls, mostly rabid networkers/socialisers), and the ensuing rollout to other colleges/countries were staged carefully to maximise demand.

iPhone - marketing, marketing, marketing, marketing, and the US had never really seen a smartphone before. Then, ecosystem and snowball.

That said, I agree that UI is a fundamental part of any product - API, however, not so much - Joe Public doesn't care and neither does your CFO - and as posited, developers, no matter how much we'd like to think we are, are not influencers in the markets where PSPs are entrenched.

The easy of implementing it into any app is incredible. The dashboard is also very simple and easy to use. It eliminates needs for Gateways, scammy Paypal and other merchants.