Live data from Hacker News

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

github.com

31–40 of 75 posts

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

#32
post #22

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 re…

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.

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!

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

#33

Earlier quoted context omitted.

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.

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!

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.

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

#34
post #26

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 ve…

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.

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

#35
post #26

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 ve…

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.

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

#36

Earlier quoted context omitted.

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.

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!

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?

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

#39
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.

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

#40
post #22

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 re…

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.

The whole idea that billing should be "a service" was a Jedi Mind Trick.
Post reply on HN