Typically, you have to write code to handle checkouts, upgrades/downgrades, failed payments, then receive webhooks to provision features, reset usage limits etc. We abstract this into one function call for all payments flows (checkouts, upgrades, downgrades etc), one function to record usage (so we can track usage limits), and a customer state React hook you can access from your frontend (to handle paywalls, display usage data etc).
Here’s a demo: https://www.youtube.com/watch?v=SFARthC7JXc
Stripe’s great! But there are 2 main reasons people use Autumn over a direct Stripe setup:
(1) Billing infra can get complex. After payments, there’s still handling webhooks, permission management, metering, usage resets, and connecting them all to upgrade, downgrade, cancellation and failed payments states.
(2) Growing companies iterate on pricing often: raising prices, experimenting with credits or charging for new features, etc. We save you from having to handle usage-based limits (super common in pricing today), rebuilding in-app flows, DB migrations, internal dashboards for custom pricing, and grandfathering users on different pricing.
Ripping out billing flows etc, really sucks. With Autumn, you just make pricing changes in our UI and it all auto-updates. We have a shadcn/ui component library that helps with this.
Because we support a lot of different pricing models (subscriptions, usage, credits, seat based etc), we have to handle a lot of different scenarios and cases under the hood. We try to keep setup simple while maintaining flexibility of a native integration. Here’s a little snippet of the architecture of our main endpoint: https://useautumn.com/blog/attach
Currently, the users who get the most value out of us are founders that need to move fast and keep things flexible, but also new/non-technical devs that are more AI native.
You can clone the project and explore the repo, or try it out at https://useautumn.com/, where it’s free for builders. Our repo is https://github.com/useautumn/autumn, docs are at https://docs.useautumn.com/ and demo at https://www.youtube.com/watch?v=SFARthC7JXc
We’d love to hear your feedback and how we could make it better!
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...
Are you planning on adding other payment providers besides Stripe?
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.
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.
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.
Lago is better in that they have have support for custom payment integrations [3].
[1] https://stripe.com/global
[2] https://paystack.com/stripe/south-africa
[3] https://getlago.com/docs/integrations/payments/custom-paymen...
(just to be clear, not relevant in my case at this point, just something that was a bit messy to handle in something I worked with previously)
Connecting this all to auth systems is still a flow we’re hoping to make cleaner. It’s in early stages for now.
btw, if you still want to go directly with stripe, here are some general recommendations/notes I generally agree with:
https://github.com/t3dotgg/stripe-recommendations
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.
Any insight into why they failed and why you will be different?
In contrast, Lago uses AGPL-3.0 and has an open-core model (not sure if the premium features are source available or not), which makes it more clearer on how they're going to make money.
I've suffered so much with all the pricing changes I've been experimenting with (early stage solo founder). Till now had been chugging along doing it manually but I'm going to integrate autumn soon.
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!
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.
few builders i know struggling with this. will share this with them.
also a fan of a single state for billing, metering, and entitlements. any plans for a go sdk for these?
Agreed that self-hosting billing can be a pain just cuz of how complex the whole system can be, which also means that it's prob p hard to debug / fix when something goes wrong. We don't see a lot of people self-hosting Autumn at the moment, but would be interesting to see that happen.
We've got a bunch of requests for a go sdk, so definitely on our roadmap to launch that soon!
DX is our bread and butter though, and we're fully focused on perfecting it for a single language (Typescript) before we start journeying into other languages!
This means you don't need to store any additional IDs for billing -- just make calls to Autumn with your exiting auth uuids.
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.
Our bottleneck is probably infra + optimisations via caching but at the moment I'd say we can handle 1k events per second comfortably :)