9 ms·
(I work on Stripe Billing). This is a question we raise fairly regularly internally at Stripe. The real, prosaic answer is because when we started working on S
by kurrik 4y ago
(I work on Stripe Billing). This is a question we raise fairly regularly internally at Stripe. The real, prosaic answer is because when we started working on Stripe Billing in 2017, Stripe had already built an internal billing system to bill its own customers. Stripe was 7 years old at that point.
At the time, we got lots of feedback from the folks who had built that system. Our goal was to build a flexible billing system for all kinds of companies at different sizes, but we were definitely focused on smaller (doing maybe $100k–$10M of ARR) SaaS companies to start. We've come a long way since then and now power billing for a number of large/public companies. Atlassian, Figma, Notion and Slack are either using or migrating onto Stripe Billing today.
Stripe Billing is a powerful tool with a role to play in any company's revenue management system, including Stripe's. Newer Stripe products (such as Atlas) do build on top of Stripe Billing but we haven't gotten around to migrating our existing stack. That said, I do have a personal goal of taking on more internal billing responsibilities over time (e.g. I think we could easily use Stripe Invoices internally today, and it's mostly opportunity cost keeping us from actually doing so).
I do want to say that the specific use case covered in the post is something we have thought about a lot. I think about it as a pipeline with stages for collecting high volumes of usage events, aggregating them, mapping them to rate cards based on usage, and then producing recurring bills, collecting payment, dunning, etc... The post claims we don’t do a good job on the first two stages (collecting usage events and aggregating them) is perhaps missing that the style of percentage-based fees is a one-line addition to a Connect integration as my colleague edwinwee mentioned below. It is also possible to have a scalable usage event collection/aggregation pipeline integrated with Stripe Billing. You can read this AWS blog post https://aws.amazon.com/blogs/apn/building-a-third-party-saas-metering-and-billing-integration-on-aws/ https://aws.amazon.com/blogs/apn/building-a-third-party-saas... for information about how to build such a system according to our best practices.
While I’m here, I’m always eager to hear feedback on Stripe Billing from folks who are using it. My email is ark@stripe.com.
- deleted 4y ago[deleted]
- neosat 4y agoThanks for some internal insights. I think the original post wasn't making the point that such a use case is not possible to build but rather that the architecture and design choices of Stripe Billing are not optimized for these use cases and don't make it easy.
- AlecSchueler 4y agoI loved the answer but it's a good point to raise in return, what makes migration to internal billing so unappetising for the teams at Stripe?
- longboardcat 4y agoHopefully because there's an actual business to be building.
- AlecSchueler 4y agoYeah, that's what I figured too as I was asking that. Focus on the product first. In a way it's actually a plus point that they haven't migrated, as it shows they're clearly focused on building.
- kurrik 4y agoI wouldn't say it's unappetizing for us. Even contemplating the possibility offers us insight about what companies the size and complexity of Stripe need to go through in order to migrate Billing systems. e.g. back of house processes for revenue reconciliation and recognition need to work across both systems, we need to support bulk migrations of data, both systems need to recognize the "canonical biller" for a customer so that you avoid double-billing issues, you need to backfill invoices and ensure no gaps in numbering, product teams need to update their integration and provisioning code and so on. My observation is that large companies can spend 10s-100s of engineers on the order of several quarters or years to do this kind of migration safely. We've made several internal and a few external changes over the years to help our users with these kinds of issues and in my estimation we've been getting closer to making the commitment, but as of right now we haven't done a stop-the-world effort to change systems internally.
- cutenewt 4y agoLago is really gunning for Stripe Billing. Is Lago barking up the wrong tree? Or is there really an untapped opportunity here?
- theturtletalks 4y agoIf Lago builds a billing UI and API that can connect to Stripe Billing, Paddle, Authorize.net, PayPal, etc. then that is a huge opportunity.
- swyx 4y agowhy exactly? is this just some form of xkcd-style "there were too many APIs so i built a superAPI" line of thinking? or is there something more fundamental about this problem you are referring to
- AnhTho_FR 4y agoInterested in the answer too! Maybe you meant being a 'metering x billing layer' that can easily connect to any PSP, unlike 'Stripe Billing' that is only usable with 'Stripe Payments'?). In that case, we'd connect to 'Stripe Payments' (not Stripe Billing), which we already do :) Genuinely looking forward to your thoughts!
- theturtletalks 4y agoStripe Billing is not fully internationally available so a lot of software companies are opting for Paddle. A super API would allow users to easily switch between billing platforms and avoid lock-in. The other reason is that Stripe Billing is stupidly good. So good in fact, that they could raise they rates from 0.5% to 1-1.5% and most people would pay up since migration would cause downtime and man-hours. I use Stripe Billing now, but could integrate with Lago once and easily switch between payment processors.
- AnhTho_FR 4y agoHi! I work at Lago. Billing is still a huge nightmare for engineers, this is what we're going after -> https://news.ycombinator.com/item?id=31424450 https://news.ycombinator.com/item?id=31424450 We've built and scaled it internally in a 5x Fintech Unicorn before joining YC, we would have loved to use an off the shelf solution, but none of them were a fit.
- rtanks 4y agoThis is great information. Thanks!
- Biganon 4y agoSo, same reason why Microsoft uses SAP instead of Microsoft Dynamics. They would use their own product if they were to start now, but migrating from SAP would cost them millions and take a lot of time.
- thunky 4y agoBilling seems much simpler though. If this comparison is apt, it's not a great look for Stripe.
- AmericanChopper 4y agoI can’t imagine somebody who’s implemented a billing system before ever making the claim that billing systems are simple.
- lsaferite 4y agoThey didn't say "simple", they said "simpler". If we are talking relative complexity between SAP/Dynamics and Stripe Billing, yeah, billing is "simpler".
- matai_kolila 4y agoNothing is a good look for anyone once you see how the sausage actually gets made, in my experience.
- awad 4y agoStripe's own claim to fame and much success is making an exceptionally complex topic, like billing, seem simple. It never is. I would imagine most of their own customers have far simpler needs than they themselves do. FWIW, we're happy Stripe customers, but also candidly do much of our billing outside of of them. Some of the examples GP cited are in a similar boat. Which is all to say that Stripe solves a lot of headaches, but it hasn't solved all of them. I'm sure investors in Stripe see that as a positive opportunity.
- kdtsh 4y agoIf you could wipe out the past and start from day dot then /maybe/ you could transition without too great a risk; even then, you’re looking at a massive transformation project with a lot of temporary contract workers. It’s expensive, because billing fundamentally touches every part of a business - if it breaks, you can’t pay your service providers and you can’t get paid by your clients. Optics doesn’t matter here, dogfooding is a nice bonus and not a given. There’s just no compelling reason for them to move over.
- joshpadnick 4y agoWe use Stripe Billing and it's gone very well overall, but the biggest miss for us is that Stripe conflates "contract term" with "billing frequency." We sign up customers for annual contracts but bill them monthly, but Stripe Billing only understands the "bill monthly" part of that. Are there any plans for first-class contract term support coming?
- anamexis 4y agoYou could use subscription schedules to end the subscription after 12 months. https://stripe.com/docs/billing/subscriptions/subscription-schedules https://stripe.com/docs/billing/subscriptions/subscription-s...
- joshpadnick 4y agoYep, tried that. But we want an auto-renewing contract of 12 months, and subscription terms require you to have an end date.
- kurrik 4y agoYes, this is definitely a use case we've been working on. If you'd be willing to email me any more details about how you need things to work at ark@stripe.com I'll make sure the feedback makes it to the people working on it.
- WanderPanda 4y agoThis is one of the darkest dark patterns I'm glad they don't allow it
- joshpadnick 4y ago(This is my second feature request on this thread; apologies for any noise.) Stripe Billing helpfully allows you to set the original subscription start date to a past date, but only at subscription creation time. If we could modify the subscription start date, then Stripe could be authoritative for when 100% of our subscriptions actually started.
- kurrik 4y agoThanks! I'm curious about your use case and specifics about how you're looking at start date and how often you'd expect to update it (i.e. is this a one-time cleanup or a regular thing?). I'd welcome an email with some details!
- AnhTho_FR 4y agoHey Ark, I work at Lago, thanks for the detailed answer!
- Liron 4y agoLove these Stripe HN answers. Seems no other big company has this ability to go on HN and answer a question.