I’m trying to use the terminal.checkout.updated webhook to verify a payment has been completed so I can complete the order within our system. This is working well except I am receiving 2 requests with “COMPLETED” status instead of 1.
The payloads are identical except the event_id and updated_at. Is this expected?
What’s your application ID and the
event_ids of the duplicates?
event_ids: 3ff0a2fb-1e39-4aa8-8f36-46bb3bdb706f, 764a5862-2535-448c-82f7-327765fbed3b
application id: sq0idp-ppT0KyxA7k6c6Om1zURr8g
I’m asking the team about this cause it looks like the only thing that updated was the
Were you able to find anything out? Thanks!
The team is still looking into this. It appears that the only think that’s changed is the
@Bryan-Square I’ve tested this again and I think i’ve found what’s happening. On the terminal after the payment is successful the first webhook fires with the “COMPLETED” status. The terminal then prompts for a receipt and after selecting one of the options (or letting the screen timeout.) a second “COMPLETED” status webhook fires.
Since the two webhooks can potentially fire very close to one another there could be a race condition when trying to complete the order within our system. Do you have any idea how to get around this issue? It seems like something that would happen frequently.
I am seeing the exact same behavior. My transactions are configured to skip receipts, but i too am receiving dups (2 events exactly), only difference between the two payloads is event_id and updated_at. @Bryan-Square is it possible to get some clarification ? Seems like this has taken a very long time to yield limited progress.
I was able to replicate this and am checking with the team.
The fix for the duplicate events has gone out. Let us know if your still running into this.
@Bryan-Square hi there Bryan - I’m having a similar issue with webhook duplicate. The application ID is sq0idp-H0WvEPgT-OioqAXp_S1qlA & the event ID is 0f4c036d-c86c-375f-b4c0-23c12e819079. The affected events have around a 4-5 second difference between the Triggered at & Sent at timestamps. Any ideas on what might be causing this?
I took a look at your Webhook Logs and I see some failed deliveries. Are the duplicates that your referencing retries? Are you responding with a
2xx within 10 seconds?
I don’t think the duplicates that are being referenced are retries. Here’s another event ID that triggered duplicate webhook events: 3bbcf9dd-ed72-3606-9dd8-f01b492a6863
I’ve also attached a screenshot from what I’m seeing on Make of the two scenario runs.
It doesn’t seem the issue is the 200 success code not being sent back to Square (triggering a retry) because in both the scenario logs in the screenshot, the last module fires successfully sending the 200 success code back to Square - since the webhook was completed successfully, it shouldn’t do anything further like sending a retry?
Any idea on what might be triggering the duplicate webhook events? Thanks in advance!
I took a look at the API logs for that event and we only sent one webhook for that event. There wasn’t a duplicate or a retry sent. Do you have any examples where there’s a duplicate in our logs that we provide?
Hi Bryan, thanks for getting back to me. Can’t say that I can provide such an example - any ideas on why some events have around a 4 second difference between triggered at & sent at timestamps? Whenever this occurs, I’m getting duplicates on the Make platform end.
Is there a reason that you can’t provide an example? According to the logs in your Developer Dashboard everything look correct and there aren’t any duplicates. If were to further investigate this I’ll need some examples so the team can look into this.