Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

41–50 of 75 posts

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

#41

Post by thedangler »

chucky123 wrote: post #28
samdung wrote: 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.

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.

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

#42

Post by thedangler »

nprateem wrote: post #31

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

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.

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

#43

Post by internetter »

moralestapia wrote: post #32
chucky123 wrote: post #28

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

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

#44

Post by prettygood »

sb8244 wrote: post #21

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.

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.

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

#46

Post by SoftTalker »

ripe wrote: post #10

For people like me who might be wondering: MRR = monthly recurring revenue This is a metric relevant to subscription businesses.

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.

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

#47

Post by hibikir »

dboreham wrote: post #40
chucky123 wrote: post #28

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.

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

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.

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

#48

Post by ensignavenger »

internetter wrote: post #43
moralestapia wrote: post #32

Earlier quoted context omitted.

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

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.

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

#49

Post by jokethrowaway »

internetter wrote: post #43
moralestapia wrote: post #32

Earlier quoted context omitted.

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

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.

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

#50

Post by chasebank »

internetter wrote: post #43
moralestapia wrote: post #32

Earlier quoted context omitted.

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

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.

Post reply on HN