#kurage6566
fathom dragon
Sorry for the delay.
How about this way?
"id": "evt_1NaV7gJ2s7TuvZITWoB8wO73", "id".
fathom dragon
Yes,
Not every time, but the probability of failure is high.
remote bloom
Can you try running this script on your server? https://github.com/stripe/stripe-reachability
fathom dragon
Thanks for the info!
I see!
I'll give it a try.
It's lunchtime here now, so it will be an hour later.
It was easy to execute, so I will just send you the results of the execution.
Everything seems to have worked this time.
fathom dragon
Yes, two units exist.
remote bloom
Have you tried running the scripts on both server?
fathom dragon
Sorry, this was a Stage environment, so there was only one server.
remote bloom
Okie, and if you try the scripts multiple times, does it still output OK?
flint kestrelBOT
fathom dragon
sure, try it now
I ran it five times and succeeded five times.
The biggest problem for us is that we use this webhook for plan cancellations and the customer's plan cancellations fail.
What is the current timeout duration?
What should we do in case of failure?
stone forge
If you're saying that the requests time out before they reach your server, i think the first step here is to check in with your host provider if you've received those requests.
The timeout duration is 20 seconds. Stripe will retry for up to 3 days with an exponential back off. Alternatively, you can also retrieve those objects / events via the API to process them
fathom dragon
@stone forge
Thank you very much.
Twenty seconds is all I need.
That's strange.
First, we will verify again if the request is really not being sent to the server.
Please take your time.
Also, currently, after a request comes in from the Webhook, we check the signature and then return 200, but that is the implementation, right?
remote bloom
Yep