Hi,
We are using the Square Reader SDK and relying on the payment.created webhook to provide the receipt url
(even though the payment created webhook doesn’t include the full receipt url we can create it using the payment_id)
to be able to print out the receipt for those customers that want printed receipts. 90% of the time this works well as the webhhook arrives within a few seconds. About 10 % of the time however the webhook will take about 60 seconds to arrive. This means customers have to wait for their receipt. 60 seconds may not sound long but it is an eternity if the customer is rushing to catch a flight or waiting in a queue.
My question is why does the webhook take so long on only some occasions? Is there anything that can be done to ensure the webhook arrives consistently fast? Is there something from our end that could be causing this 10% of the time?
Square webhook notifications typically send within 60 seconds of the associated event. Unfortunately, there isn’t anything that can be done to speed up the event delivery.
Since you get back the transaction_id from a payment at the same time you’re waiting for the webhook event you can call the Orders API with the transaction_id and get the payment_id from the order to call the Payments API to get the receipt_url.
Hi Bryan, just on this point, does it mean that if we want to get information about payments faster we should use the transaction_id to look up the payment using Orders API which would ensure there’s less of a delay compared to waiting for the webhook notification to come through? Would this be the quickest way to receive the information on payments just created/processed?
Also, is the delivery time of the webhook notification slower in the Sandbox environment as it seems sometimes it takes several minutes for the notification to come through there?
You can definitely call the Orders API with the transaction_id if the webhook is taking too long to arrive. The order won’t have the receipt_url but it will have the payment_id which you can then call GetPayment with to get the receipt_url. 
Hi @Bryan-Square I have a similar question though it may be a separate issue. I am using the payments.created webhook as a notification for orders created on the POS. I am using this because the orders.created webhook is not triggered by POS orders.
Our flow is as follows:
- Receive payment.created webhook which includes order ID
- GET retrieveOrder to retrieve order details
This works sometimes, but many times we get a 404 not found response on the retrieveOrder request. However if I then manually look up the same order using the API explorer it shows up correctly.
I found that the timestamp on our 404 not found response is before the timestamp showing on the order’s created_at field. For example an order has a created_at timestamp of 2023-01-22T22:54:37Z and our app is showing the 404 timestamp at 2023-01-22 22:54:32 (5 seconds before the order is showing as created). So the webhook containing the order ID is firing before the order can be retrieved via API.
Do you know if there is some defined logic around this delay? For now we are adding a delay on our side to add more time before making the retrieveOrder request, but it would be helpful to know if this is the expected behavior with specific logic that we can follow? Or if we should just make sure to add enough of a delay to create a buffer that will prevent the 404s.
Thanks
Hey @dan! Yes, unfortunately asynchronous operations can result in some amount of small delay in situations like this. You can work around this with a buffer as you’re doing, but I’d also recommend implementing a retry mechanism in case you ever run into longer delays than you accounted for originally.