7 ms·
Stripe Data vs. Open‐Source Alternatives: A MRR Example
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- danpalmer 2y agoAt 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?
- peterldowns 2y agoSome 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.
- danpalmer 2y agoIs 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.
- peterldowns 2y agoYes, 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.
- fsndz 2y agocan't you just design your database so as to be able to do that independently ?
- Rafsark 2y agoYou’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.
- guyfromfargo 2y agoI 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 2y agothey 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
- peterldowns 2y agoI 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.
- echelon 2y 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.
- peterldowns 2y agoI don’t disagree with you.
- saadatq 2y agoA 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.
- AnhTho_FR 2y ago
- echelon 2y agoPlease someone from Stripe see this. This is my #1 frustration with Stripe.
- ripe 2y agoFor people like me who might be wondering: MRR = monthly recurring revenue This is a metric relevant to subscription businesses.
- Rafsark 2y agoYes! And ARR = annual recurring revenue. In addition to other saas metrics like usage revenue that is pure consumption based and sometimes calculated differently
- SoftTalker 2y agoSuch 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 2y agoStripe'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 2y agoWe 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.
- jjeaff 2y agoMy 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 2y agoWe 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://stripe.com/pricing https://docs.google.com/spreadsheets/d/1wqs3LHNPZsKymxszsmSaUaiCXgPc-VjIVCvYAdj00xI/edit?gid=0#gid=0 https://docs.google.com/spreadsheets/d/1wqs3LHNPZsKymxszsmSa...
- chucky123 2y ago100%. 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 2y agoCan 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!
- chucky123 2y agoi 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.
- Rafsark 2y agoYou 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
- Palmik 2y agoThe 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.
- chucky123 2y agoExactly, Lago seems like its riding the open source wave. Nobody reasonable is going to self host this.
- jjeaff 2y agoI 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.
- Palmik 2y agoBecause to self host it, you'd need to ensure you're PCI compliant. That works for established companies I guess, but not so much when starting out. Payment provider lock-in in a scary thing, when they can cancel your account at moment's notice.
- Scotrix 2y agoAs 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 2y agoOften 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 2y agoPartly. 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.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- nprateem 2y agoBest payment processor for hybrid for people who hate stripe (if you were doing it today for a bootstrapped startup)?
- thedangler 2y agoI 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 2y agoWhy 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 2y agoUseful read and thread about Stripe.
- benmcredmond 2y agoIf this is something you're struggling with... It's one of the core use-cases we're solving for at Equals (https://equals.com 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 2y agoWould 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?
- benmcredmond 2y agoSorry, 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.
- ledgerdev 2y agoDoes anyone know where/how getlago stores card data for recurring billing? How does getlago deal with pci concerns?
- evolve2k 2y agoLago 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.
- bastawhiz 2y agoThere'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 2y agoMuch of this would be solved if you specified whether you used cash or accrual basis
- jjeaff 2y agoRegardless 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.
- jjeaff 2y agoI 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 2y agoLago is mocking the very idea of OSS. You can't even issue a refund self hosted.