The Stripe documentation states that it can occasionally send a webhook event multiple times:
Handle duplicate events
Webhook endpoints might occasionally receive the same event more than once. You can guard against duplicated event receipts by logging the event IDs you’ve processed, and then not processing already-logged events.
My question: What time delay should I expect between these possible duplicate events? Are we talking about seconds or hours/days?
If the delay is a few seconds at most, I could handle this problem by ignoring duplicate insert attempts (for example of an active premium subscription) in my DB. But if the delay is longer, the user could've canceled their subscription meanwhile in which case I don't want to handle a duplicate "subscription.created" event because it would falsely reinstantiate the subscription.
Stripe doesn't document any specific delay. This is more to warn against a potential edge-case to avoid bugs on your end. You can imagine a flow where they discover an issue with some Events not sent properly and reprocess that queue but it leads to some duplicate deliveries that weren't properly recorded before.
What Stripe usually recommends here is to have a database of all the Events you already processed using the Event id evt_12345 as it is unique. If you get a delivery for an Event you already processed then you can return a 200 immediately to stop retries.
This logic should be resilient to the same Event being re-sent a couple days later for example though it would be highly unlikely they would do this.