jacob-subscription-qs

[pulsar dew]

I see lots of different things in subscription updated, I think I only want when the price is changed?

[lucid ether]

1. What event should I use for subscriptions upgraded/downgraded in the billing portal? Subscription updated?
   yes, customer.subscription.updated

2. Does a past due/payment failed subscription eventually become cancelled, or do I need to implement my own expiration logic in addition to Events.CustomerSubscriptionDeleted?

I think there is a Dashboard setting which allows auto-cancel after certain retry settings

[pulsar dew]

Thank you for the fast response

[lucid ether]

I think I only want when the price is changed?

the previous_attributes on an Event request body tells you what changed from before/after on the event

Thank you for the fast response

thanks! what we're here to do, help quickly with developer qs

[pulsar dew]

So basically check if they're different 👍

[lucid ether]

yep

[pulsar dew]

What is the plan.updated event used for?

That may not be the name, it's PlanUpdated in the .NET library

[lucid ether]

that would be if you updated a Plan or Price object

but not a Subscription that switches from price_1 to price_2

[pulsar dew]

Ah thank you. And one more thing, when I get the subscription.updated that means the price difference (if any) is paid right?

Or can they upgrade their plan and have payment fail?

[lucid ether]

when I get the subscription.updated that means the price difference (if any) is paid right?

I think whether it was paid depends. depends on whether there was proration or not etc

so I would look at the latest Invoice on the Subscription, it should a/ be the same time as the Price switch and b/ it should have the new Price

[pulsar dew]

If there is any amount, depending on proration, will that be paid? Or you're saying having proration enabled changes the behavior?

Also, in that case, is the latest invoice date really guaranteed to be exactly the same as the subscription? Makes me a bit uneasy to rely on that

[lucid ether]

stepping away, a colleague is jumping in to help you out!

[orchid sage]

👋 Hello! Give me a minute to catch up

[pulsar dew]

Thank you for your time

[orchid sage]

Just to confirm - you're asking whether receiving the customer.subscription.updated event guarantees that the price difference has been paid? Receiving that event doesn't mean that the latest invoice has been paid - you can update a subscription but still have the price difference not be paid depending on the payment_behavior that was set when the subscription was updated (see https://stripe.com/docs/api/subscriptions/update#update_subscription-payment_behavior)

[pulsar dew]

I see thanks. I'm using the billing portal, so I guess I need to setup the payment_behavior I want in the portal settings

So an invoice will be issued but customer.subscription.updated will be fired regardless?

[orchid sage]

Ahhh, I forgot that you were using the billing portal - in that case, let me double check something

[pulsar dew]

Thanks

[orchid sage]

So I believe the billing portal will use payment_behavior: pending_if_incomplete (specifically with card payment methods), so when payment fails you should see that reflected in pending_update on the Subscription (see https://stripe.com/docs/billing/subscriptions/pending-updates#handling-failed-payments)

[pulsar dew]

Thank you. If the payment is eventually successful will I get another subscription updated event or will I get an invoice paid?

Maybe I should record pending payment invoice IDs then if paid provision the new plan?

[orchid sage]

Yes, I believe when the payment is eventually successful you should get another customer.subscription.updated event in addition to an invoice.paid event

[pulsar dew]

Oh great. Thank you!