How the Collison brothers turned ‘seven lines of code’ into Stripe • Hacker News Board

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

#191

Post by robinjfisher » Thu, Aug 03, 2017, 7:26 AM UTC

edwinwee wrote: post #133

robinjfisher wrote: post #82

Earlier quoted context omitted.

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 + transac…

> you need customers to re-enter card details :scream: We can work directly with your previous payments provider to import card details directly, which helps take the burden off when migrating (and keep things PCI-compliant ;) ).

If I'd known that...

Didn't occur to me to even ask :)

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

#192

Post by sidcool » Thu, Aug 03, 2017, 8:47 AM UTC

eggbrain wrote: post #2

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 co…

I would guess hacker news audience would know it.

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

#193

Post by A1phab3t » Tue, Aug 08, 2017, 7:39 PM UTC

eggbrain wrote: post #2

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 co…

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.

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

#194

Post by Leigho_11 » Wed, Aug 09, 2017, 4:06 PM UTC

The article is inspiring at first glance but could cause a new programmer to overlook effort and possible expenses associated with building such a website. For instance, if the programmer has either front- end or back- end programming skills but not both they will need to hire someone to build half of the program. Still, lacking one or both skills they would need to have an engineer or coder available to manage any potential bugs in the program and field user requests.

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

#195

Post by amichal » Wed, Aug 09, 2017, 4:50 PM UTC

edwinwee wrote: post #130

amichal wrote: post #123

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 m…

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 edwin@stripe.com?

The complexity was more in our customers application logic then in Stripe. Stripe understandably enforces quite a few sensible limits that 'normal' usage probably wouldn't hit. For us the 2 biggies were:

* There is a (undocumented?) limit of 25 subscriptions per customer. Our client sells a la carte services and some large customers have quite a bit more then 25 things. Subscription items partially solve this EXCEPT everything in a subscription must bill on the same-cycle and...

* Our client had a requirement to maintain the existing billing cycles for all customers (and enforce specific start dates for new subscription).

These two limits meant we had to bundle existing services into Subscriptions during the migration and use the "trial period" feature (as a "start_date") to force the billing cycle for each bundle. The worst case customer had I believe 18 different billing cycles for their services in the end so we got lucky. (we also had to figure out a way to name the bundles in the UI and the CC statement descriptor etc).

In the end this saves on transaction fees and reduces the clutter on their CC statements but cost quite a bit of development effort to do and makes the code managing "subscription" starts and stops a bit complex.