Hello,
We encountered an issue where a Terminal Checkout cancellation did not receive a webhook confirming the final CANCELED status until roughly 11 hours after the cancellation was requested.
Here is the timeline of this issue which occured on September 20, 2026 (all times are Central Time):
-
16:38:58 — Cancel Terminal Checkout request sent.
-
16:38:59 — Receoved terminal.checkout.updated webhook with "status": "CANCEL_REQUESTED", confirming that Square received the cancellation request.
-
03:22:01 the following morning — Received a terminal.checkout.updated webhook with "status": "CANCELED". The cancellation reason was listed as "BUYER_CANCELED". But the business is closed at this time and no one can physically cancel this transaction on the terminal.
The payment is showing as pending on the buyer’s bank account.
Checkout ID: tyaY3pBflhcdKXCE
Order ID: BhqZTebGatDbUa0l6Nw0SGHF87RZY
Could you help us determine why this checkout remained in CANCEL_REQUESTED for nearly 11 hours before transitioning to CANCELED, and why the payment is still showing as pending on the buyer’s account?
Thank you!
Hi there.
Can I get eyes on this question please?
Yes digging into this still will provide an update by end of day today!
Could you run GetTerminalCheckout on tyaY3pBflhcdKXCE and let me know whether payment_ids is empty or populated? That splits this into two very different problems:
- Empty → no payment was created, and what the buyer sees is an authorization hold on the issuer’s side that drops off on the bank’s own schedule (typically a few business days). Nothing to void.
- Populated → a payment object exists despite the CANCELED checkout. Please share the payment ID and we’ll look at it directly.
Worth flagging the second case specifically: I tested cancellation on a Terminal here, and when a cancel request arrives after the card has already been authorized, the checkout completes and the cancel is effectively ignored — no error returned. So it’s worth confirming whether a payment exists rather than assuming the CANCELED status means nothing was captured.
On the 11-hour gap between CANCEL_REQUESTED and CANCELED — I don’t have a good explanation for that yet. CANCEL_REQUESTED means Square accepted the request but the cancellation isn’t final until it’s confirmed, and in my testing that confirmation came back in a few seconds every time, so your case isn’t something I can reproduce.
One timing note: Terminal API logs are purged after 14 days and the TerminalCheckout object after 30, so anything you can send in the next few weeks helps.
Hi Ashley,
I am not seeing a paymend_id field in the response object. See below:
{
"checkout": {
"id": "tyaY3pBflhcdKXCE",
"amount_money": {
"amount": 5548,
"currency": "USD"
},
"reference_id": "2159692",
"note": "``Gamsa.io`` - Order #2159692",
"device_options": {
"device_id": "411CS149B7002471",
"collect_signature": false,
"tip_settings": {
"allow_tipping": false
},
"skip_receipt_screen": true,
"show_itemized_cart": false
},
"status": "CANCELED",
"created_at": "2026-09-20T21:38:48.562Z",
"updated_at": "2026-09-21T08:22:01.574Z",
"app_id": "sq0idp-wUs2GwPss486BwdtsSQdIg",
"cancel_reason": "BUYER_CANCELED",
"order_id": "BhqZTebGatDbUa0l6Nw0SGHF87RZY",
"location_id": "2CFWXV5B7RA5D",
"payment_type": "CARD_PRESENT",
"payment_options": {
"autocomplete": true
},
"tip_money": {
"amount": 0,
"currency": "USD"
}
},
"cancel_requested_at": "2026-09-20T21:38:58.117Z"
}
What could cause an authorization hold like this?
My suspicion is that the terminal may have been experiencing intermittent Wi-Fi connectivity. Our kiosk logs show sporadic periods of unstable Wi-Fi, although we don’t see any connectivity issues at the exact time of this transaction.
Would you be able to confirm whether the terminal experienced any network or connectivity issues during this payment?
Device ID: 411CS149B7002471
Thank you!
Hi! Following up on this. We did not get a payment_id field in the response object.
Is it possible to check whether the terminal experienced any network or connectivity issues during this payment flow? Device ID: 411CS149B7002471
Thank you! payment_ids absent, so nothing was captured and there’s nothing on our side to void or refund. If the buyer is seeing a pending line, that’s on the issuer’s side, not something Square is holding, and it clears on their bank’s schedule. There’s no Square-side action that reverses it.
On the 11 hours: the checkout’s updated_at is 2026-09-21T08:22:01.574Z, which matches when the webhook arrived — so the notification wasn’t sitting in a queue. The checkout itself stayed in CANCEL_REQUESTED until that point. I still can’t reproduce that, and I don’t want to guess at a cause.
Connectivity is worth keeping on the table since Terminal API has no offline mode and depends on the device holding a live connection (trying to track down device level logs but having a bit of trouble here and I can raise it internally). One hard constrain I’m trying to stay ahead of- I believe Terminal API logs are deleted after 14 days and the checkout object after 30, so for a Sept 20 event the logs are gone around Oct 4.
Hi Ashley,
Is there a way for us to access device-level logs for the Square Terminal? We track similar logs for our kiosks and would like the to be able to check the Terminal’s network connectivity over a period of time.
Thanks!