#darcyye_webhooks

1 messages · Page 1 of 1 (latest)

sage sedgeBOT
#

👋 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.

echo wolf
#

Sorry to bother you, but I couldn't find any relevant information in the webhook documentation.

warm gust
#

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.

echo wolf
#

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.

warm gust
#

I would recommend to build a queue and process that sync logic in the queue, but always instantly response 200 to Stripe webhook

echo wolf
#

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?

warm gust
#

Yes!

echo wolf
#

That makes sense

warm gust
sage sedgeBOT
echo wolf
#

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.

acoustic solstice
#

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

Listen to events in your Stripe account on your webhook endpoint so your integration can automatically trigger reactions.

echo wolf
#

I've thought it over, and I think I have an idea about the problem I mentioned. Thank you for your answers.