#joeyeomans
glad skiff
strong edge
Hi 👋 yes, that seems expected in this case. You used a test card for that payment that results in a Dispute being created after the charge succeeds. So both the successful payment Event and the dispute creation Event were triggered by the same request, so it is expected for them to reference the same request and it's idempotency key.
noble isle
So when I'm saving the idempotency key in my database should I also check the event type to make sure it's not a duplicate request?
strong edge
I'm not sure I'm grasping the question.
The idempotency key that is included there is not related to the Event, it is not a key for deduplicating Events. The idempotency key that is included is the same one that is provided as part of the request that was made which caused the Event to be triggered.
noble isle
This is the point I'm refering to in the docs:
Best practices for using webhooks
Review these best practices to make sure your webhooks remain secure and function well with your integration.
Handle duplicate eventsWebhook endpoints might occasionally receive the same event more than once. You can guard against duplicated event receipts by making your event processing idempotent. One way of doing this is logging the events you’ve processed, and then not processing already-logged events.
So when I get an event I store the idempotency key in my db to make sure the same event isn't processed twice
strong edge
You shouldn't rely on the idempotency key included in the Event for that, it's not guaranteed to be unique to the Event since it is associated with a request that could have generated multiple Events.
Events have unique IDs, you can use those IDs to check whether you received an Event more than once. The ID that begins with the evt_ prefix.
noble isle
Ahh okay so I can just use the event Id to do this. What is the likeyhood of an event being sent twice?
strong edge
It's hard to say. We typically only send Events a second time if the first delivery attempt fails, which we determine by either receiving a status outside of the 2XX range or if we don't receive a response at all. If your endpoint successfully acknowledges receipt of the Events that we send, then I would not expect you to receive many if any duplicate Events.