#darcyye_webhooks
1 messages · Page 1 of 1 (latest)
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1299216452880175104
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- darcyye_api, 19 hours ago, 9 messages
Sorry to bother you, but I couldn't find any relevant information in the webhook documentation.
We don’t disclose it unfortunately, generally:
Retry behavior
In live mode, Stripe attempts to deliver a given event to your webhook endpoint for up to 3 days with an exponential back off. In the Events section of the Dashboard, you can view when the next retry will occur.
In test mode, Stripe retries three times over a few hours. You can manually retry transmitting individual events to your webhook endpoint after this time using the Events section of the Dashboard. You can also query for missed events to reconcile the data over any time period.
For example, I want to synchronize subscription status in my DB via Stripe Webhooks, inserting data into our DB only on subscription.created events and updating data only on subscription.updated events. However, I see in the documentation that the order of events is not guaranteed, so if there's no corresponding subscription record during an update, I'll return a 4xx error and wait for the webhook to retry automatically.
If the automatic retry interval is too long, it's possible that after my users pay, a subscription won't be successfully created in our DB for a period of time, thus failing to provide the corresponding service.
We only allow users to create subscriptions with checkout sessions.
I would recommend to build a queue and process that sync logic in the queue, but always instantly response 200 to Stripe webhook
Try to confirm, so the suggestion is that the WebHook receiver shouldn't return an error because of its own data logic issues, am I right?
Yes!
That makes sense
We do process webhook events asynchronously, but it's possible that the current webhook event hasn't finished processing before the next one arrives.
And since the order of events in the webhook is not guaranteed, do you have any suggestions on how to determine the dependencies between events in the queue?
Let's imagine a scenario where I have two users, A and B, checking out simultaneously. My server receives the following events sequentially: A.subscription.created (event 1) -> B.subscription.created (event 2) -> B.subscription.updated (event 3) -> A.subscription.updated (event 4). Processing begins immediately upon receiving each event. Before our server queries Stripe for data using the Stripe SDK, it doesn't know that event 3 depends on event 2 rather than event 1.
For example, I want to synchronize subscription status in my DB via Stripe Webhooks, inserting data into our DB only on subscription.created events and updating data only on subscription.updated events.
For this, you should make an API request to retrieve the relevant objects (if required) to insert the DB first. https://docs.stripe.com/webhooks#event-ordering
I've thought it over, and I think I have an idea about the problem I mentioned. Thank you for your answers.