[HN Gopher] Show HN: Autumn - Open-source infra over Stripe
___________________________________________________________________
Show HN: Autumn - Open-source infra over Stripe
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!
Author : ayushrodrigues
Score : 90 points
Date : 2025-06-24 12:48 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| filipealva wrote:
| Feels good to have billing solved in these rapid shipping times
| ayushrodrigues wrote:
| 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 :)
| gabrielruttner wrote:
| this is interesting and i've been poking at autumn for a little
| bit. and nice to see more billing in the oss. we started on a
| self hosted billing solution, but quickly realized that a single
| centralized (hosted) model was better for our particular use case
| (less to manage). curious if you're seeing the oss as a driver
| for trust or if folks are demanding this for some reason?
|
| also a fan of a single state for billing, metering, and
| entitlements. any plans for a go sdk for these?
| johnyeocx wrote:
| Thanks! Going oss was definitely about trust in the beginning
| -- people were more open to using the platform because they
| could see our codebase
|
| 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!
| abdhass wrote:
| Will this work for a charity? One-time and regular (monthyly,
| daily etc) donations? Thanks
| ayushrodrigues wrote:
| 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!
| notpushkin wrote:
| Neat! Seems similar to Lago (also open source):
| https://www.getlago.com/
|
| Are you planning on adding other payment providers besides
| Stripe?
| ayushrodrigues wrote:
| 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.
| codegeek wrote:
| You say but your landing page almost lists similar features
| that getlago does including things like "metering" etc. It is
| ok to be similar of course but I don't really see how you are
| different than them other than saying that they are focussed
| on Series B and you are for early stage. So feature wise, I
| am not seeing a huge difference. I could be wrong of course.
| ayushrodrigues wrote:
| 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.
| ethan_smith wrote:
| Supporting multiple payment providers would be crucial for true
| payment infrastructure independence - curious if there's a
| plugin architecture planned that would make it easier to add
| adapters for Adyen, PayPal, or regional payment gateways.
| ayushrodrigues wrote:
| 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.
| issanassar wrote:
| looks awesome, but how much can it scale up? i need to handle
| alot of throughput for my startup, like events per second
| johnyeocx wrote:
| each event is a consumable which means we aren't running large
| analytical queries to process them.
|
| Our bottleneck is probably infra + optimisations via caching
| but at the moment I'd say we can handle 1k events per second
| comfortably :)
| drag0s wrote:
| love this as someone who's been fixing the same billing bugs over
| and over and who sometimes finds stripe more complex than it
| should be. will make sure to try this on my next adventure.
|
| 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
| ayushrodrigues wrote:
| 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.
| kanzure wrote:
| 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!
| ayushrodrigues wrote:
| 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...
| namanyayg wrote:
| Nice to see this show HN, I was literally talking to a friend
| yesterday about how Autumn is making their billing way easier.
|
| 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.
| ayushrodrigues wrote:
| Nice to hear that word is starting to spread :) and happy to
| help when you come to integrate!
| dominikdoesdev wrote:
| Looks cool, but usually permissions management is done by auth,
| how does this work with autumn?
| ayushrodrigues wrote:
| 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.
| nodesocket wrote:
| How is update credit card on file and a listing of past invoices
| handled?
| ayushrodrigues wrote:
| 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.
| ericpsimon wrote:
| Congrats on the release Ayush! Happy to see this come to market.
| ayushrodrigues wrote:
| Thanks Eric!
| satvikpendem wrote:
| I have some web/mobile apps and I'm currently using Adapty which
| has custom paywalls and other sorts of features, as well as web-
| based paywalls now that Apple lost their ruling against Epic
| Games (and I'm using Flutter but the UI side doesn't necessarily
| matter due to the web-based nature of the paywalls). Is this a
| use case you are targeting? Adapty also integrates with Stripe
| for the web side of its offerings.
| ayushrodrigues wrote:
| 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.
___________________________________________________________________
(page generated 2025-06-24 23:00 UTC)