(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!
I work at an HR/Payroll company with a phenomenal app that we put our blood, sweat, and tears into every single day. And every single day I clock in with Oracle Time and Labor. There's a legal reason for this and we do it for compliance. I'm guessing Stripe is in the same boat with this product despite its flaws.
When dogfooding, you have to be very careful that you don't end up in a bubble and only see your own needs as the priority.
There's a propensity for developers to start using their own products then changing it to suit themselves thinking that the regular users use the same product the same way. You end up with this mismatch of expectations and it can even get so bad that the developers don't believe the users who tell them that things need to change.
That gets repeated a lot but I have observed the opposite when you have a diversified company dogfooding an internal product that isn't strategic in their portfolio, or is targeted at a market segment that the company doesn't belong to. I have seen companies hamstring themselves by using a product that isn't the best offering for them or a poor technical fit, only because it is their own offering. Also, in the worst case, companies become develop tunnel vision in the market, because they don't regularly use the competition.
If you have a large, international software company targeting small to medium business customers in the US, dogfooding would be counterproductive. It would probably harm their strategic customer base by overcomplicating their product with features they don't need at the same time it slows the parent company down by using a product that's poor fit.
The idea behind dogfooding is that you get more/better feedback and more internal pressure to fix problems.
But the product team should already be getting feedback from a diverse set of customers. And if they're not, that's what needs to be fixed.
Dogfooding can also result in overprioritizing only your own company's product needs, and at worst the ultra specific issues that one particularly vocal VP is having, to the detriment of the overall customer base. (I've seen it happen way too many times.)
Companies should use the best tools for the job, not necessarily the ones they make themselves. If those are the same, then great. If not, then also great.
Maybe alternate between the leading product and your own so you can experience the same pain users do when they are forced to use the inferior choice after becoming accustomed to best-in-class.
Google has invested heavily in sound management in their rooms, and issued noise cancelling headphones to everyone awhile back they got to take home. That might explain some things.
But isn't Google Meet's background noise cancellation far superior to that of Zoom's? Or maybe I misunderstood your comment.
EDIT: I see above that others have claimed the opposite, but my experience has been different. I simply cannot take a call from a cafe in Zoom without complaints, but Meets is regularly tolerable, according to those I meet with.
If you use Zoom & Google Meet in the browser, the audio processing is likely pretty much the same (most of the filtering is built-in to the WebRTC stack). Zoom's native app has noticeably worse audio, but pretty much everything about it is worse anyway — it's just a pity you have to click through the "download the app" dark pattern to get to their better browser experience.
It makes sense to me - if Twilio undergoes a massive outage, do you want them to be unable to communicate as they try to fix it? So they use Zoom and Slack.
That can also work - but backups that aren't used can atrophy - and market segments could mean that what "works" for the company isn't what the company is selling.
It might be a goal to move everything internal (I believe Google is now using Google Apps internally, but they didn't for awhile, even after other businesses were).
However, I find it can get tiresome / has potential compilations.
Customer's can be terrible with incomplete, bad idea, and nonsensical requests. But sometimes internally you get the worst "Someone spilled some words into email that don't sense / no you don't actually want that / bro this is accounting software not Photoshop." situations that folks who are more familiar with the origination might make, but customer's might not make.
It takes an extra level of internal discipline to deal with dogfooding side effects at times IMO. Still, a good idea none the less.
A salesperson that I worked closely with like to use: “Drinking our own champagne.” I liked it enough I started using it though the engineer in me tends to be fine with “dogfooding”.
Oscar is the same. They no longer offer Oscar insurance to their employees. It's a liability to mandate that your coworkers information is stored in Production and accessed by Client Services.
The company where I work disallows us from using our own product because it would be considered a conflict of interest. Some co-workers say it's a federal regulation, but I've never seen that anywhere in print, so I suspect it's just a workplace rumor/justification.
I've had customers complain to my face that we tailor the products to our needs, and are surprised (and sometimes vocally disbelieve) that we don't use it, ourselves.
In certain industries, dogfooding is considered bad, and sometimes illegal.
Yeah most of the time I hear conflict of interest I don’t believe it at this point. Conflict of whose interest? If you used your own product wouldn’t you learn some issues that exist within it?
> If you used your own product wouldn’t you learn some issues that exist within it?
Isn't that the worry? Say a bug in your timekeeping software underreported hours worked and that lead to workers not being paid their agreed upon rate. When it goes to court you now have to prove that you didn't maliciously introduce the bug to save on employment costs, whereas if it is a third-party providing the software it's their problem. "Conflict of interest" is ultimately just another way to say "I don't want to assume the liability when things go sour". Nobody cares about conflict of interest when things go right.
>"Conflict of interest" is ultimately just another way to say "I don't want to assume the liability when things go sour".
No, it's not.
It's "malice is not a reasonable explanation for things going wrong". It only changes liability when it follows malice, what is much rarer than you seem to think.
It is also a way to assure people that you won't do something bad.
I'm not familiar with that definition. On the other hand, the Department of Defense explicitly says it happens "if the particular matter will have a direct and predictable effect on that interest". Predictable being "a real, as opposed to speculative possibility, that the matter will affect the financial interest".
The topic is centred around off-hand remarks made by someone as to why they aren't doing something (such as using their own product) and how, as pointed out by willio58, "conflict of interest" is used where there is no actual demonstration of conflict of interest. We're not talking about military rigor, as interesting as that subject may also be.
Again, "conflict of interest" is what people often say when they don't know if it will affect them, but don't want to take the risk. "Regulation requires it", as illustrated in the first comment, is what people say when caselaw actually demonstrates that they would be liable.
The fun thing about language is that it is fluid and can take many forms.
I'm working on the iOS/WatchOS app(s) for a major bank, and fortunately of course most of our staff uses it; too - because of course we bank with the bank we work for. (There's tangible benefits to a staff account, even those who have accounts elsewhere I'm willing to bet still do their primary banking with us.)
I've actually had an instance or two over my four years there where I discovered a bug in our PROD/App Store version myself; simply from using the software enough.
It's really unfortunate that this isn't the case for a lot of dev shops. Dogfooding is incredibly important to QA.
If the system happened to break in a way that was opportune for the employer but ripped off the employee, it's better to point fingers at Oracle than your own company.
The risk is the appearance that the company was deliberately ripping off employees. When the employer has created their own labor tracking software, it's easier for mistakes to look deliberate.
Maybe not a legal reason per se, but even if you have production data access appropriately locked down there will be some people who hold the keys to the kingdom. There's a lot more risk of people peeking at things they aren't supposed to when the data in question is about their own company, friends, coworkers.
First off, yes, Stripe uses Stripe to bill our own customers. In fact, for our larger customers who have negotiated complex pricing plans, we're currently migrating much of our manual billing to a system that's inspired by Stripe Billing.
Second, this article seems to miss the point of Stripe. It seems to want to build a platform, which is what Stripe Connect is designed for.
Slack, Atlassian, and Notion have all built their B2B billing on top of Stripe. But we don't target just B2B or B2C ecommerce in case a business has multiple revenue streams (which many businesses are increasingly adding). In fact, we designed Billing so it can flex across any business model—per-seat, usage-based, tiered, or even graduated.
This is the point of Stripe. A single stack that flexes with your business as it grows and pricing that's public.
> First off, yes, Stripe uses Stripe to bill our own customers.
This is confusing because you’re implying that Stripe Billing is used internally but another employee clarifies and says it’s not, it’s simply another billing service was created that predates Stripe Billing.
Sorry, to be clearer—we are moving away from the old billing service my colleague mentioned and to a new one. Our new system shares similarites with the Stripe Connect + Stripe Billing flow I mention above (specifically https://stripe.com/docs/api/usage_records).
You say it shares similarities with Stripe Billing. Above, you say inspired by Stripe Billing. "Similarities" and "inspired" are weasly ways of saying that it is not Stripe Billing.
It used to be that Stripe could be relied on not to do this sort of corporate doubletalk. The OP asked a direct question and you've given a misleading PR answer.
I'm sure you're a nice person just trying to do your job, but your inevitable PR posts to HN, within minutes of anything Stripe-related coming up, are hurting your cause. The Stripe of the past would never have spewed propaganda like "This is the point of Stripe. A single stack that flexes with your business as it grows and pricing that's public" into HN threads. It's embarrassing, and what it's telling us is that culturally you've lost your way.
Maybe that's inevitable on your way to world domination, but if you guys can no longer communicate honestly or treat readers as intelligent, you'd be better off not posting here. I like Stripe, by the way. I know this is harsh but I would like it to be helpful.
no bad intention - I am not sure when was the turning point but you appearing on a Stripe thread now seems like a negative signal recently, for me at least
I would be shocked to learn you’re using stripe billing and checkout sessions successfully internally - those products are so convoluted in how they overlap and don’t as to be unusable. All but the most basic use cases are a nightmare to both implement and then track rev Rec on. So much so that you’ve got a whole new product dedicated to trying to figure it out. If that were the result of a dog-fooded product I’d be pretty sad to hear it.
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.
In Xero you've got something called a "Xero Network ID", which is an ID that you can give to other Xero users and they can link it to your contact record on their account, which means that invoices they raise are automatically posted in your Xero account without you having to lift a finger.
Now, you would have thought that Xero would do the same for their subscription invoices (i.e. automatically post them to your Xero account).
But no.....
Instead they send you one by email which you then have to post manually onto your Xero account. And they do that every ... single ... month.
If you ask them "why ?", you get an arrogant reply that along the lines of "we're too big to use Xero, so go away you silly little person".
But that doesn't answer the question. Xero is their dogfood. So even if they use Sage or whatever internally, surely it is not that difficult for them to build an integration so they can post their damn invoices to the customer's accounts.
Slightly off-topic, IMO Xero has really gone downhill. The Yodlee integrations with banks fail so often these days, it makes it hard to use the product at all. When you refresh a bank/credit card feed or log in for the xth time, you have no expected timeline as to when the feed will update or whether it will even work. There are multiple buttons to reset a feed, and they do different things.
It's nearly impossible to just log in and reconcile all your accounts because you are always fighting with unconnected bank feeds. This degrades the core value prop of making it easy to stay atop of bookkeeping—now I always have some form of "accounting debt" these days.
I got so frustrated that I am in the process of migrating my personal account to Tiller + Google Sheets, and I'm still looking for a solution for our small business account.
I agree about the billing issues; I waste time figuring out where the invoices live in the product and manually posting them. Otherwise, the product would be fine if outdated, if it wasn't for the unreliability of Yodlee.
> I'm still looking for a solution for our small business account.
For a long time I resisted moving to Xero.
Unfortunately my hand was forced because my existing solution (MYOB which was then bought by Mamut) stopped being Apple compatible through their own lazyness (they refused to update the software for 64-bit compatability).
Apple had pre-announced the post-Catalina 64-bit requirement years in advance. Every other developer out there had made the change. But Mamut/MYOB ... nope, they sent out a long email one day basically making that absolutely clear they were not moving from 32-bit.
Their answer was to offer a "cloud" version. I say "cloud" because what they offered was a remote desktop connection to a Mac running an old version of software on their side.
So hence I was forced over to Xero. My accountant was pressuring me too, but Mamut/MYOB killing off their own product was the straw that broke the camels back.
(I believe they may have finally relented and brought out a 64-bit version subsequently, but by that time it was too late, I'd moved already. And I had lost trust in their software support abilities anyway by then).
Consistent with my own experience with MYOB. Product managers coasting on market share and stalling on mandatory changes, even when their competitors sitting next to them in the room have done it and moved on.
It’s really unclear what everyone at Xero does these days. Their main product development seems to be keeping up STP compliance, and trying to move add-ons onto their new App Store. I haven’t seen an exciting new feature in a long time. (Their business development team, by contrast, seems pretty busy.)
Fairly sure Xero use NetSuite (or did- maybe they've since moved) and apparently went to great lengths at the time to make the invoice look like it was generated from Xero.
Whenever I hear about a US based payment processor, I feel compelled to mention UPI, India's Unified Payment Interface.
Basically, with fairly modest investment, the Indian government put together a system to allow instant transactions between bank accounts. There are no transaction fees.
We have so many companies (sometimes the same company with multiple faces - Paypal/Venmo, Stripe, Clover, Square, all of whom want a cut of transactions for the incredible service of making a number go up in one place and down in another place. Instead of fixing bank-to-bank transfers, we're stuck with ACH, which for some godforsaken reason takes days to clear.
There's no technical reason why the US can't have a system like UPI. There's no reason why we MUST allow rent-seeking payment processors to take a cut when someone in Mumbai can make a peer or merchant transfer for free in seconds.
You're ignoring history and momentum. (I am likely wrong on some parts of the below). Credit cards have been present in the United States for a century (I believe originating as store credit), within becoming ubiquitous after the mag strip was invented in the 1970s, and really starting to replace checks and cash in the '80s and '90s. Because of this, the US had a very large infrastructure and consumer momentum to continue to use credit cards. Adopting another system requires banks and merchants to all agree on such the system. Without government intervention, that's pretty hard.
Many nations didn't have such systems in place, so they were prime to have their own technology be brought forward. That's why WePay was able to spread in China.
The other huge factor here is that forcing things on companies in the US is extremely difficult. Our constitution and laws make it a lot more difficult for the government to force certain behavior on private businesses. Along with the cultural idea of free enterprise, people don't like the government making decisions for them on how a business should be run.
In India, the Bank of India and the government was able to force UPI down everyone's throat, and companies have no choice on the matter.
I think the U.S. federal government is working on a payment system. At first it will just work between banks. I dunno if that means consumers can use it between their banks or if it means B2B bank transactions, but they are working on something (and I recall it’s close).
Edit: FedNow, May 2023, pricing not yet released. It is for business and consumers
> There's no technical reason why the US can't have a system like UPI.
You're right there is no technical reason, but there is a very strong political reason.
They way things are now, people in the US have to pay for a lot of things that people don't pay for in other countries. Bank Transfers is just one example. Health Insurance (and care) is another. Higher education. Filing taxes. This list is endless.
Making people pay for this stuff is extremely good for the economy, and probably a big part of the reason the USA has the highest GDP.
It also makes many, many hundreds of billions of dollars for those entrenched in those industries, who will spend tens upon tens of billions of dollars lobbying to make sure it never changes.
Seems very understandable to me that your customers' profile doesn't necessarily meet your customers' customers profile.
If I sell a cash register app to indie businesses who sell trinkets at the art fair, that doesn't mean my solution meets my own needs for billing my millions of those business customers.
Several of the concerns revolve around the complexity of managing multiple IDs (product SKUs, prices, etc) for a single subscription - and the author reaches the conclusion that this is because it's optimized for "e-commerce and not B2B SaaS".
While from the buyer's perspective, "single negotiated cost with overages" may appear simple - it's a single bill after all - on the accounting side for the company selling the product, I'd expect it's much more complicated; with potentially different tax rates for different products and complexity around producing an auditor-defensible determination for "cost of goods sold" and "marketing expense."
So for at least some of these requests, I see Stripe's posture here as helpful - it's not "requesting a dollar figure", it's "creating a detailed enough accounting trail behind that bill to operate your business." Looking across the breadth of Stripe's products, I'd give them the benefit of the doubt here.
This isn't as much of a gotcha as they think it is. Amazon was using Oracle databases until like 2019, 13 years after the launch of AWS. Same with pretty much every large company that has a mature hand-crafted tech stack in place. Sometimes the costs and complexity of migration are simply not enough to justify switching, even if the target product is your own.
If I were a regulator I would be suspicious if a company runs its own billing on its own billing software and then something goes wrong with the numbers. Keeps honest executives honest in a way. Also keeps outages and hacker attack vectors somewhat contained.
Thanks! we're working on this, the point is: the problem occur for a small portion of visitors, and we're iterating to reproduce that. Thanks again for the feedback!
As the old men say at the park, there comes a moment in every SaaS's life where you need to spend a year of a team's time just adding Zuora. They are dark days but hopefully life is better on the other side.
Interesting that one YC company publicly attacks another YC company. I thought there's at least some "family" vibes there, instead of bitching each other now.
Hi! I work at Lago. As we wrote in the disclaimer of the article, we're just stating how our positioning is different, extract here:
"We were told recently: “We love your ‘Stripe hate’ content”. While it was intended as a compliment, ‘Stripe hate’ has never been our intention.
We partner with Stripe Payments and love their products. Our own product is an alternative to Stripe Billing (and Chargebee, Recurly, etc.) but with a deep focus on B2B and product-led companies. We actually have common investors on our cap table (e.g. Y Combinator and others)."
What I'm interesting in is a front end where the underlying payment provider can quickly be replaced when Stripe/PayPal etc cancel you (for any reason at all).
This article comes at a welcome time for me. I've been building out a usage-based B2B product and have wracked my brain on how to properly implement billing (without having to pay large upfront fees or integrate a more complex gateway that I don't really need).
I'd never heard of Lago before but I think I'll give it a try.
I use Stripe for other products, and their usage-based billing is limited to specific scenarios that are not one-size fits all. This is in fact the entire subject of the post we are commenting on.
Why would you assume I haven't evaluated Stripe's offering on a post that is specifically about the shortcomings of Stripe's offering.
The only damning evidence we need is quantum physic gotchas + uncertainty principle + matter/wave dualism which happen because the simulator does not have enough precision, performance or memory to fully simulate the reality within it operates and needs to cut corners. But maybe this simulation IS reality and reality is simply limited in its precision, performance and storage.
To call the uncertainty principle a precision limitation on measurement is something of an oversimplification.
Passing from the general physicist's uncertainty principle to a more restricted but still physically meaningful case, the Fourier-transform version of the uncertainty principle (requires no physics to derive and) states that the narrower and less smooth a spatial representation of something is, the wider and slower-decaying its frequency representation becomes. (Sharp and abrupt sounds have wide spectra, which is why they get mangled into the strange but recognizable bubbling in low-bitrate MP3s. The two-dimensional case of the same phenomenon is well demonstrated by the JPEG "ringing" around sharp edges, with the caveat that JPEG transforms every 16x16 block of pixels independently.) Physics comes in here only when you say that position and momentum (amplitude) distributions are Fourier transforms of each other.
If a single sample or the average value is all you get, then yes, the width of the peak becomes the uncertainty of your measurement. If you can get many samples, though, then you absolutely can trace the shape of that peak. It's just that the instruments used at the dawn of quantum mechanics were not built that way.
(What "particle-wave dualism" means, I think nobody really understands except maybe Bohr scholars; "dualism" was his personal German-philosophy-style all-encompassing idea that he was smitten with before he even started thinking about QM. It's a wave, period, it's just that high-frequency waves can look like particle propagation if you squint, as seen in optics and acoustics.)
> It's a wave, period, it's just that high-frequency waves can look like particle propagation if you squint, as seen in optics and acoustics
Based on the normal definitions of particle and wave, and based on things like the double-slit experiment, I think we'd have to conclude the behavior is closer to "neither" than to "wave".
If you define "wave" based on quantum behavior, then you're really just begging the question of what to call it.
Stripe Billing came after Stripe, by years, and it's intended for a different purpose anyways. Stripe doesn't bill me; they take a cut of what I bill my customers. That's a very different model than Stripe Billing is for.
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.