[HN Gopher] Stripe Data vs. Open-Source Alternatives: A MRR Example
___________________________________________________________________
Stripe Data vs. Open-Source Alternatives: A MRR Example
Author : AnhTho_FR
Score : 143 points
Date : 2024-08-25 19:28 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| danpalmer wrote:
| 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?
| peterldowns wrote:
| 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.
| danpalmer wrote:
| 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.
| peterldowns wrote:
| 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.
| fsndz wrote:
| can't you just design your database so as to be able to
| do that independently ?
| Rafsark wrote:
| 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.
| guyfromfargo wrote:
| 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 wrote:
| 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
| peterldowns wrote:
| 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.
| echelon wrote:
| > 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 wrote:
| I don't disagree with you.
| saadatq wrote:
| 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.
| AnhTho_FR wrote:
| 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?
| peterldowns wrote:
| 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.
| AnhTho_FR wrote:
| 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.
| fsndz wrote:
| I have to agree here. Feels like pure marketing/selling
| blogpost. I was not convinced.
| echelon wrote:
| 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.
| Rafsark wrote:
| That's one of the options, yes. Chartmogul does an amazing
| job at ingesting and retrieving revenue data from stripe
| echelon wrote:
| Please someone from Stripe see this. This is my #1 frustration
| with Stripe.
| ripe wrote:
| For people like me who might be wondering:
|
| MRR = monthly recurring revenue
|
| This is a metric relevant to subscription businesses.
| Rafsark wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| samdung wrote:
| 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...
| chucky123 wrote:
| 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 wrote:
| 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!
| chucky123 wrote:
| 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.
| Rafsark wrote:
| 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
| j33zusjuice wrote:
| Have you already looked here?
|
| https://alternativeto.net/software/stripe/
|
| 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?
| internetter wrote:
| I'm seriously considering https://www.paddle.com/. For 5% +
| $0.5, they promise that you'll never need to worry about
|
| - Chargebacks
|
| - Global tax compliance
|
| - Billing support
|
| - Fraud
|
| - Subscription management
|
| Their API is... worse... and it is expensive... but mathing
| it out it is like 1% for all that peace of mind. Feels
| worth it.
| ensignavenger wrote:
| Until you build out your business around their API and
| processes, and they decide to start charging more... and
| more..
|
| Obviously you need to use some third party services, but
| as soon as your business is viable, always be preparing
| the ability to switch to competitors.
| jokethrowaway wrote:
| 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.
| chasebank wrote:
| Until they raise their pricing too.
|
| 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.
| dboreham wrote:
| The whole idea that billing should be "a service" was a Jedi
| Mind Trick.
| hibikir wrote:
| 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.
| thedangler wrote:
| 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.
| bastawhiz wrote:
| 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.
| Palmik wrote:
| 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.
| chucky123 wrote:
| Exactly, Lago seems like its riding the open source wave.
| Nobody reasonable is going to self host this.
| Scotrix wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| ....that's exactly what the article is describing.
|
| Retrieving the metrics you want from raw data.
| nprateem wrote:
| Best payment processor for hybrid for people who hate stripe (if
| you were doing it today for a bootstrapped startup)?
| thedangler wrote:
| 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 wrote:
| 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 wrote:
| Useful read and thread about Stripe.
| benmcredmond wrote:
| 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.
| ledgerdev wrote:
| Does anyone know where/how getlago stores card data for recurring
| billing? How does getlago deal with pci concerns?
| evolve2k wrote:
| 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.
| bastawhiz wrote:
| 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.
___________________________________________________________________
(page generated 2024-08-26 23:01 UTC)