Re:Stripe Data vs. Open‐Source Alternatives: A MRR Example
by peterldowns on Sunday August 25, 2024 @07:47PM
(#41352578)
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.
Re:Stripe Data vs. Open‐Source Alternatives: A MRR Example
by danpalmer on Sunday August 25, 2024 @08:44PM
(#41352877)
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.
Re:Stripe Data vs. Open‐Source Alternatives: A MRR Example
by peterldowns on Sunday August 25, 2024 @08:58PM
(#41352953)
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.
Re:Stripe Data vs. Open‐Source Alternatives: A MRR Example
by fsndz on Sunday August 25, 2024 @09:40PM
(#41353234)
can't you just design your database so as to be able to do that independently ?
Re:Stripe Data vs. Open‐Source Alternatives: A MRR Example
by Rafsark on Sunday August 25, 2024 @10:40PM
(#41353534)
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.
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?