top | item 14902696

How the Collison brothers turned ‘seven lines of code’ into Stripe

594 points| coloneltcb | 8 years ago |bloomberg.com

182 comments

order
[+] eggbrain|8 years ago|reply
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.
[+] Kluny|8 years ago|reply
To expand, it's these 7 lines. (Actually 12)

    <form action="/your-server-side-code" method="POST">
      <script
        src="https://checkout.stripe.com/checkout.js" class="stripe-button"
        data-key="pk_test_6pRNASCoBOKtIshFeQd4XMUh"
        data-amount="999"
        data-name="Stripe.com"
        data-description="Widget"
        data-image="https://stripe.com/img/documentation/checkout/marketplace.png"
        data-locale="auto"
        data-zip-code="true">
      </script>
    </form>
- more or less. Maybe not precisely that, but it's the bit where you add a payment form to your website.

It's a nice headline, but it really leaves out the tremendous amount of back-end work that went into making that front end easy to use.

[+] mmahemoff|8 years ago|reply
So it's the equivalent of saying "How this inventor made $X billion with the flick of a switch" after they spent decades inventing the light bulb.
[+] tracker1|8 years ago|reply
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."
[+] kbenson|8 years ago|reply
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.
[+] WheelsAtLarge|8 years ago|reply
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.

[+] adam12|8 years ago|reply
The only reason why I started to read the article. I guess that's why they call it clickbait.
[+] rpod|8 years ago|reply
Thanks. There's a misleading headline if I ever saw one
[+] codazoda|8 years ago|reply
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.
[+] riazrizvi|8 years ago|reply
Contrary to some of the other commenters I think figuring how the title is true is an interesting game. It's the type of clickbait I don't mind.
[+] A1phab3t|8 years ago|reply
It's infuriating. Ok, 7 lines of code that form the tip of an iceberg of thousands of lines of code fronting months of contract and negotiation work.

WTF.

[+] free2rhyme214|8 years ago|reply
That's exactly what I was thinking. The API is definitely more than 7 lines of code.
[+] sidcool|8 years ago|reply
I would guess hacker news audience would know it.
[+] dschiffner|8 years ago|reply
I hate click-bait headlines as much as anyone else... but nowhere in this headline does it say that they started with 7 lines of code.
[+] forkLding|8 years ago|reply
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

[+] downandout|8 years ago|reply
I don't know Patrick, but he has personally jumped in here on HN where appropriate, publicly given out his own email address to handle issues, etc., and continued to do so even after Stripe achieved a $1b+ valuation. While most of their billionaire Silicon Valley contemporaries are very hard people to root for, I am rooting for these guys. They seem like genuinely good people whose success is well deserved, and so far they have not let it go to their heads.
[+] mschaef|8 years ago|reply
~12 years ago, it was Patrick Collison that was named young scientist of the year for developing a dialect of Lisp called Croma:

http://lemonodor.com/archives/001038.html

I'm glad to see he has continued to do well.

[+] smaili|8 years ago|reply
Though not the primary focus of the article, this struck a chord with me:

> When bored in class, Patrick read books. “I would line up the angles so I was hidden from the teacher’s view,” he says, adding that he found out years later that an enlightened principal had instructed teachers to allow it.

[+] mrisoli|8 years ago|reply
I used to do something similar, I had quite a few bad teachers in college on some very interesting classes, I would cut class to go to the lab and study the same subject being taught there.
[+] jozzz|8 years ago|reply
Presumably you weren't reading books on music theory.
[+] fpgaminer|8 years ago|reply
I hadn't worked with payment systems for a number of years, but recently added Stripe to a quick MVP I built (bitcoinvoice.com). It took two hours. I couldn't believe how easy it was, and how nice the UX of the whole thing was.

I imagined the usual song and dance of writing a bunch of back-end code to handle all their weird requests, worrying about double checking everything in the requests to make sure nobody can spoof them, etc, etc. Ya know, the dumb stuff that takes hours to write, hours to test, and days to wait for support to get back to you because their test servers are broken.

And then I imagined waiting days for them to approve my account for live transactions, requiring scanned copies of my driver's license with me flashing some sort of gang sign while reciting page 452 of the 1993 re-print of Moby Dick.

Nope. Turned out they have a synchronous API for processing payment so I don't need to handle callbacks on the backend. Turned out the front end code was, yeah about 7 lines (more with a few tweaks). And their documentation injects your keys into the sample code for you (wow)! On top of all that ... they had Go sample code!

And when I went to enable my live account, I'm pretty sure all they asked for was name and address, maybe TIN. Nothing else. No wait. Just ... bam, I was enabled and could start accepting live payments.

It was perhaps the most pleasant API integration I've ever done.

There are _some_ rough spots. They don't really explain Radar, their fraud protection very well. It wasn't clear to me if it was automatically included and handled. shrugs. And though they advertised support for Bitcoin payments, it turns out you have to use their async API to accept Bitcoin payments. I was willing to accept zero-conf payments, so I figured I could just keep using their synchronous API, but I guess not.

[+] jajern|8 years ago|reply
I had pretty much the same experience. I programmed an API to talk to a payment gateway connected to a chase merchant account some years ago. It was not fun. When I setup Stripe I was confused when it was done and there weren't 25 more steps before it works.
[+] cylinder|8 years ago|reply
Anyone who dealt with Authorize.net should have seen the opportunity in making these payments simpler... But I didn't.
[+] jmtame|8 years ago|reply
I vividly remember how difficult it was. You had to print pages off and fill out all this stuff and mail it to someone.
[+] wonderwonder|8 years ago|reply
The article mentions this but for me the truly great aspect of stripe is that they targeted the developer. I have dealt with several payment systems and most of them have poor documentation and getting them to work is a lot of trial and error. They appear to be monoliths who survive because management has chosen them.

Stripe provides excellent documentation and support (on #stripe in freenode). It just makes my life easier.

(I have never used Braintree so I can't comment on it)

[+] willlll|8 years ago|reply
> Over the past couple of weeks, Stripe began handling a large, though undisclosed, portion of Amazon’s transactions. Neither company will address the scope of the deal—which was only revealed by Stripe’s addition of Amazon’s logo to its website—but it could help Stripe greatly increase its trans­action volume.

So, reading into this, amazon presumably invested in stripe, then gave it some transaction traffic to juice the numbers to make an S-1 look better?

[+] omarchowdhury|8 years ago|reply
This is quite interesting. What does Amazon have to gain from using Stripe?
[+] IgorPartola|8 years ago|reply
For me, Stripe was a revelation because they eliminated fixed monthly costs. When I ran a side project that took credit cards, I found the cheapest option to be a $20/month merchant account + $20/month to Spreedly. Others had a few months free trials, etc. but ended up being more expensive over the first year.

Stripe, while being more expensive than these options per transaction, actually cost me a lot less to start out. While $40/month doesn't seem like a lot, for a hobby project that likely won't make that much money in the first months to a year, it's huge.

[+] robinjfisher|8 years ago|reply
So much this. When I started Leavetrack[1] in 2011, it was so difficult to get setup for recurring payments. I was using Chargify to handle the recurring payments/credit card storage, a company in New Zealand (I am in the UK) to handle the interface to my merchant account in the UK. Total costs:

- c. US$40 per month for Chargify (which kept increasing) - £20 per month for the payment gateway - £25 per month + transaction fee for merchant account

So happy when Stripe landed in the UK and I could migrate to a flat fee per transaction which scaled with me. Migrating is hard as you need customers to re-enter card details but an offer of reducing their monthly subscription due to savings in processing costs helped that process. :)

[1] https://leavetrackapp.com/

[+] BigChiefSmokem|8 years ago|reply
I love this. Simplicity and speed is what I fight for everyday at work but it seems I am the odd man out in my field. Everyone just wants to write over-engineered solutions that can launch space rockets with extra extra modularization you know just in case the Hubble fails again and of course fear of what may happen "in the future" in case "we ever need to scale".

How about we just focus on the job at hand for now and worry about things like scaling and robust API/interfaces AFTER we actually acquire customers and start making the money.

[+] abalone|8 years ago|reply
> Over the past couple of weeks, Stripe began handling a large, though undisclosed, portion of Amazon’s transactions.

Take this with a large, disclosed portion of salt. Amazon is big enough to pay essentially nothing in processor markup. Not to mention they sell their own payments service. If Stripe is actually handling any Amazon processing they are making no money on it, and quite possibly taking a loss to buy the volume.

Think Square's deal with Starbucks. They ended up losing $56M.[1]

[1] https://www.wired.com/2015/10/square-ipo-filing-shows-starbu...

[+] whipoodle|8 years ago|reply
Since, as you point out, they're probably not making money on the processing directly, maybe there is another reason Stripe would find it useful to process a large amount of transactions...
[+] balls187|8 years ago|reply
Seems all kinds of shitty to have an article about "Two brothers" yet feature a photo where only one brother is in focus.
[+] skrebbel|8 years ago|reply
I guess Patrick is the singer, John is the drummer.
[+] Kiro|8 years ago|reply
The biggest thing for me with Stripe was that I no longer needed a card redemption agreement. Before that I had to deal with both my bank and the provider and it was a bureaucratic mess.

I still wonder how Stripe managed to get around that.

[+] tzs|8 years ago|reply
How well does Stripe handle expired cards? The payment gateway we use now allows sending an expiration date of 0000 on submissions that are marked as being a recurring or installment payment. This attempts the transaction without doing an expiration date check [1].

Stripe's documentation says that they automatically use the credit card update services of Visa, MC, and Discover to update expiration dates of cards they are storing, so that you don't have to worry about keeping the expiration date up to date.

However, from what I've seen using the Visa and MC updater services, a significant fraction of issuing banks do not support them and when requesting updated information on those cards nothing comes back, and these cards often still actually work fine.

Does Stripe having something equivalent to 0000, so that one can say "try to charge this recurring payment on this card, even if we do not have the current expiration date and the updater service did not give a response"?

[1] The expiration date on a credit card is the date that the card itself expires, not the date that the account expires. For new orders, online or in-person, an expired card should be a red flag because a person actually placing a live order should have their latest card. Seeing an expired card live could mean it is a stolen card.

[+] basdevries|8 years ago|reply
To add a bit of insight: most Payment-Service-Providers actually pay big retailers to be listed on their site, as it improves trustworthiness and brand awareness. So the Amazon deal might not be as favorable to Stripe as it might sound.
[+] heyrhett|8 years ago|reply
"That figure has roughly doubled in the past five years"

So, 14 lines of code?

[+] samblr|8 years ago|reply
>>>> "Stripe made its debut in 2011 .... had spent two years testing their service and forming relationships with banks, credit card companies, and regulators so customers wouldn’t have to".

Can somebody help throw light on:

how Paypal was lagging in 2011 when compared to stripe ?

-OR-

how Collisons went forming better relationship with bank to build a system better than Paypal ?

[+] AdieuToLogic|8 years ago|reply
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).

The "two years testing their service" part is longer than a lot of ISO certifications, but that all depends. Ultimately, though, it's a lot easier to be certified as a VAR due to the fact that the processor (a bank usually, though can be an ISO) assumes more responsibility (risk/liability) in the relationship.

Regarding "forming better relationship with bank [sic]", it's not so much that one is has a better relationship than the other as it is their relationships are fundamentally different.

[+] tommynicholas|8 years ago|reply
Paypal's white label product was unusable (literally for some companies). Their banking relationships did not need to be better than Paypal's to have a better white labeled, developer centric payments gateway than Paypal.
[+] amichal|8 years ago|reply
I am just now in the process of completing a migration from Paypal PayFlow (Recurring Profiles) to Stripe (Subscriptions)

While Stripe's API documentation is MUCH easier to understand on the face there is a lot of undocumented complexity hidden away in there that was documented in Payflow Pro (mostly -- in a hard to find 400 page pdf).

In the end it is worth it for our specific use case. But like anything involving money over time it is much harder then it seems. Obviously, WAY more then "7 lines of code" to do it even halfway right.

I have to give massive credit to both organizations support engineers who helped us move the card details across without us ever seeing them. In the end they even ended up having to do a complex customer_id mapping for us to get it done in a way that allowed us to recreate the behaviour we had in PayFlow in Subscriptions

[+] edwinwee|8 years ago|reply
I'd love to hear more about the complexity you ran into to see if we can make it easier. Could you email me at [email protected]?