friiky2-webhooks

[loud vector]

1. the .updated event is likely enough, but it depends how you change the plan for example. For example for some changes the customer has to pay for the change upfront(like they get a prorated invoice for the change) and you might not want to give them access in your system until that's done, hence invoice.paid being recommended.

2. not sure what you mean by 'default' status for a subscription, the status changes according to various criteria

friiky2-webhooks

[harsh axle]

Found it, jsut try to get and anker link 🙂

https://stripe.com/docs/billing/subscriptions/overview#subscription-lifecycle There it says:

If you set payment_behavior to default_incomplete, the subscription status is incomplete. Learn more about why we recommend using this type of payment behavior for subscriptions.

[loud vector]

yep that's the status the subscription starts in before the customer pays the first invoice

[harsh axle]

so that is already taken car of if I listen for checkout.session.completed to start everything

same goes for customer.subscription.updated as it state in the docs, that it is first send after successful payment.

Sent when the subscription is successfully started, after the payment is confirmed....

[loud vector]

yes it's irrelevant if you're using Checkout since you just track when the CheckoutSession is complete to kick off any order fulfillment

[harsh axle]

Ok so for starting the sub it's clear.

And for changing the subscription I need to listen for the invoice.paid when I have payment methods not paid instantly? Did not quite understand that.

[loud vector]

what can I clarify?

[harsh axle]

Good question. 😂 So if I understood correctly, I listen for the update and as long as it says active, I can assume, that the subscription is at least somehow paid + if payment fails, I will get the .deleted anyways. Right? So I use the invoice paid just to confirm delayed payments?

[loud vector]

sounds about right