arrayappy

[urban island]

Sounds like the default integration path. Is that unexpected? Can you share a req_xxx of you creating the Subscription?

[digital crag]

req_VkvlP56oAV67CL

[urban island]

Ok, you're using Checkout. Yep, that's how it works. We create the Subscription (and that event fires), it's status is incomplete as a payment is due. Once the payment completes, you'll get a customer.subscription.updated event and status: 'active'

[digital crag]

Ok, But we are listening to customer.subscription.created and customer.subscription.updated and we create new document in our database if there is no object exists with the stripe subscription id, we will create new document with custom id ( we are not using stripe subscription id as document id ). But customer.subscription.created and customer.subscription.updated are getting called at the same time and creating two documents in the database.

There is a 2 seconds delay in both webhooks, but my backend server is not able create the document for customer.subscription.created.

[raven gate]

you can't assume any order of webhook delivery, so you need to robustly handle that. For example if you get the .updated event first, call the API to retrieve the Subscription object and create your database records based on its current state. Or push events into a queue system on your side and play through that based on the creation date of the events

but if you're using Checkout you sohuldn't even be using those events

[digital crag]

If I proceed to create document only when event.data.object.status === "incomplete" in created webhook object, it is working fine

[raven gate]

you listen to the checkout.session.completed and you do everything you need to do based on that (https://stripe.com/docs/payments/checkout/fulfill-orders) ; the fact Checkout creates/updates a subscription as it runs is more of an implementation detail

[raven gate]

if you're using Checkout, don't even create anything until you're handling the Checkout-specific event(at which point you can access the session.subscription field which is the created/active subscription)

[digital crag]

We are listening to checkout.session but we are not doing anything with that webhook.

[digital crag]

We are handling only the two webhooks, and customer.subscription.created helping us when payment failures are happening to track the created time

[raven gate]

you should

[digital crag]

Upon customer.subscription.deletion we are updating latest

[digital crag]

What are the all the webhooks should I listen to then

[raven gate]

depends on the use case! for knowing when a subscription is created and you need to add that to your database and provide access to your service, just checkout.session.completed

after that for tracking the ongoing payments, you would listen to invoice.paid and customer.subscription.updated https://stripe.com/docs/billing/subscriptions/webhooks#active-subscriptions

[digital crag]

Currently listening to those two webhooks, actually working for us
But if we put the above check, only single document getting created and if we remove that check two documents are creating.

Is there any call kind of options ??

[raven gate]

not sure what that means.

no

[digital crag]

Ok

If i can proceed with upon checkout.session

How do I handle autorenewing updates

again customer.subscription.updated right ??

[raven gate]

after that for tracking the ongoing payments, you would listen to invoice.paid and customer.subscription.updated https://stripe.com/docs/billing/subscriptions/webhooks#active-subscriptions

note also that you could ignore customer.subscription.updated events if say the latest_invoice of the referenced subscription has billing_reason:"subscription_create" since you will handle that case in your Checkout handler (https://stripe.com/docs/api/invoices/object#invoice_object-billing_reason)

[digital crag]

In that case for first time subscription getting created via checkout session, I can depend on checkout session

OKK

For creation should i handle customer.subscription.created or checkout.session.completed is enough ?

[raven gate]

checkout.session.completed is enough

[digital crag]

In our use case we are not maintaining invoices, so finally checkout.session.completed for creation (first time)

And customer.subscription.updated and customer.subscription.deleted for after the first time updates

Will the flow works

[raven gate]

it should!

[digital crag]

Here I'm not getting billing_reason field, only getting for invoice.paid

[raven gate]

it's a field of the invoice specifically

so depending on what you have and what you're starting with, you will have to make some API calls to get extra information(like you can call https://stripe.com/docs/api/checkout/sessions/retrieve and pass expand:["subscription.latest_invoice"] and so on)