#sow - idempotent webhook events
limber sun
In some cases there are situations where we do generate multiple events with different event IDs for the same action (.e.g setupintent.succeeded). Because of this you would need to configure your server logic to prevent multiple updates based on these events.
lusty comet
Thanks. so in server what exactly we need to look for tracking?
limber sun
well you don't want to update the customer's default payment method over and over, right?
lusty comet
yes, ie just one scenario, we have many other scenarios to update our own db based on the stripe webhook events. We are looking for a best unique ID per events to make sure that it won't be processed multiple times.
limber sun
Well because we cannot guarantee we won't generate multiple event IDs, you will need to determine the necessary logic on your server.
Perhaps you could track the Object ID (Customer, PaymentMethod, etc) and the data to be changed.
lusty comet
hmm ok, I was referring this doc, and it says, external_id and assume it is event_id https://www.bigbinary.com/handling-stripe-subscriptions/handling-stripe-webhooks
limber sun
Using the event ID will work 99% of the time
In the case of attaching the same payment method, it doesn't seem like that would cause any harmful problems.
So simply processing each unique event ID only once would avoid almost all repeated webhook requests.
lusty comet
Do you have reference of how your other customers are handling to achieve 100% idempotency
if we design our system with event_id as a key and if it is not giving surety for 100% , I am thinking any alternate aproach we need to consider
limber sun
Most merchants use event ID to handle idempotency. However to achieve 100% idempotency you will need to build custom logic that examines the IDs of all objects involved and checks whether that change has occurred previously.
lusty comet
Got it , thanks for the details.
Can I get a reference to the event_id from the underliner data object ?