We’re always working on making Checkout and Billing gel together better, and our Revenue Recognition product automates ASC606-compliant accrual revenue reporting including automatically recognizing data from Stripe Billing. Have you talked to us yet about your use-case? Could you email me at ark@stripe.com?
I appreciate the offer. We are very much working closely with you on implementation and have from the start (over 6 years spanning many of your products). I am very familiar with all of your offerings.
The core of stripe is great, we’re fans. But as you add any complexity you end up with a mess of various internal account balances to maintain. It forces you into gross things like bin packing refunds, complex internal transfer fail handling. Toss in the inconsistent handling across connect and man, you’d be better off just going back to basic charges and ignoring all the value adds.
(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... 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.
So, 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.
Just personally, I value companies who "dogfood" their products a lot more than similar companies that don't.
An example is 3D printers. Prusa makes fantastic 3D printers, and about half of the structural parts for their printers are printed on their own printers. So they have 600 of their own 3D printers printing 24/7 printing their own parts. That means they are forced to address long-term durability and reliability issues even just to ship their own product.
Because it absolutely is true that at that scale, you're usually better off just injection molding the parts, but they'd lose the high-quality signaling that yeah, their 3D printers are good enough for the company to rely on them to print their product. They also lose out on insight to things they could do to improve their own product from a usability standpoint.
I shuddered a bit when i heard that some GCP services are just external wrappers over internal systems. Feels like a bad setup for everyone involved: customers, wrapper owners and internal system owners.
Was mentioned in an onsite interview i had with them a few years back. Maybe i misunderstood but it seemed that internal teams didn't integrate with the same API as external customers. Not sure the other reply means that the "wrapper" doesn't exist or the wrapper's are just named the same as the underlying service or i just misunderstood the point.
My impression (I work at Google) is that internal interfaces to some of these services have a lot of Google-specific stuff that are hard to map to non-Google requirements.
> but migrating from SAP would cost them millions and take a lot of time.
Microsoft's annual revenue is almost US$200 billion. Even if the migration would "cost them millions", they can easily afford it, it would not make any material difference to their ultimate financial position. And, it would actually be justifiable as an investment in their own ERP suite – "eating their own dogfood" would send a signal to their customers about their commitment to those products, and would also help improve those products over time (by exposing them to the distinctive needs of a Microsoft-scale enterprise). As far as time goes, they could always do it gradually (maybe they already are), and even if it takes several years, before we know it those years will be behind us.
I don't think people should be down voting you for this comment, but I imagine the reason why is because that's generally not how things work at large companies. Someone in product and/or sales might have made the same argument you have, but in my experience the business response to that argument is something along the line of "you can quantify the cost, but you can't quantify the value (i.e. sales upside) and there's no change in business capability? No." Revenue doesn't come into it... money is money. Or perhaps more correctly, value is value.
I used to work for Oracle. I can recall Oracle sales reps telling me how important it was that we internally used the software we sold to our customers, because if we didn't trust it with our own business, why should they trust it with theirs? Maybe Microsoft doesn't think the same way?
Of course, Oracle has so many different software offerings (duplication due to acquisitions, and lots of industry-specific offerings), it couldn't possibly use them all internally. But at least its sales reps could say, that if they weren't using the specific product they were selling, they'd be (for non-industry specific functions) using an equivalent product in Oracle's portfolio.
Agreed, it's definitely not one size fits all. The story of Amazon migrating off Oracle is probably in the same ballpark (if that story is true - I don't know one way or the other). To which point, again... it's a totally valid perspective that you have!
> Amazon’s Consumer business just turned off its final Oracle database (some third-party applications are tightly bound to Oracle and were not migrated).
No idea what those “third-party applications” are and how significant they are - they could be insignificant fringes or extremely core business systems (such as payroll or general ledger)
If they can't justify the value of their products compared to their competitors internally, how would they ever convince others it's worth it to switch to their product? I mean, it's practically an acknowledgement it's not worth it to switch to their product, because the value really isn't there.
Sometimes decision are not reflection of the merits of the individual options, but of the fundamentals of the challenge. Changing a business platform is an incredibly invasive/disruptive move, with huge costs (money and opportunity) and meager gains. Does not mean that say, Dynamics, is not any good.
It’s a major distraction even if they have money and resources. I am a CFO who has purchased/integrated multiple products from SAP/Oracle/etc (different companies). I’ve never once factored into my purchasing decisions whether they were dogfooding or not. If I was told they were dogfooding, I’d have placed zero value on that. That’s just me though.
Oracle’s own marketing has repeatedly used variations of the slogan “Oracle on Oracle”, to highlight various instances of Oracle moving internal business function X to run on Oracle product Y. [0] I don’t think it has ever been their primary message, just one among many, but it’s been there. Obviously it doesn’t make any impact on some customers, such as yourself. On the other hand, it must work sometimes, or else they surely would have dropped it.
Right, but, don’t they want to sell their product against SAP? They would learn so much and then be dogfooding. I’m not surprised Microsoft hasn’t done this, because Microsoft. Microsoft doesn’t build products for users it builds products for its program managers.
I am sure a company like Microsoft has quite a few unique needs. So just getting everything implemented to even be in a position to dogfood would take away development time which could be better invested to improve the experience for paying or potential customers.
The departments are also not the same, the developers might be happy to have a customer like Microsoft but the hundreds of people using something else today really don't gain anything. They would have to retrain and take on a huge migration. And for a system that has grown for such a long time you can be sure that there are a lot of undocumented edge cases for weird business needs.
Smaller companies have burned millions trying to move off SAP. And there is nothing Microsoft can do or learn to make the migration to their product easier because it's all business problems, not so much technology. Their potential future customers aren't billion dollar companies which are on SAP today.
They didn't say "simple", they said "simpler". If we are talking relative complexity between SAP/Dynamics and Stripe Billing, yeah, billing is "simpler".
Stripe'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.
If 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.
Thanks 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.
Yeah, 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.
I 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.
We 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?
Yes, 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.
Shameless plug, but at www.salesbricks.com we separate out billing schedule and contract terms. We also handle complex deal structures, upgrades and renewals!
If you rent a home, you pay monthly despite the contact lasting a year or longer. If are employed you probably get paid monthly, even with a fixed contract duration of 6 months or a year.
Auto-renewing yearly contracts, on the other hand, are definitely a dark pattern. Luckily many places are outlawing it, so as an alternative a 12-month contract will often automatically convert to a monthly one at the end.
(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.
Thanks! 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!
I’m Raffi from Lago. Frankly, Stripe is a awesome company. They’ve built amazing products, including Stripe Payments (the blog post starts with this exact same statement). When it comes to billing, we do believe we are creating a better solution, especially for companies having complex billing (usage based, for instance). At least, we offer a new solution to prevent additional % fees on revenue, vendor lock-in and rigid billing solution by creating the tool we would have loved to use.
We do not bark up the wrong tree, but try to give our point of view about the perfect billing system
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.
why 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
Stripe 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.
Interested 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!
(Engineering Manager at Stripe Billing) Ah - sorry about that, a last minute fix caused a bug. This is now fixed in production. Thank you so much for reporting!
