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.
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."
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.
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
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.
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.
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.
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.
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.
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)
> 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 transaction 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?
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.
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. :)
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.
> 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]
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...
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.
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.
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.
>>>> "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 ?
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.
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.
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
[+] [-] eggbrain|8 years ago|reply
[+] [-] Kluny|8 years ago|reply
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
[+] [-] tracker1|8 years ago|reply
[+] [-] michaelthiessen|8 years ago|reply
[+] [-] kbenson|8 years ago|reply
[+] [-] WheelsAtLarge|8 years ago|reply
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
[+] [-] rpod|8 years ago|reply
[+] [-] codazoda|8 years ago|reply
[+] [-] riazrizvi|8 years ago|reply
[+] [-] A1phab3t|8 years ago|reply
WTF.
[+] [-] free2rhyme214|8 years ago|reply
[+] [-] sidcool|8 years ago|reply
[+] [-] dschiffner|8 years ago|reply
[+] [-] forkLding|8 years ago|reply
Also really appreciate Stripe, registered for Delaware with them
[+] [-] downandout|8 years ago|reply
[+] [-] mschaef|8 years ago|reply
http://lemonodor.com/archives/001038.html
I'm glad to see he has continued to do well.
[+] [-] smaili|8 years ago|reply
> 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
[+] [-] jozzz|8 years ago|reply
[+] [-] ice109|8 years ago|reply
[+] [-] fpgaminer|8 years ago|reply
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
[+] [-] cylinder|8 years ago|reply
[+] [-] jmtame|8 years ago|reply
[+] [-] wonderwonder|8 years ago|reply
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
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
[+] [-] IgorPartola|8 years ago|reply
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
- 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
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
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
[+] [-] balls187|8 years ago|reply
[+] [-] skrebbel|8 years ago|reply
[+] [-] Kiro|8 years ago|reply
I still wonder how Stripe managed to get around that.
[+] [-] tzs|8 years ago|reply
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
[+] [-] nouveau0|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] heyrhett|8 years ago|reply
So, 14 lines of code?
[+] [-] samblr|8 years ago|reply
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
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.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] tommynicholas|8 years ago|reply
[+] [-] amichal|8 years ago|reply
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