I’ve seen this topic was actually opened in 2021, but it seems the same problem is ongoing.
I’m an AI developer, and I want to get payments in my chatbot. In a nutshell, I create a payment link and send it to the customer. I listen to the payment.updated webhook event. However, I receive multiple posts for the same payment. I planned to create some additional code to differentiate these posts by looking at the payment_id, but 2 or 3 posts occur in less than a second. This makes it impossible to filter them out. This is a really annoying problem for developers. It means I cannot take any payment using this webhook. I really don’t know how this problem was not solved before. I need help with this. I have one more problem, but I’ll open a new topic for that.
Hello!
Handling multiple webhook posts for the same payment event in your chatbot integration can be resolved by implementing idempotency keys. These keys ensure that duplicate webhook events are processed only once by generating unique identifiers for each payment request. Additionally, configure your webhook endpoint to handle retries effectively and consider implementing rate limiting to manage bursts of webhook notifications. Monitoring incoming webhook logs and contacting your payment gateway provider for support can provide further insights and adjustments to prevent duplicate posts and stabilize your payment processing workflow.
payment.updated webhook posts contain a “version” field which is the best way to differentiate posts and work out which is the latest.
The problem with using the idempotent “event_id” or “id” fields is that you can’t tell easily which is the final version, especially if one or more occur in a second, or if they arrive out of sequence which is possible.
To be fair, as of June 2024, this isn’t documented correctly, but this is what is posted to your webhook endpoint. Best thing is to save a few posts and you’ll see what I mean.
I’ve solved this issue by using id in the head. event_id changes for every webhook post. so it does not solve the issue. but there is an “id” in the payment.updated webhook head. You can use that to differentiate the same webhooks.