I use Stripe Checkout then, in "test" mode, I intentionally returned 400 http response or timed out to response 200 http response to Stripe in "test" mode and I waited for retries from Stripe for 9 hours but Stripe didn't send retries to my webhook. So, I opened query for missed events page then Stripe immediately sent the retry with the event type "setup_intent.created" to my webhook.
Retry logic says:
In test mode, Stripe retries three times over a few hours. Webhooks can be manually retried after this time in the Dashboard, and you can also query for missed events to reconcile the data over any time period.
Built-in retries says:
Stripe webhooks have built-in retry methods for 3xx, 4xx, or 5xx response status codes. If Stripe doesn’t quickly receive a 2xx response status code for an event, we mark the event as failed and stop trying to send it to your endpoint. After multiple days, we email you about the misconfigured endpoint, and automatically disable it soon after if you haven’t addressed it.
My questions in "test" mode with Stripe Checkout:
Normally to get a retry three times from Stripe, do I need to wait for more than 9 hours?
Immediately to get retries from Stripe, do I need to open query for missed events page?
Is the event type of retries from Stripe always "setup_intent.created"?
Does Stripe send a retry three times if Stripe doesn’t receive 200 http response or doesn't quickly receive 200 http response?
Does opening query for missed events page send a retry whether or not Stripe doesn't quickly receive 200 http response?
CodePudding user response：
- Normally to get a retry three times from Stripe, do I need to wait for more than 9 hours?
No. From my one week experiments, at least with Stripe Checkout, in "test" mode, I found that Stripe doesn't send any retries to my webhook most of the time even if I intentionally return 400 http response or timed out to response 200 http response to Stripe.
- Is the event type of retries from Stripe always "setup_intent.created"?
According to my one week experiments, at least with Stripe Checkout, in "test" mode, it is Yes. One by One, I returned 400 http response for 4 event types "payment_intent.created", "payment_intent.succeeded", "charge.succeeded" and "checkout.session.completed", then waited for the retry from Stripe. Finally, Stripe sent "setup_intent.created" for all 4 event types.
Actually, I asked Stripe support about "1" and "3" questions spending more than 3 or 4 hours but they don't even know much about Stripe which means horrible support eating time. So, you better solve any problems about Stripe yourself because you know Stripe super much more than them. Or just use other payment services.
CodePudding user response：
Normally to get a retry three times from Stripe, do I need to wait for over a few hours which is 2, 3 hours or more?
Yes, in test mode retries are automated over a short period following an initial event delivery failure. Stripe will re-attempt to deliver a test mode event up to 3 times.
Immediately to get retries from Stripe, do I need to open query for missed events page?
You can't manually trigger an event retry via the API, this can only be done via the Dashboard.
Is the event type of retries from Stripe always "setup_intent.created"?
The event type field on a retry will always be the same as the original event delivery attempt. If it was a setup_intent.created event then the type field will reflect that.
Does Stripe send a retry three times if Stripe doesn’t receive a 2xx response status code or doesn't quickly receive a 2xx response status code?
We expect to receive a 200 response ~immediately. It is recommended you return a 200 response before running any custom logic your webhook may need to handle, otherwise you risk the event being undelivered (even though it was processed).
Does opening query for missed events page send a retry whether or not Stripe doesn't quickly receive a 2xx response status code?
Querying for event via the API does not re-attempt event delivery. The idea is that following event delivery failures, you can reconcile any missed events by querying for those objects from the API.