#venkateshjsoft
candid gorge
Hi 👋 can you clarify, are you trying to cause the Event to be sent to the webhook endpoint again, or is there something in your webhook endpoint's code that you want to try again?
lament finchBOT
civic tinsel
when stripe sents the webhook and if my server is busy, can we configure stripe to retry again
I noticied that its not retrying again
like retry 3 times before stop sending webhook
candid gorge
That is default behavior. In live mode we use an exponential backoff approach and attempt to deliver Events for up to three days before giving up:
https://stripe.com/docs/webhooks#retries
That behavior occurs automatically if your webhook endpoints responds to us with a status outside of the 2XX range.
Can you share the ID of an Event where you didn't see the a retry attempted for a failed delivery?
civic tinsel
evt_1Nuzx8B4yD6nPBkB6d219ofA
Currently we are not returning any status when we receive webhook from stripe, but you mentioned if our webhook endpoints responds to us with a status outside of the 2XX range. Will this cause any issue?
gentle mist
👋 stepping in here as toby needs to step away
So ideally you always return a status code of 2xx immediately when you ingest the webhook.
If something goes wrong on your end, you already have the data. However, you can also respond with something like a 4xx on your end if something unexpected goes wrong and then retries will occur.
Really you should always respond though and not just let it timeout
civic tinsel
currently on acceptance, im not returning any status. but webhook is working fine
but if its failed to send, it stop sending futher
will there any problem if we go the same implementation to production
gentle mist
I don't really understand what you mean by:
currently on acceptance, im not returning any status. but webhook is working fine
If you don't return a status then eventually your endpoint will be automatically disabled
civic tinsel
ah okay
one more question
Im trying to test dispute case
I received charge disputed event immediately after payment intent is created. Before I process the payment intent event, I received the next event and we have some logic which is breaking. Is there a way I can delay this
gentle mist
Nope, events are never guaranteed to be in order (https://stripe.com/docs/webhooks#event-ordering) so your code should be resilient to this
civic tinsel
Thanks
candid gorge
A quick note about the Event that was referenced above. It wasn't sent to a webhook endpoint, so we don't have any insight into it failing to be delivered. That Event seems to have been picked up by the listener provided by the Stripe CLI. When using stripe listen, the CLI always immediately responds to Stripe with a 200 status to indicate it successfully received the Event. You won't see Event delivery retry logic kick in when using the Stripe CLI.
civic tinsel
is it possible to generate the dispute event myself
because im getting payment intent and dispute event almost same time
I have some logic which can work only after payment intent is completed
civic tinsel
normally this wont happen in production
because to react for the payment and create dispute will not happen immediately after payment is charged
i dont want to spend too much time to change the logic just because in sandbox its returning same time
plz let me know if you have any suggestion
gentle mist
There is no way to delay this in test mode, no.
So you can mock the response instead if you want
And use that for testing
civic tinsel
is it possible for me to generate this webhook
like creating dispute via api call
so stripe can generate webhook
gentle mist
No that won't guarantee that you receive that after payment_intent.succeeded in test mode
civic tinsel
I mean i create a payment using valid test card
then I manualluy initiiate dispute for the payment
then stripe should be able to send new webhook event for charge dispute right
i will be doing this after payment charge is completed (may be after 5 min)
gentle mist
As far as I know you can't manually initiate a dispute