If you are wondering how Stripe could even start with just 7 lines of code, it's a bit misleading:
With Stripe, all a startup had to do was add seven lines of code to its site to handle payments: What once took weeks was now a cut-and-paste job.
I.E. the simplicity of the Stripe platform (taking only 7 lines of code for developers) was how they succeeded, not that they built a startup at first with just 7 lines of code.
Nope. The Stripe advantage over PayPal is that Stripe operates more like a merchant account, where the buyer sees the seller's name on the credit card statement. PayPal injects itself into the checkout process, Stripe is basically a white label. Stripe also has easier underwriting. I suspect Stripe is taking more business from merchant accounts/gateways than PayPal, because they are different markets.
As someone that selected stripe to process orders for a product were were launching somewhere around 2012, it was because of the APIs and developer sandbox.
Paypal was ugly to work with, felt crufty, etc. Stripe had pip installable modules, awesome documentation (live code samples in docs and sandbox), and was easy to integrate into our tests.
That's the least of it. Paypal automatically puts you on a 21-60 day rolling reserve once you hit a certain level. Small businesses can and have had 30%+ of their revenue unavailable for two months. That's your entire profit margin gone. It makes it impossible to grow a small business. And of course they will not respond to anything for months if ever. And it never gets better! Companies with millions in revenue still get these problems.
Paypal has no place being used by anyone trying to start a company. They are awful.
Before Stripe - I had to take a loan out, and make the switch to Authorize.net so I could get my company off PayPal and its 60 day reserve - otherwise it would have folded. They were perpetually holding tens of thousands of dollars at all times.
They'll do that sooner or later. Everyone in the money-handling industry has to randomly lock-up funds and not tell you why, because that's what anti-money-laundering laws require.
Ok, but there's a difference between doing that because you are required to by law, and doing it because you've chosen to adopt appalling business practices.
PayPal had a developer sandbox back in 2010 when I wrote our client code. Honestly I don't remember it being difficult or tricky. The worst aspect was their confusing documentation which tended to mix up various different services and APIs such that it was hard to figure out which was the current, appropriate one. Perhaps that was the Stripe advantage: a single obvious course of action to take.
One of my best upvoted stackoverflow answers is about a paypal sandbox bug (or "undocumented feature") where it would disregard the port in the pingback url.
Just generally the sandbox was horrible, it had a weird 'double login' system where it often got confused between whether you were 'inside' the sandbox logged in as a fake user or outside logged in as your paypal account.
And you're right about their woefully confusing documentation, it was definitely hard to understand which payment flow you were trying to use and which was appropriate.
I suspect also that the marketing folks re-branded the various services on a regular basis so you weren't even sure if two different names for something actually referred to the same thing.
PayPal tried to "modernize" their old crufty SOAP API with a REST-based API but ended up creating a separate half-functional, poorly documented, buggy layer on top of it that actually loses payments sometimes. I processed millions of payments through it and actually have their support people admitting the problems.
Their only hope is a reverse-takeover from Braintree. I'm not holding my breath; I've done my last PayPal integration. Forget all the "paypal will hold your money" concerns - the real problem is that they will loose your money in the wonky Rube Goldberg machine they've created to process payments.
In a series of calls with the top tier of support at Paypal, no one was able to even answer which API was the best to use. I was told not to use SOAP (or NVP), because they're ancient, not to use REST because it wasn't ready yet, and that the Braintree API around PayPal would never support the features we were trying to implement.
Ease of development was our number one reason to use Stripe for sure. We did end up adding Paypal after and it was a pain to work with.
Stripe was so reliable that we had clickety-test that used their real sandbox API to make sure in our CI that payment kept working.
Whenever someone brings up Stripe it always brings happy memories. I've never worked with a third party API that was as nice as theirs. Their Ruby SDK helped with that of course.
> The Stripe advantage over PayPal is that Stripe operates more like a merchant account, where the buyer sees the seller's name on the credit card statement. PayPal injects itself into the checkout process, Stripe is basically a white label.
You're talking about PayPal Express, which is the PayPal form most of us are familiar with.
PayPal has a number of other services, such as Payments Pro, and PayFlow, which act just like a Credit Card Processor, ie. the customer has no idea it's PayPal on the backend - they enter their credit card info on your checkout form like normal and click submit. The customer's bank statement will state your company name, not PayPal.
Majority (all?) of the PayPal horror stories you hear are from folks using PayPal Express with large amounts of money coming from weird places. Payments Pro really is a different class of service, complete with your own representative you can call up 24 hours a day. You can also setup a nightly automated sweep of any funds to your real bank account.
The Stripe advantage over PayPal is that
Stripe operates more like a merchant account ...
Stripe is an ISO with First Data Merchant Services (FDMS, I believe now owned or controlled by Wells Fargo) doing the actual processing and, as such, assumes a different legal role than PayPal (which is a VAR for Paymentech). This is how Stripe is, as you say, "basically a white label."
We moved from PayPal to Stripe. Yes, integration was much easier, because of the simple and effective API and great documentation (good examples with your own data included - brilliant!).
But we switched because PayPal just did not work. A significant percentage of card transactions failed for absolutely no reason, despite "good" customers (school teachers from first world countries), no chargebacks and no fraud. Cards would routinely magically work the next day, and in the end we came to believe PayPal arbitrarily failed card transactions to force people to set up PayPal accounts.
Moving to Stripe resolved this overnight. We'll never go back.
And don't underestimate the power of new and... different. Many founders pass on markets they think have no room for innovation or new entrants, only to leap into some small marketless crevice.
> The real break through for stripe was it was an alternative to PayPal with a modern UI.
Paypal's documentation and the sandbox process is so atrocious that I had to question my own intelligence. Turns out the problem was with paypal and not my IQ.
The PayPal form also involved redirecting all your users over to PayPal. Stripe has always integrated into your site/service which is part of what made that form so nifty.
Wait, the /your-server-side-code bit seems like the most difficult. Did Stripe not implement this aspect as well? I would have no idea how to securely process credit card transactions server-side.
If I remember how they worked (last did stripe integration a ways back), the script instruments your form's submit event to do an (ajax if possible) POST to stripe's server, which processes everything, and returns back a (merchant specific) "token" representing a redeemable charge to the customer. The form is then posted to your server, but all it gets is the "token", which it can then use your private merchant key to redeem behind the scenes with their server.
So you get an anonymous "charge" token that you can revoke if a later part of the checkout process fails, and CC data never touches your system.
(I think the markup for that was a little bit different than what was posted above though).
Correct, and the big reason for that is it means you don't have to be PCI compliant since the card never touches your server, only stripes. That's why Stripe blew up, Paypal had no such offering for allowing you to use your own checkout form but not have to pass the card through your server.
That product seems to have a marketing problem. I've heard plenty of PayPal horror stories over the years, but this thread is the first time I've ever heard of Payments Pro.
I think they did eventually. I remember trying to use Stripe for a project during college (2012ish) that involved building a website with a REST integration in C#. My rtfm'ing skills were much worse back then so I could be wrong, but yeah, you had to do a bunch of server-side implementation and make calls to their API. It seemed quite challenging to me at the time, but looking back, it really wasn't. They've gotten rid of that extra step now though. You can just drop in the javascript and their html form with api keys and you're ready to go.
More like how turning on lights is easy for billions of people because someone else did the hard work of the power lines, generators, switches, light bulbs, etc.
Actually, it would be more like all of that stuff already existed, but it was a woeful and Byzantine process to get all of it lined up for your particular lightbulb.
It was a bit interesting to see, and perhaps not at all surprising, that they've been around since 2010. And they crossed the billion-dollar-valuation threshold 4 years later.
There's a few misconceptions in the article beyond that.
and the more modern bits are written by banks,
credit card companies, and financial middlemen,
none of whom are exactly winning hackathons for
elegant coding.
Hackathon code is never elegant... it's always piecemeal at the end in order to get it "done."
Which is already a better picture than what most people have when I tell them I attended a hackathon: "So you all get together to try and hack the security system of a company?"
I don't think it's misleading, it's just that there are different preconceptions based on the audience. If there was an article about "How two brothers turned a 3 oz piece of metal into a billion dollar startup" and it was a highly machined part that fit a really useful case in the auto industry, we would rightly assume they were talking about what they sold, and that a lot more work went into actually making and perfecting it. If the same article was read by machinists, they might take issue with it like people are taking issue with this headline, but that's because of the context they are perceiving it in.
It is misleading. It deemphasizes what can be learned from the article. What helped this company get traction was ease of use, the 7 lines of code made it easy to use, and also, that the reason this company even got off the ground is the 2 brothers and their focus on getting the company to where it is. It seems to me that whatever they would have chosen to do would have had some success.
Again, it highlights the point that it's not the idea, they're a dime a dozen, it's the people that implement the idea.
I feel like I just wasted 15 minutes digging for that and being disappointed that their MVP wasn't a 7-liner. Guess I should have come to the comments first.
The typical interpretation of "turned 7 X into Y" isn't "7 X plus another million X turned into Y". Last night I turned a pat of butter into a steak dinner. Never mind I also started with a steak, thats an irrelevant detail.
I'm thinking for the layman who doesnt code which Bloomberg also targets, this distinction is pretty negligible so in a way its not totally clickbait because its still seven lines of code, for developers it seems to be the code you write whereas the title could go anyway
Also really appreciate Stripe, registered for Delaware with them
To the layman, I imagine this reads as either "they spent a few minutes writing one paragraph and made $9B" or "they agonized for years over something as small as a single paragraph that was worth $9B"; neither of these are reasonable interpretations. It is only to the advanced technical reader that I think there is any hope of them interpreting it in the correct manner.
It participates to negating the difficulty of building and delivering a product, thereby giving said laymen a sense of entitlement over "undeserved wealth".
