Preferences

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


kanzure
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.
ayushrodrigues OP
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 item has no comments currently.