utkarsh-upadhyay_webhooks

[dawn grove]

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1286692546684260393

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

[viscid pumice]

Hi 👋 you want to listen to customer.subscription.created to be notified of the initial Subscription creation, customer.subscription.updated to be notified about updates to the Subscription, and customer.subscription.deleted for cancellations.
https://docs.stripe.com/billing/subscriptions/webhooks#events

checkout.session.completed can be used to receive the Checkout Session object in an event once your customer completes the checkout process.

It's hard for us to say exactly what events you need to listen for, because you know best what your flow needs to be made aware of.

Is there anything that you're currently not being notified of when you test your flow that you need to listen for?

[paper relic]

It's the opposite, I'm getting all these events on a stripe.checkout.sessions.create with mode: "subscription":

1. checkout.session.completed
2. payment_method.attached
3. customer.updated
4. payment_intent.created
5. payment_intent.succeeded
6. charge.succeeded
7. customer.subscription.created
8. customer.subscription.updated
9. invoice.created
10. invoice.finalized
11. invoice.updated
12. invoice.paid
13. invoice.payment_succeeded

Which is confusing me. It sends both customer.subscription.created and customer.subscription.updated

[viscid pumice]

That could be expected depending on how exactly the Subscription is being created. If the Subscription is created in one state then immediately transistions to another state when the payment succeeds. Do you have IDs of example events that you can share?

Within the Event there is a data.previous_attributes hash that gives you insight into which fields are changing.

[paper relic]

I am not getting this field, apiVersion = "2020-08-27"

Is it due to the older apiVersion?

[viscid pumice]

On which Event? It won't be on customer.subscription.created because the whole Subscription object is new, nothing is changing yet, that'll be in customer.subscription.updated.

Or on x.created events in general

[paper relic]

event id: evt_1Q17IjIroE9a6cxW11dZUKUl

  default_payment_method: null
  status: "incomplete"
}

[viscid pumice]

Gotcha. So the key things changing in that Event are the subscription going from incomplete to active, and the checkout session setting the default payment method on the Subscription object.

[paper relic]

Hmm, found something interesting:

payment_intent.succeeded (evt_3Q17IgIroE9a6cxW3LqNYkZR)
invoice.updated (evt_1Q17IjIroE9a6cxWkGr437fV)
invoice.payment_succeeded (evt_1Q17IjIroE9a6cxWi39fXyHW)
invoice.paid (evt_1Q17IjIroE9a6cxWKS78P46A)
customer.subscription.updated (evt_1Q17IjIroE9a6cxW11dZUKUl)
checkout.session.completed (evt_1Q17IiIroE9a6cxWGuUBy8dc)

All of these events were sent to me at the exact same time, in parallel maybe. Do they all, sort of, signify the same thing?

That the subscription was successfully created/updated?

[viscid pumice]

Yup they're all related to that. The Checkout Session creates a Subscription, the Subscription will create an Invoice, then the Invoice creates a Payment Intent. All of those objects will progress through their lifecycle as the payment happens and generate Events accordingly.

So there's a lot of flexibility in the Events that you can listen for depending on what exactly you want to be notified about, and what object you want to be included in the Event to make your downstream processing easier.

[paper relic]

And if I just want to know the very basic details like subscription created/failed, subscription modified, subscription cancelled

customer.subscription.created, customer.subscription.updated, customer.subscription.deleted

these should be enough, right? Or do I need invoice.payment_failed and invoice.paid as well?

[viscid pumice]

Those are enough for the Subscription object, but Subscriptions don't "fail" so you'll probably need a different Event there depending on what you're referring to failing.

[paper relic]

Like, if a user is on a monthly plan and I'm trying to charge them automatically for their next cycle. And for some reason the charge fails, then I want to move the user to a free plan. Which event should I be listening to in this case?

[viscid pumice]

Gotcha, you should be able to do that with just Subscription Events. The Subscription's status will become past_due if a recurring payment fails, then you can configure your account so those go into an unpaid state if you use our automatic retries and those all fail:
https://dashboard.stripe.com/settings/billing/automatic#:~:text=Manage failed payments for subscriptions

We talk about those flows a bit more here:
https://docs.stripe.com/billing/subscriptions/overview#build-your-own-handling-for-recurring-charge-failures

[paper relic]

Thanks Toby! I'll check these out in detail.

[viscid pumice]

Any time! We'll be around if there are any more questions that come up while you go through those or if they leave anything unanswered.