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!

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!

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.

Our bottleneck is probably infra + optimisations via caching but at the moment I'd say we can handle 1k events per second comfortably :)

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.

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...

This means you don't need to store any additional IDs for billing -- just make calls to Autumn with your exiting auth uuids.

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.