Stripe Data vs. Open‐Source Alternatives: A MRR Example

https://github.com/getlago/lago/wiki/Stripe-Data-vs-Open%E2%80%90Source-Alternatives:-a-MRR-example

by AnhTho_FR • 2 years ago

167 69 2 years ago

danpalmer2• 2 years ago

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?

peterldowns5• 2 years ago

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.

danpalmer2• 2 years ago

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.

guyfromfargo• 2 years ago

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.

fragmede• 2 years ago

they already have the data, so at some level it's easier to give them the rest of it and process it with their service than do it yourself

peterldowns5• 2 years ago

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.

echelon3• 2 years ago

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.

peterldowns5• 2 years ago

I don’t disagree with you.

AnhTho_FR2• 2 years ago

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?

peterldowns5• 2 years ago

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.

fsndz2• 2 years ago

I have to agree here. Feels like pure marketing/selling blogpost. I was not convinced.

echelon3• 2 years ago

Try hooking Stripe up to any third party analytics dashboard. You won't get an accurate MRR.

It really sucks if you want to have Stripe metrics in front of your team.

echelon3• 2 years ago

Please someone from Stripe see this. This is my #1 frustration with Stripe.

ripe• 2 years ago

For people like me who might be wondering:

MRR = monthly recurring revenue

This is a metric relevant to subscription businesses.

Rafsark4• 2 years ago

Yes! And ARR = annual recurring revenue. In addition to other saas metrics like usage revenue that is pure consumption based and sometimes calculated differently

SoftTalker• 2 years ago

Such a common oversight for writers. Define your acronyms when they are first used, it takes very little effort and it will help some of your readers.

sb8244• 2 years ago

Stripe's MRR number is NOT correct for my application (shows as higher by 1-2%).

I have an external script over their API that calculates MRR, and every single tool that calculates MRR has had a different number.

It's actually a huge PITA, although my custom script works well enough.

prettygood• 2 years ago

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.

jjeaff4• 2 years ago

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.

samdung• 2 years ago

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).

https://stripe.com/pricing

https://docs.google.com/spreadsheets/d/1wqs3LHNPZsKymxszsmSa...

chucky1234• 2 years ago

100%. Stripe is a blackhole.

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.

moralestapia• 2 years ago

Can you (and GP, and others in the thread) suggest alternatives?

I'm about to work on payments for a new product, would like to try something new!

dboreham• 2 years ago

The whole idea that billing should be "a service" was a Jedi Mind Trick.

thedangler2• 2 years ago

That is quite the markup. You should look into using a processor and a gateway with a solid API. email me if you have questions.

bastawhiz3• 2 years ago

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.

ankit774• 2 years ago

Check out getopenpay.com

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

Palmik2• 2 years ago

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.

chucky1234• 2 years ago

Exactly, Lago seems like its riding the open source wave. Nobody reasonable is going to self host this.

jjeaff4• 2 years ago

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.

Scotrix• 2 years ago

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?

rtpg• 2 years ago

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.

figassis• 2 years ago

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.

paulddraper• 2 years ago

....that's exactly what the article is describing.

Retrieving the metrics you want from raw data.

nprateem• 2 years ago

Best payment processor for hybrid for people who hate stripe (if you were doing it today for a bootstrapped startup)?

thedangler2• 2 years ago

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.

datavirtue• 2 years ago

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?

frays• 2 years ago

Useful read and thread about Stripe.

benmcredmond2• 2 years ago

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.

asdfqwertzxcv• 2 years ago

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?

benmcredmond2• 2 years ago

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.

ledgerdev2• 2 years ago

Does anyone know where/how getlago stores card data for recurring billing? How does getlago deal with pci concerns?

evolve2k2• 2 years ago

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.

ledgerdev2• 2 years ago

So lago is storing token issued by processor, then using that token to trigger payments?

bastawhiz3• 2 years ago

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.

Zenzero• 2 years ago

Much of this would be solved if you specified whether you used cash or accrual basis

jjeaff4• 2 years ago

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.

jjeaff4• 2 years ago

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.

derekperkins• 2 years ago

Lago is mocking the very idea of OSS. You can't even issue a refund self hosted.

Stripe Data vs. Open‐Source Alternatives: A MRR Example

Related Stories