IN_STORE orders stuck with fulfilment COMPLETED but order state OPEN

Questions
1

Hello,

We recently started sending dine-in/table orders with the IN_STORE fulfilment type (previously PICKUP). One merchant has IN_STORE orders getting stuck: the fulfilment is COMPLETED (completed on Square KDS), but the order state stays OPEN.

This is isolated to one merchant. Our other merchants receiving IN_STORE orders aren’t affected, and we can’t reproduce it on our test account.

Merchant / integration

  • Merchant ID: ML30W1TY93E5P
  • Location ID: LKT37W1NNFW5A
  • API Version: 2026-07-15

Device setup

  • Square Register running Square for Restaurants v7.31 (QSR mode)
  • Square KDS v7.19 (Expo)
  • 2 connected printers

What’s happening

  • Orders are created via the Orders API with an IN_STORE fulfilment and paid with an OTHER tender (net_amount_due is 0)
  • Staff complete the order on Square KDS, which sets fulfilment.state to COMPLETED
  • order.state stays OPEN, so the order remains active on the POS
  • The order can’t be closed from Square POS or Square Dashboard. Square POS shows an error below.
  • PICKUP and DELIVERY orders at the same location complete normally

image
image1920×2560 498 KB

Example stuck orders

  • wyYMx4nCGLktFlapsvlh0oR1B4RZY
  • mXrlA9iWOoh7DdMjoJCf2eJxLOEZY
  • 4ygfhNDUpsiRVpLTcw4HUQ092IfZY
  • ORoGFdH0g5CDh8M2ocw5g1dsDzBZY
  • uBEATlyjdomLXdRzaxIc883MBvLZY

Relevant part of one stuck order:

“fulfillments”: [{
“uid”: “75bbb3d2-ded0-3261-bfd2-582b46969ff4”,
“type”: “IN_STORE”,
“state”: “COMPLETED”,
“in_store_details”: {
“placed_at”: “2026-10-31T06:36:29.138Z”,
“in_progress_at”: “2026-10-31T06:36:29.701Z”,
“prepared_at”: “2026-10-31T06:50:06.718Z”,
“completed_at”: “2026-10-31T18:08:35.305+11:00”
}
}],
“state”: “OPEN”,
“version”: 8,
“net_amount_due_money”: { “amount”: 0, “currency”: “AUD” }

Already tried

  • Turned on POS fulfilment methods and “Enable order tracking”
  • Reloaded/synced orders on the POS

Questions

  1. Why are these orders getting stuck with the fulfilment COMPLETED but the order OPEN, and only for this merchant?
  2. How can the orders that are already stuck be cleared?

Thanks!

3

Since this affects one location, could you check a few things against a location where IN_STORE orders complete normally?

  • KDS settings: Compare the Expo device’s Completion settings (“Complete for all devices” versus “Complete only on this device”) and Automatic Order Update setting. These are configuration checks, not confirmed fixes.
  • POS setup: Compare the assigned POS mode and POS/KDS app versions. Thanks for confirming you’ve already tried order tracking and resyncing.
  • API completion: For an affected order that is fully paid and fulfilled, have you tried UpdateOrder with order.state: "COMPLETED", the latest order version, and a new idempotency key?

If the settings match and the order still won’t close, could you share the full, redacted RetrieveOrder response for one of the examples, plus the UpdateOrder request, response, and request ID if attempted? Remove access tokens and customer information.

That would help distinguish a configuration difference from an issue needing further investigation, particularly given the server error shown in POS.

4

Hi Ashley

Thanks for the suggestions. Some more context:

Scope

  • This is now affecting 2 merchants (one with multiple locations), not just one
  • Affected setups include Square KDS v7.31 and v7.19, on both Expo and Prep devices
  • Square for Restaurants is v7.31

Only IN_STORE orders are affected
PICKUP orders from our integration complete and close normally at the same locations, on the same devices and settings. If the KDS or POS configuration was the cause, we’d expect PICKUP orders to be affected too. Since it’s specific to the IN_STORE fulfillment type, we suspect something in how IN_STORE orders are handled when the fulfillment is completed.

UpdateOrder
We haven’t tried closing the orders via UpdateOrder yet. We’d like to find the root cause before forcing the state through the API.

Example order (second merchant, redacted)
RetrieveOrder response below. Customer details have been removed.

{
“order”: {
“id”: “x1XTwG2VXuEVH37REKZUdJpgrdBZY”,
“location_id”: “LABF2NXEPPSN9”,
“line_items”: [
{
“uid”: “c31540b9-6965-455b-ab68-71f6a52d61e1”,
“catalog_object_id”: “V75FCOBYT3G5DBSZ243LPACX”,
“catalog_version”: 1793575969312,
“quantity”: “1”,
“name”: “Chilli Folded Eggs”,
“variation_name”: “Regular”,
“base_price_money”: { “amount”: 2400, “currency”: “AUD” },
“gross_sales_money”: { “amount”: 2400, “currency”: “AUD” },
“total_tax_money”: { “amount”: 219, “currency”: “AUD” },
“total_discount_money”: { “amount”: 0, “currency”: “AUD” },
“total_money”: { “amount”: 2400, “currency”: “AUD” },
“variation_total_price_money”: { “amount”: 2400, “currency”: “AUD” },
“applied_taxes”: [
{
“uid”: “23fa5ab3-2153-424b-9322-7b9ae1131e5f”,
“tax_uid”: “7e78a6b4-da0e-4831-93cf-c4dcdefba21d”,
“applied_money”: { “amount”: 219, “currency”: “AUD” }
}
],
“item_type”: “ITEM”,
“total_service_charge_money”: { “amount”: 0, “currency”: “AUD” },
“total_card_surcharge_money”: { “amount”: 0, “currency”: “AUD” }
},
{
“uid”: “467c98ee-6e63-4e0f-9c27-d44dd595c7b7”,
“catalog_object_id”: “A2CJWZFDS3Z6GCZFJOQVDDKE”,
“catalog_version”: 1793575969312,
“quantity”: “1”,
“name”: “Iced Strawberry Matcha”,
“variation_name”: “Regular”,
“base_price_money”: { “amount”: 950, “currency”: “AUD” },
“gross_sales_money”: { “amount”: 950, “currency”: “AUD” },
“total_tax_money”: { “amount”: 86, “currency”: “AUD” },
“total_discount_money”: { “amount”: 0, “currency”: “AUD” },
“total_money”: { “amount”: 950, “currency”: “AUD” },
“variation_total_price_money”: { “amount”: 950, “currency”: “AUD” },
“applied_taxes”: [
{
“uid”: “6a074d76-d04c-4994-948f-92617002b470”,
“tax_uid”: “7e78a6b4-da0e-4831-93cf-c4dcdefba21d”,
“applied_money”: { “amount”: 86, “currency”: “AUD” }
}
],
“item_type”: “ITEM”,
“total_service_charge_money”: { “amount”: 0, “currency”: “AUD” },
“total_card_surcharge_money”: { “amount”: 0, “currency”: “AUD” }
}
],
“taxes”: [
{
“uid”: “7e78a6b4-da0e-4831-93cf-c4dcdefba21d”,
“catalog_object_id”: “AUSSALESTAXML1H4598YJ6K7”,
“catalog_version”: 1785886603873,
“name”: “GST”,
“percentage”: “10.0”,
“type”: “INCLUSIVE”,
“applied_money”: { “amount”: 305, “currency”: “AUD” },
“scope”: “LINE_ITEM”,
“auto_applied”: true
}
],
“fulfillments”: [
{
“uid”: “d731e67c-48a8-3501-ae8d-e094f5137d5c”,
“type”: “IN_STORE”,
“state”: “PREPARED”,
“in_store_details”: {
“note”: “[T8] Table 8\n[REDACTED]”,
“recipient”: { “display_name”: “[Table 8] [REDACTED]” },
“placed_at”: “2026-11-02T01:15:49.283Z”,
“prepared_at”: “2026-11-02T01:21:04.409Z”,
“in_progress_at”: “2026-11-02T01:15:49.835Z”
}
}
],
“created_at”: “2026-11-02T01:15:48.544Z”,
“updated_at”: “2026-11-02T01:21:06.268Z”,
“state”: “OPEN”,
“version”: 6,
“total_tax_money”: { “amount”: 305, “currency”: “AUD” },
“total_discount_money”: { “amount”: 0, “currency”: “AUD” },
“total_tip_money”: { “amount”: 0, “currency”: “AUD” },
“total_money”: { “amount”: 3350, “currency”: “AUD” },
“tenders”: [
{
“id”: “qQw7zLZ6vJQ7ZQlmuCOktuqRUGfZY”,
“location_id”: “LABF2NXEPPSN9”,
“transaction_id”: “x1XTwG2VXuEVH37REKZUdJpgrdBZY”,
“created_at”: “2026-11-02T01:15:49Z”,
“amount_money”: { “amount”: 3350, “currency”: “AUD” },
“type”: “OTHER”,
“payment_id”: “qQw7zLZ6vJQ7ZQlmuCOktuqRUGfZY”,
“other_details”: { “source”: “[REDACTED]”, “status”: “CAPTURED” }
}
],
“total_service_charge_money”: { “amount”: 0, “currency”: “AUD” },
“net_amounts”: {
“total_money”: { “amount”: 3350, “currency”: “AUD” },
“tax_money”: { “amount”: 305, “currency”: “AUD” },
“discount_money”: { “amount”: 0, “currency”: “AUD” },
“tip_money”: { “amount”: 0, “currency”: “AUD” },
“service_charge_money”: { “amount”: 0, “currency”: “AUD” },
“card_surcharge_money”: { “amount”: 0, “currency”: “AUD” }
},
“source”: { “name”: “[REDACTED]” },
“pricing_options”: { “auto_apply_taxes”: true },
“ticket_name”: “[Table 8] [REDACTED]”,
“net_amount_due_money”: { “amount”: 0, “currency”: “AUD” },
“total_card_surcharge_money”: { “amount”: 0, “currency”: “AUD” }
}
}

Could you look into why IN_STORE orders aren’t closing when PICKUP orders on the same setup are?

Could you also please give our test environments access to Square KDS, and Square for Restaurants so we can do further testing?

Merchant IDs: ML2QP4V7B2DT1, MLNDTERP1XJQD

Thanks!

5

Hi Ashley / Square team,

I’m just following up here – we’ve had to rollback our changes to the affected clients because of this issue.

6

Hi James, thanks for the update. I’m sorry this disrupted your rollout.

The comparison with PICKUP on the same setups is useful. I also found a discrepancy: your original response shows a COMPLETED fulfillment, while the internal order record currently shows PREPARED for the matching order and version. The newer example you shared also shows PREPARED.

That doesn’t explain why the orders remain active or why POS can’t close them. This needs investigation across the order, fulfillment, and KDS history before we can confirm the cause. You don’t need to force-close the orders through UpdateOrder for us to investigate.

For the original COMPLETED response, could you share the RetrieveOrder request timestamp and response request ID, if available? Keep access tokens and customer details redacted.

For the KDS and Square for Restaurants access request, can you confirm whether those two IDs are production test seller accounts rather than Sandbox accounts?

7

Hi Ashley,

Apologies for the confusion. The example in my last reply (x1XTwG2VXuEVH37REKZUdJpgrdBZY) is a more recent order that hadn’t been completed on KDS yet when I pulled it, which is why it shows PREPARED.

Below is the RetrieveOrder response for WJ8jGnekZaVh6iPaWD02kSf4NTVZY (one of the merchant’s original reported orders), taken before we changed anything. It shows the fulfillment COMPLETED with the order still OPEN.

  • Request timestamp: 2026-11-05 08:05:44 GMT+10
  • Trace ID from the response headers: CDN-0e2f447e-db49-4b2e-a99d-3ca00eac906f

Is that the request ID you need, or is there a different one you’re talking about?

Straight after that, we updated this order to COMPLETED via UpdateOrder, as it was causing problems for the merchant:

  • Request timestamp: 2026-11-05 08:05:44 GMT+10
  • Trace ID: CDN-89be41cd-8280-4da9-90be-a2f24ba6a485
  • Result: successful API response. We’re waiting for the merchant’s staff to confirm whether it has cleared from the POS.

To confirm, the two accounts we shared are production test seller accounts, not Sandbox.

Thanks,
James

{
“order”: {
“id”: “WJ8jGnekZaVh6iPaWD02kSf4NTVZY”,
“location_id”: “LKT37W1NNFW5A”,
“line_items”: [
{
“uid”: “40457506-32a6-4b55-b74e-3b3602ae1775”,
“catalog_object_id”: “R6VSAROL44MRKZYSHNANQ54L”,
“catalog_version”: 1793253911006,
“quantity”: “1”,
“name”: “Pineapple & Pork Jowl”,
“variation_name”: “”,
“base_price_money”: { “amount”: 2900, “currency”: “AUD” },
“gross_sales_money”: { “amount”: 2900, “currency”: “AUD” },
“total_tax_money”: { “amount”: 264, “currency”: “AUD” },
“total_discount_money”: { “amount”: 0, “currency”: “AUD” },
“total_money”: { “amount”: 2900, “currency”: “AUD” },
“variation_total_price_money”: { “amount”: 2900, “currency”: “AUD” },
“applied_taxes”: [
{
“uid”: “9687b186-4bf9-4024-a84c-bfc2c181e46d”,
“tax_uid”: “2108b282-828e-4a76-af58-38084da4de48”,
“applied_money”: { “amount”: 264, “currency”: “AUD” }
}
],
“item_type”: “ITEM”,
“total_service_charge_money”: { “amount”: 0, “currency”: “AUD” },
“total_card_surcharge_money”: { “amount”: 0, “currency”: “AUD” }
}
],
“taxes”: [
{
“uid”: “2108b282-828e-4a76-af58-38084da4de48”,
“catalog_object_id”: “AUSSALESTAXML30W1TY93E5P”,
“catalog_version”: 1753830685011,
“name”: “GST”,
“percentage”: “10.0”,
“type”: “INCLUSIVE”,
“applied_money”: { “amount”: 264, “currency”: “AUD” },
“scope”: “LINE_ITEM”,
“auto_applied”: true
}
],
“fulfillments”: [
{
“uid”: “b761ab18-7a68-394b-9f96-a0c85a8cf83f”,
“type”: “IN_STORE”,
“state”: “COMPLETED”,
“in_store_details”: {
“note”: “[T3] Table 3\n[REDACTED]”,
“recipient”: { “display_name”: “[Table 3] [REDACTED]” },
“placed_at”: “2026-10-30T05:31:15.201Z”,
“completed_at”: “2026-10-30T16:45:43.193+11:00”,
“prepared_at”: “2026-10-30T05:39:38.975Z”,
“in_progress_at”: “2026-10-30T05:31:16.058Z”
}
}
],
“created_at”: “2026-10-30T05:31:14.195Z”,
“updated_at”: “2026-10-30T05:45:47.648Z”,
“state”: “OPEN”,
“version”: 8,
“total_tax_money”: { “amount”: 264, “currency”: “AUD” },
“total_discount_money”: { “amount”: 0, “currency”: “AUD” },
“total_tip_money”: { “amount”: 0, “currency”: “AUD” },
“total_money”: { “amount”: 2900, “currency”: “AUD” },
“tenders”: [
{
“id”: “qWhKVe1RX6syL7LGMcVBi1vBH2PZY”,
“location_id”: “LKT37W1NNFW5A”,
“transaction_id”: “WJ8jGnekZaVh6iPaWD02kSf4NTVZY”,
“created_at”: “2026-10-30T05:31:15Z”,
“amount_money”: { “amount”: 2900, “currency”: “AUD” },
“type”: “OTHER”,
“payment_id”: “qWhKVe1RX6syL7LGMcVBi1vBH2PZY”,
“other_details”: { “source”: “[REDACTED]”, “status”: “CAPTURED” }
}
],
“total_service_charge_money”: { “amount”: 0, “currency”: “AUD” },
“net_amounts”: {
“total_money”: { “amount”: 2900, “currency”: “AUD” },
“tax_money”: { “amount”: 264, “currency”: “AUD” },
“discount_money”: { “amount”: 0, “currency”: “AUD” },
“tip_money”: { “amount”: 0, “currency”: “AUD” },
“service_charge_money”: { “amount”: 0, “currency”: “AUD” },
“card_surcharge_money”: { “amount”: 0, “currency”: “AUD” }
},
“source”: { “name”: “[REDACTED]” },
“pricing_options”: { “auto_apply_taxes”: true },
“ticket_name”: “[Table 3] [REDACTED]”,
“net_amount_due_money”: { “amount”: 0, “currency”: “AUD” },
“total_card_surcharge_money”: { “amount”: 0, “currency”: “AUD” }
}
}

8

Hi James, thanks—those trace IDs and timestamps are useful for tracing both requests.

I’ve confirmed that your UpdateOrder request succeeded. The order is now COMPLETED at version 9, with its fulfillment also COMPLETED. Let us know once staff confirm whether it has cleared from the POS.

That confirms the API update worked for this order, but it doesn’t explain the original behavior. Your pre-change response shows COMPLETED fulfillment / OPEN order, while the internal historical record for that version shows PREPARED / OPEN. That discrepancy needs investigation; it doesn’t mean your response was incorrect.

Thanks also for confirming the two accounts are production test seller accounts. KDS and Square for Restaurants access is still outstanding; I don’t have an access update to share yet.

9

Thanks Ashley.

I think it’s related to the “Complete on this device” vs “Complete on all devices” KDS setting – I’ve just spot checked a couple venues experiencing the issue, against those without.

Once I have access to Square KDS, I can try and reproduce further.

10

Oh nice! Hopefully that’s it. Do you see an option in your account for a free trial for KDS?

11

Hi Ashley,

We got access to the Square KDS, and we were unable to reproduce using similar settings.

Has anything been fixed/changed on your side? One of our merchants is no longer experiencing the issue, and we didn’t make any changes on our side

12

I’m glad you have KDS access now and this appears to be resolved, though I don’t have a confirmed Square-side fix to explain it. I’m sorry again that this disrupted your rollout. If other sellers are still affected or the issue returns, please reply here and tag me and we can pick up from your existing examples.