#nicolas-fernandez-falco_webhooks
slender tuskBOT
👋 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/1267521355528667157
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
tough folio
Hi! I'm working with the Payment Intents webhooks. I'm adding some logic to prevent processing the same webhook event multiple times. I was wondering which is the best approach. I was thinking of using either the EventId or the idempotency_key value. What would you recommend?
dry marsh
Hi 👋
The Event object has a unique ID so you could start with that. Another option is to use the Payment Intent ID and keep local store of the actions you have taken with it.
So, for instance, if you are shipping out physical goods for every successful payment intent, you would store the Payment Intent ID in your own records and if you got a duplicate payment_intent.succeeded you could look up that payment intent ID and see you had already processed it.
let me know if that makes sense
tough folio
I don't think the payment Intent ID is the proper identifier to determine if an event was already proccesed or not. A payment Intent could have multiple differents events so the Id would not be a safe way to determine that
dry marsh
That entirely depends on how you are implementing your business logic. But I can understand that. So your main concern is repeat delivery of the same event object?
In that case using the EventID is your best resource to identify webhook events you have already processed.
tough folio
Yes, Let's say that for some reason the event was triggered multiple times, I just making sure I dont' perform actions multiple times
You don't suggest using idempotency_key>?
dry marsh
If you mean the request.idempotency_key property https://docs.stripe.com/api/events/object?lang=python#event_object-request-idempotency_key, then I would point out that this will be null for any events that were not directly caused by an API request (e.g. subscription renewal)
tough folio
Yes, I'm refering to request.idempotency_key
That was my only concer. The null value. But at least for all the events triggered by Stripe related to PaymentIntents they have the request.idempotency_key
dry marsh
Yes. For this kind of scenario I do recommend building complete end-to-end testing scripts that will allow you to verify the behavior for all potential use cases. But your reasoning is sound.
tough folio
EventId should work pretty same as idempotency_key anyways right?
Meaning that if a payment intent A trigers two times same failed event, those two events will have the same eventID and if the same paymentIntent triggeres a processing event it will have a different eventId
dry marsh
Correct. The one caveat about EventID vs idempotency key is that a single API request can trigger multiple different events.
For instance the same API request can trigger payment_intent.succeeded and charge.succeeded events and those events would have different event IDs but the same idempotency key
slender tuskBOT