#inexorable - subscription

1 messages · Page 1 of 1 (latest)

stable plinth
#

Hi! I'm sorry but I'm not sure I follow. Could you give a concrete example of what you are trying to do?

zenith nova
#

Hi - thanks for your time... I can probably manage Subscription lifecycles (in my app) without hooking into checkout.session.completed events at all (by using just subscription and invoice events) - but I'm exploring whether or not to keep checkout.session information in my Db too. If I do, I'm trying to decide if I need to just keep a few checkout.session variables in my Subscription table, or if I need a one-to-many relationship between Subscriptions and a CheckoutSessions Db table.

One Subscription --> Many Checkout Sessions

I'm having trouble working out if a given Subscription will ever encounter multiple CheckoutSessions - or will it only ever see future Subscription and Invoice events once created. Specifically, I think I'm asking about what happens when a Subscription ends... like is properly killed off.... is there a way to renew or somehow bring that Subscription back to life in a way that requires a new Checkout Session?

stable plinth
#

Got it! You'll have one Checkout Session ID when you create the subscription in the first place, and then... that's it! If you update/cancel the subscription later, that won't involve a Checkout Session.

#

So one subscription -> zero or one Checkout Session (since it's possible to create a subscription directly without a Checkout Session (not recommended)).

zenith nova
#

So if a Subscription is cancelled (and it's past it's true expiry date), it can't be brought back to life with another payment?

stable plinth
#

If the subscription is "canceled" then you cannot do anything except create a new subscription. If the subscription is "past_due", then yes the customer can still pay to make the subscription "active", but you can't use a new Checkout Session for this.

zenith nova
#

soma - you're wonderful. Thank you very much.