- ayushrodriguescongrats on the launch Arlan! Nia is a lifesaver when we're coding :)
- This is the most fun I've had on the internet in a long time.
- I've been interested in a tool like this for a while. I currently have tried whisprflow and aqua voice but wanted to use my API key and store more context locally. How does all the data get stored and how can I access it?
- Ah yes. Interestingly most of our users don't set this up in the early stage. But for the ones that do, they need webhooks for this. We have a single webhook that fires whenever a customer's state is updated (eg subscription started, cancelled, downgraded, expired) etc, that the downstream functions you talk about rely on.
- This is really helpful context. Thanks for sharing!
- Ah shame we missed you! Glad to hear it resonates :)
- We have react hooks so we try and make the majority of the integration lift on the frontend. One of our contributors is helping us launch a python SDK soon too !
- Adapty looks cool! Kind of similar to Revenuecat?
I think the offering is similar -- both manage entitlements and paywalls. And while we do have a proportion of users that use us for mobile apps we're pretty focused on SaaS / web.
I can imagine Adapty would go deeper on features like AB testing, paywall designing etc
Our users handle lower volume of subscriptions but require more flexibility and depth on the pricing models they want to support.
- Thanks Eric!
- We are pretty tightly coupled with Auth. Part of setting it up is resolving your internal customer (or org) ID from your auth JWT and passing it into an autumnHandler function, which then makes calls to the Autumn API.
This means you don't need to store any additional IDs for billing -- just make calls to Autumn with your exiting auth uuids.
- Updating credit card: - We have an openBillingPortal() function that when called, will redirect a user to the Stripe billing portal where they can update their card info. If it's a valid card, we allow the change and keep the customer in an active subscription state.
Past invoices: - We have a GET /customer method that returns all billing related information on a user. This includes their current plans, features and balances they have available, and can take in an expand?=invoices param that will return all past invoice data for you to display.
Users can also see invoice history in the Stripe billing portal mentioned above.
- Nice to hear that word is starting to spread :) and happy to help when you come to integrate!
- I think that's a fault of ours with our landing page and messaging. We can definitely do a better job here. Almost everyone that has used us after using Lago can tell a big difference with the products.
The main reason that people use us is permissions management. We are the source of truth for which of your users can access what, and linking that to billing. Eg, we know that because user ABC is on Pro tier and bought 3 top ups, they have access to 75 AI credits. If their next payment fails, they should only have access to 15 AI credits (etc etc). Our value is in handling this matrix of scenarios related to usage resets, billing cycles, transitioning between monthly and yearly plans, etc.
Lago only handles billing, so if you're using them, then the logic to sync up the user's permissions with the billing state has to be handled yourself.
- Ah yes, we're still entirely built on Stripe, so all your chargeback management, tax handling, subscriptions and payments are still handled by them! We are not a Stripe replacement.
When our users integrate Autumn, they don't need to handle the state syncing or any Stripe events, as we do all of that for them.
Eg, one of your users, John, subscribes to a Pro tier. We'll listen to that event from Stripe, and grant them access to the right features (eg premium analytics and 100 messages).
From your app, you just query Autumn to ask "does John have access to send messages?", and Autumn says "yes".
When the John's payment fails, we again handle that event from Stripe. Now when your app asks whether John has messages, Autumn says "no, their payment failed".
When you log into Stripe, you can still see everything as normal, and take actions as you normally would!
Edit: now that I'm writing this comment, I realize that we probably should be listening to the chargeback event so we can block access to features if that happens. We'll definitely handle this case, it's just that no one has needed it so far...
- Thank you! We try and take case of most of these bugs and edge cases. I think the ones that have been most useful are:
1. Race conditions. There are some weird conditions to handle around if a user makes it back to your app post-payment before the webhook, or if they click twice on a purchase button accidentally.
2. Keeping usage reset cycles in sync with billing cycles. We had a bunch of weird cases to solve in February as it's a shorter month.
3. Handling annual plans that have monthly usage billing cycles. Or just handling anything to do with transitioning between annual and yearly billing.
Theo's approach is awesome and a very similar architecture to what we have.
- This is absolutely where we want to end up within the next year, especially as we move upmarket. Enterprises love having redundancy between payment providers to use as leverage for lower fees and there are several companies founded purely around payment routing, (deciding which payment provider has the best acceptance rate based on region, issuing bank, MCC etc). Some examples are primer and payrails.
It just turns out that most of our users are only really interested in using Stripe at the early stage, so for now our codebase is closely embedded into their billing product.
It's going to be fun(?) ripping all of it out and moving towards a PSP agnostic architecture you mentioned.
- People compare us a lot because they're also another open source YC company that does billing. So definitely some similarities!
I think in practise though we serve a very different segment. Lago is great for high-throughput event metering and mainly target series B+ companies. They don't yet have an offering for feature permissions management (aka entitlements).
Autumn is built more for early stage companies that have payments in-app. Hence we're trying to invest more in the developer experience (eg React hooks), while also providing that abstraction layer for entitlements too.
We absolutely will be adding more payment providers soon. Our biggest requests are Polar and Razorpay for the indian market.
- Hey! Yes it will, as long as you can process the payment with Stripe, you can use us. I know Stripe has discounts for non-profits.
However, Autumn is really only useful when combined with our permissions / entitlement management. So if your donors get access to certain things once they donate, then it would make sense to use us!
- Appreciate the kind words. We have a long way to go before it's a solved problem, but making headway for early stage companies with typical SaaS pricing :)