4 ms·
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 ra
by dclaysmith 14y ago
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-way-payment-wars-braintree-finally-offers-instant-underwriting/ http://pandodaily.com/2012/10/01/a-new-twist-in-the-three-wa...
- jorde 14y agoThey also eliminated the need for merchant accounts which is a pretty big benefit compared to Braintree. One could also use Paypal but...
- jacquesm 14y agoBut 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.
- pbiggar 14y agoYou 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".
- jacquesm 14y agoIt 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.
- pbiggar 14y agoI don't understand what the risk is. Can you go into more detail?
- jacquesm 14y agoSure. 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.