51–60 of 75 posts
Earlier quoted context omitted.
I have to agree here. Feels like pure marketing/selling blogpost. I was not convinced.
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.
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 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 ot…
Does anyone know where/how getlago stores card data for recurring billing? How does getlago deal with pci concerns?
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.
Earlier quoted context omitted.
> 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…
I don’t disagree with you.
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.
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.
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.
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…
Retrieving the metrics you want from raw data.
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.
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 price…
Scroll down Stripe's pricing page, they will charge you for literally everything.
We have annual pricing and that definitely results in lower fees and other stuff. But only a small percentage of our users are on the annual plan.
Does anyone know where/how getlago stores card data for recurring billing? How does getlago deal with pci concerns?
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 oth…
Earlier quoted context omitted.
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 price…
Nope, b2b saas. We charge a decent amount. Scroll down Stripe's pricing page, they will charge you for literally everything. We have annual pricing and that definitely results in lower fees and other stuff. But only a small percentage of our users are on the annual plan.