We don't bill much with Stripe but have been using it for a very long time. At this point i have to say that Stripe is just extracting it's tax. Anything you do on Stripe is taxed. If you want to get an invoice paid that is charged 0.4% and then you have to pay $2 just to generate an invoice to provide proof of transaction to your customer. And then recurring billing charges went up to 0.7% (from 0.5%) without any reason. (recurring billing charges are over and above the base fee).
For my current project, I pay nearly 5-7% on each transaction to Stripe.
For my next project, I'm implementing custom billing and using Stripe just as a payment processor.
i don't use a 3rd party billing solution. I straight up created my own.
If you have a single type of pricing(eg, variable, or tiered) its very easy rolling your own.
The issues happen when you change from variable to tiered(or vice versa), change from anniversary to calendary dates, add coupons, per user custom pricing, credits, etc etc.
I don't recommend building your own if you aren't familiar with Stripe or any other billing system. Once you understand how billing works, feel free to make a custom billing solution.
You are right! The issues usually happen when you add more complexity (tiers, discounts, credit notes, coupons, prepaid credits). Also, what I find very tough is that this is not a « one stop shop »: every single company has it’s own definition of what should be included or excluded from the MRR. I am pretty sure you never end up on an universal definition
Paddle is pretty bad.
Support is bad in general, the API is bad, you never win a chargeback (you still have to worry about chargebacks). I wanted to try lemonsqueezy but now it's been acquired by stripe, so it will likely turn into another expensive Death Star.
MoR solutions are a good idea; the tax (F*K VATMOSS Europe) / accounting overhead is likely not worth it. Having a single B2B transaction whenever you want is much easier to deal with.
When your income is large enough that the % you'd be saving let you afford developer time to implement and maintain taxes / billing and extra for accounting of thousands of transactions, then go for it and switch to a cheaper solution.
Let's say you make 100k per year: the 2-3k you save on pure stripe won't pay for the extra developer / accounting time to maintain all that.
Currently we use a processor agnostic billing engine - sticky.io - but they were purchased by private equity and are doing private equity things. Raising prices, charging per transaction fees, etc. Plus, their software and api is downright terrible but it's what we decided on 12 years ago so here we are.
Vendor lock-in sucks. Open to payment stack suggestions.
I previously bootstrapped a business to 30M ARR and was sick of paying the "subscription tax"
We give you all the tools you need to build and run your subscription business without having to integrate a dozen different tools together and tear your hair out (and also break the bank). Feel free to reach out to us via the contact form–we're giving people on HN one year free
I don’t run any commerce sites, myself, but is there a big difference in using stripe vs a more traditional processor, like working with CardPointe or something?
I'm the founder of OpenPay (getopenpay.com) and a lot of Stripe customers migrated to us as an alternative. We give you all the functionality that Stripe provides without the "Stripe tax"
Feel free to reach out to us and we'll hook you up
That implies you're only charging a few dollars per transaction (where the $0.30 fixed cost per transaction with sticker pricing is 2-4% of the transaction). That's about $7.
It's great to want to charge only a small amount, but this is easily fixed by billing annually and allowing payments through lower-fee payment methods like ACH.
I was in your shoes when I started my business, charging $5/mo. I increased my prices to $10/mo and enabled annual billing (with a $10 discount) and saw MRR grow, both through added sales and increased retention (fewer payments means fewer opportunities for failed payments). And increased revenue on volume, since I pay less in fees.
I used to work at Stripe and I'm very familiar with the pricing. I'm simply perplexed at how you can possibly be paying them up to 7% if your payments are B2B-sized. BNPL acceptance is the only thing that even comes close to that. You'd need to load up on nearly every single metered feature (billing, Tax, chargeback protection, revenue recognition, radar for teams, etc) to pay that much with sticker pricing.
I ran into the same issues / frustrations as you when I bootstrapped my previous business to 30M ARR. I hated paying the "Stripe tax" and having vendor lock in with Stripe
Feel free to reach out to us on the website and we'll take care of you with free subscription management for a year
There are industries where billing is a service for very good reasons: Telcos have been buying entire billing packages, paying a mint for them, for decades.
The issue is whether one needs a battleship sized, super flexible, yet expensive billing solution for much smaller problems.
As a developer I’m always surprised that these issues are real.
I’m used to store raw data I receive back from payment processing in my own database as transactional events (e.g. renew, cancel, successful and failed payments ) ends up as single events.
I do the same for all application events and it is then rather easy for me to get the data as I need it for whatever KPI I want (activity, retention, usage) and for very little overhead while building products.
So I’m wondering, is this a result of all the low-/no-code stuff going on?
Often the database structure that is amenable for running the app or billing system isn't the one that is ammenable for generating a graph of historical MRR over your company's lifetime (or future expected revenue!)
And when you get into cohort analysis, it gets a bit messier. Your cohort calculations might be cheap on one user but not across your entire system.
This is often just a question of some very simple data engineering. But you get queries that are "good enough" and "basically are right". So you use them. And they get slower and slower until they take like 10 minutes to run because you're calculating historical app usage data for your bespoke cohort. And then they start taking hours. And then they're just timing out constantly. And then you start fundraising and you do "MRR/ARR vs actual money in/out", and find weird discrepencies (yes you included one-time purchases. Or did you? And your rebates done through the stripe dashboard definitely were captured in your app database right?)
Oh and of course your top sales person has been giving people discount coupons but they were doing it in Stripe instead of in your bespoke system and you weren't properly flowing the data back into your system because of webhooks and now you realize that your MRR is 5% less than it actually is (and it's been like this for 2 years so now you have lied to investors consistently for 2 years).
Nothing is really hard, but it's too easy to get a "close enough" answer and the activation energy to doing this stuff right is just high enough to where people put it off for way too long.
Partly. There is always some data you will need in the future that you don't think to store today. So I suspect MRR is not the only issue these startups are having. Another example is stripe just does not make some fields available via api. Say, the date an external account was added to a connected account. That is not in the api, so if you then want to add some logic that depends on the age of certain accounts (maybe fraud prevention), you're out of luck. You would have to handle the event when it happened, and use the current time. But Stripe does show this date on the UI.
At my previous company we used Stripe, and never saw any value in their data products. I was always curious as to why they had data products and would be interested to hear the other side – satisfied users with solved use-cases.
The reason it always seemed weird to me is that billing data is just one small portion of a company's data. We had all sorts of data about our users – preferences, demographics, data from marketing campaigns, how they browsed our site, etc, all of which was much more insightful than data about how they paid. Now we didn't have recurring subscriptions which perhaps adds a little value, but Stripe still delivers data via webhook back to your application, and companies still need to keep their application records up to date, so surely most details to compute MRR, churn, etc are already being delivered. Why would you analyse this in Stripe which doesn't have any of your other data?
If a company uses the very high-level Stripe products, and is (or almost) a no-code implementation, perhaps just a Stripe plugin in a Wordpress site, then I can sort of understand it, but what's the value for a company with any sort of custom integration or using any of the lower level products like billing?
Some businesses are large enough that polling the API and/or ingesting webhooks is a poor architectural choice or simply impossible — Sigma and the other bulk data products are extremely useful for these businesses.
The other kind of business that benefits from Sigma is much lower tech than yours, and most likely doesnt have a database or something that can accept webhooks.
Is that true? Polling the API might be too much, but I would expect Stripe to be able to handle a few GETs for every payment they take, even big companies will probably only be taking ~1-10k payments/second, doubling or tripling that isn't much. And ingesting webhooks for payment is necessary to be able to perform access control or whatever is necessary for the business to function. Conversely, $0.03 of margin to patch over bad engineering is quite a lot of margin for some types of business.
Lower tech businesses perhaps, but most of them probably aren't doing data analysis anyway.
Yes, it’s true. For a hint of some of the utility and complexity, consider backfilling historical data; or, how you’d ensure consistent views (as of time X) of historic data (all charges before time X) when each row in the dataset is mutable.
You’ve got plenty of paid options with Stripe, but here’s the catch: trying to match what you see in the Stripe dashboard with exact cent accuracy using queries is a total headache. in addition, it would be simpler to add an option to pull that data via an API call.
I consult in this space, and Sigma is one of my favorite tools. It can be useful specifically for fighting delinquent churn. One of the first things I like to check is to see if a particular card brand is declining more than others. I also like seeing the average time between the first failed payment and success. There is all sorts of data in Stripe that can help create a strategy for combating delinquent churn.
Sure you could get and store all of this data from webhooks and into the database, but most product teams don’t want to spend the time implementing this. Keep in mind it’s usually the finance/revenue team that needs this data. They’d rather pay Stripe a couple hundred/thousand dollars and get the data instantly, rather than bugging the product team only to find out the ticket got back burnered.
We had the same issue, but it was over by 10-20% in our case. Discussed this with them multiple times, and the last response I got was:
"I've checked in with our engineering teams, and we unfortunately don't yet have a fix or timeline to share here, though we have made additional progress on scoping a path forward. It's extremely complex on our end, as existing data models don't have the required information in place to make the change here, and we'd need to scope how to add that and backfill data (which we're approaching, but again, no timeline to share as of now)."
Obviously I don't know anything about them internally, but if I can export the data as a CSV-file, and then calculate the MRR myself in GSheets, then what data needs to be backfilled? The data is already available to properly calculate it.
My interpretation of backfilling here is that they need to architect the data in a different way to be able to have all the information needed to calculate the MRR correctly. Then once the data is modelled how they need it, they have to backfill the new model. Basically like your export to csv step. I'm sure the data that fills your csv export is coming in from a dozen different tables and sources.
The article is interesting, but it's not clear how Lago fixes the issue.
As far as I know, Lago starts in the low thousands per month.
If you go with the self hosted route, you might also just process Stripe's API (backfill using API or data export, use webhooks to keep it up to date). It's actually much easier than onboarding with Lago I would say.
I see no reason why one wouldn't self host this. Subscription and billing data is such a crucial part of any business, I'm surprised more don't handle it internally.
Yes! And ARR = annual recurring revenue. In addition to other saas metrics like usage revenue that is pure consumption based and sometimes calculated differently
There's no formal definition of MRR. Do you count transactions refunded as fraud after the fact? What about transactions that were partially refunded by your support team? What month do transactions that take more than one day to settle fall in? Of course that needs to be timezone-adjusted as well.
What about the case where recurring transactions fall on the 30th and 31st of each month? They'll be processed on the last day of the month, including February 28. But depending on your time zone, they might actually happen on the first of the subsequent month in _your_ time zone.
You could instead sum up recurring subscription amounts. Do you count trials? What about users who have credit or a balance on their customer object? Are you counting users whose subscription is set to expire at the end of the billing period, but who have already paid for the month?
If you ask 20 people how they should be calculating MRR, you'll probably get at least 10 different answers that produce 10 different numbers. That's why Stripe doesn't offer this as an API.
I don't think it's quite so subjective. At least, the edge cases you bring up would not significantly affect your metrics no matter how you handled them. MRR is a metric used for strategic planning and evaluation, it doesn't have to be exact, it's not going on your tax submissions.
You usually track MRR based on users who are currently paying for your service (summing recurring subscription amounts, as you put it). Whether their payment falls at the end of the month or is delayed a day to the next month doesn't affect MRR. Most subscriptions must be paid before the billing period begins.
Things like cancellations or chargebacks are counted separately and would not affect past MRR calculations. No you never count free trials. Yes, you count people who have a credit or balance assuming they overpaid to get that balance. If it was just given as a comp, then no.
Yes, you count people who are set to expire until they actually expire and don't renew.
Regardless of how you do your accounting, MRR is always an accrual basis. Someone who pays $10 monthly increases your MRR by $10. Someone else who pays $100 annually increases your MRR by $100/12.
If this is something you're struggling with... It's one of the core use-cases we're solving for at Equals (https://equals.com).
We sync your Stripe data to a data warehouse and give you an MRR by customer by day table. You can use this table in our data connected spreadsheet to report on your business.
Would equals be simple enough for a staff member with limited accounting and tech background who has been putting simple revenue, churn, product trend reports together by hand using our stripe data? If so, how can we reach out to schedule a meeting to discuss?
Sorry, just seeing this. Yes, we can definitely help. Lots of customers with a background like that. Send me a mail ben@equals.com and we can set something up.
I used to work on Sigma/ReportingDataPlatform, and all I’ll say here is that this article is wildly off base with regards to utility and cost — the DoorDash examples are laughable.
The article is correct that calculating MRR is difficult and requires access to your billing data.
I am very skeptical that working with data provided by Lago makes it any easier than working with the data you can get from Sigma or from data pipeline exports.
I don’t have a lot of love for Stripe by any means, but this is poorly argued.
> The article is correct that calculating MRR is difficult and requires access to your billing data.
Then Stripe should provide the metric as an API and precalculate it. (They already have as it powers their dashboards, it's just inaccessible via API access.)
It's extremely frustrating that external metrics dashboards report MRR as significantly higher than it actually is.
It makes me distrust and dislike Stripe that such a core figure is absent in their API. There should be zero excuse for not providing it. It's a ridiculous omission.
I've spent too much time trying to solve this and it disappoints me.
A counterpoint, from someone who’s worked on SaaS billing /MRR reporting for 10+ years - it’s usually more complicated than just exposing an API endpoint for precalculated MRR by month. Most analysis requires drilling into dimensions of MRR growth - by cohort, by billing period, etc - and so while Stripe exposing an API for MRR could be helpful, it won’t cover most of the cases for proper financial analysis for a SaaS business. There’s also the complication of how MRR is computed across companies and domains - it’s not a GAAP metric and no standardized definitions.
The question is: how can we (Lago) make it much easier (if you think it's not the case today) than working with the data from Sigma and from data pipeline exports?
I don’t think you can, which is why I criticized this blogpost for failing to demonstrate a compelling answer, and instead relying on misleading arguments based on invalid pricing assumptions.
If you think it’s easier to calculate MRR with Lago than with data derived from Sigma or the reporting data exports, I suggest showing how it’s done in each case and explaining why Lago’s schema makes it easier.
Arguing that it’s harder on Stripe because if you’re DoorDash you would have to pay a lot of money for Sigma is not honest.
I'll reach out in DM re: invalid pricing assumptions (genuinely wand to gather feedback and iterate).
Re: "how it's done with Lago" : I assume you've seen the SQL queries we shared as examples... but you still don't think it makes the point, what would have? https://github.com/getlago/lago/wiki/Stripe-Data-vs-Open%E2%...
Disclaimer: the example (for the sake of the article) is relatively simple, as it's our first article on this topic, but we're willing to go much deeper, so feedback/inputs are welcome.
Why would a big company use Stripe? Any traditional merchant provider would trip over themselves to win their business. Is it just that they have billing models implemented?
Lago doesn’t store card data. You still use a Payment Processor like Stripe to process one-off payments. But the Subscription management and data related to subscriptions moves into Lago, in short you save on the fee you pay Stripe to manage subscriptions (Called Stripe Payments), it’s aprx 2% of the charge.
Who has subscriptions and when they are charged is now handled in your Lago code.
You can also then mix in other payment processors and regain control of your data.
I would still use Stripe as a startup. However I do provide services with integrated gateway and processor if you are in Canada or USA.
I can be reached with the email in my profile.
https://stripe.com/pricing
https://docs.google.com/spreadsheets/d/1wqs3LHNPZsKymxszsmSa...