#Min.K
formal geode
unique topaz
hello! The timing for the retries depends on a variety of factors and might change. That's why we don't specify the exact timing. Is there a reason why you need the exact timing?
If you need to resend the events in test mode, you can always manually resend them via the Dashboard so that you don't have to wait for the retry
you can do the same in livemode too
fathom swallow
@unique topaz
Thank you for your reply.
I'm curious about the approximate retry interval for both production and development environments.
I know it can change, but can you give me a rough idea? Thank you.
I ask because I'm wondering if we should develop a scheduler that continuously calls the event API to read events if the interval is longer than we think.
We want to know about the retry interval because if there are network issues or other problems, a long retry interval can lead to a flood of customer inquiries because customers have paid but not received their goods.
unique topaz
i don't know what's the current retry schedule off the top of my head, but it's something you can test out if you really need to know.
Regarding the potential problem you're trying to prevent, i wouldn't attempt to depend / predict the retry intervals. The way I would go about it is to list all events for that particular day (or interval) and verify each event against what you have already received, if it hasn't been received and/or processed, you can process them
fathom swallow
My company is currently in the process of signing a Stripe contract.
We're not able to test in production yet, so I was wondering if you could shed some light on the retry interval for production?
The company is called Hyeprconnect and is part of the Match Group. I understand that we are currently in the final stages of finalizing an agreement with Stripe.
unique topaz
I don't have the exact timings but based off what I've observed in the past, the first retry is typically very fast, usually within half an hour (if not minutes). However, like I've mentioned, you should never rely on anything specific happening other than the guarantee we will retry since we occasionally change the behaviour based on what we observe
You don't need to wait for your company to set up an account. You can also register a Stripe account for your own personal use to test
fathom swallow
If it's less than 30 minutes, that's enough time to get a complaint from the customer if it fails temporarily.
What do you think about creating a scheduler that calls Stripe's Event search API called List all event if the retry interval is too long? I'm wondering if this is something Stripe recommends?
unique topaz
lets take a step back, can you describe the scenario here which you're trying to prevent? And also describe the ideal scenario (in the situation there's no problem)
right now, we're trying to work off a vague description which makes it difficult for me to provide more detailed advice
e.g. your customer buys something on your site, you show them a status page (which displays success / pending ) and if it's successful, your item is going to get shipped immediately? If it's pending, your customer will immediately complain? Is there an SLA which you're committed to?
fathom swallow
I'm sorry. Let me explain the scenario in more detail.
ALEX is playing a mobile game and purchases an item that can be used in the game. However, the payment is complete, but the game item hasn't been delivered after 10 minutes. Angry, ALEX complains to the help desk that the item hasn't been delivered.
This is the same situation as above.
In general, communication in a networked environment can fail at any time. Even if our system doesn't fail, the CDN company providing the network could fail, or a shark could eat the network cable in the ocean, causing communication to be lost.
So even if our system isn't failing, there could be network issues. A retry interval of 30 minutes is long enough to generate customer complaints.
unique topaz
what i would suggest is to build your system such that when your customer successfully pays, the app makes a call to your backend to check the status of the payment and process the order. Your server will also listen for the event, if the order hasn't yet been processed, process it. For either of these steps, you would want to first check if the order has already been processed before
this way you have a "backup" in place
fathom swallow
Since there is a limit on API calls per account, we want to do as much as possible on an asynchronous processing basis, receiving and processing webhook events.
So I was wondering if we could use the Event list lookup API to reduce the retry interval for webhook events.
unique topaz
listing the event won't reduce the retry interval
we only recognize that the event has been successfully delivered when your server responds with 2XX
fathom swallow
I'm not fluent in English, so I'll keep my questions as short as possible.
Last question.
To compensate for the long webhook event retry interval, is it okay to constantly call the List all event API through the scheduler to look up and process missed events? (https://stripe.com/docs/api/events/list)
unique topaz
yes, you can call the list all event API to look up and process missed events