←back to thread

139 points ayushrodrigues | 2 comments | | HN request time: 0.671s | source

Hey HN, I’m Ayush from Autumn (https://useautumn.com/). Autumn is an open source layer over Stripe that decouples pricing and billing logic from your application. We let you efficiently manage pricing plans, feature permissions, and payments, regardless of the pricing model being used. It’s a bit like if Supabase and Stripe had a baby.

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!

Show context
kanzure ◴[] No.44368428[source]
Hi, your docs say that users don't need state syncing, but when using Stripe you do need state syncing or to ingest the Stripe events. I also don't see any information in the docs about handling e.g. chargebacks or other events and listening for (or otherwise syncing against the history of) those events. I'm a little confused - why would I want to not have that? I could be misunderstanding this project though!
replies(1): >>44368538 #
ayushrodrigues ◴[] No.44368538[source]
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...

replies(1): >>44378344 #
1. kanzure ◴[] No.44378344[source]
Huh, weird. I don't think I have ever wanted to login to Stripe and take manual actions. Usually I hook up Stripe events to actions in my applications, like "The user subscribed, wire them up to the drip lifecycle" or "The user unsubscribed, remove them from a certain marketing list and try to schedule an exit interview" or other hook-ups.
replies(1): >>44378387 #
2. ayushrodrigues ◴[] No.44378387[source]
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.