Sandbox: inventory not decrementing + SearchOrders missing orders, refunds PENDING, PayOrder payment remains APPROVED

Questions
1

Hi Square team,

We are testing a customer ordering integration in Square Sandbox and encountered several related issues during testing on September 23–24, 2026 using API version 2026-08-19.

Our primary blocker is tracked inventory not decrementing for API-created itemized orders.

Our catalog variation has track_inventory=true, is sellable/stockable, and had an initial quantity of 20. The same location and exact catalog variation were used throughout the order, payment, and inventory flow.

We tested both delayed-capture and immediate-payment flows, including:

  • Creating an itemized order using the tracked catalog variation

  • Successfully completing/capturing its payment

  • Completing pickup fulfillment

  • In a separate test, explicitly completing both the fulfillment and order

Despite ordering quantity 2, inventory remained exactly 20, even approximately 17 hours later. Inventory change history showed only our initial physical count and its inferred adjustment, with no sale-related adjustment.

We have intentionally not added a manual inventory decrement, because we do not want to double-decrement inventory if Square is expected to handle this automatically.

We also observed three other Sandbox discrepancies during the same testing period:

1. SearchOrders: Orders remain retrievable directly by Order ID, but do not appear in SearchOrders. Removing our source filter still did not return the affected orders.

2. Refunds: Partial and full refunds against COMPLETED payments were accepted but remained PENDING approximately 17 hours later.

3. PayOrder: We created a payment with autocomplete=false, which correctly entered APPROVED. After calling PayOrder, the order became COMPLETED with zero amount due, but the linked payment continued to return APPROVED rather than COMPLETED.

We noticed other developers have reported similar SearchOrders and PENDING-refund Sandbox behavior around September 23–24, so we are wondering whether there is currently a broader Sandbox issue.

Could Square please clarify:

  1. Is there a known Sandbox incident currently affecting Orders/SearchOrders, refunds, payment-state processing, inventory processing, or related asynchronous jobs?

  2. Could such an incident explain why our tracked inventory is not receiving a sale adjustment?

  3. If not, what step is missing from our lifecycle for automatic tracked-inventory deduction?

  4. Why can our orders be retrieved directly by ID but not returned by SearchOrders?

  5. What event/state should we await before considering a refund successfully completed?

  6. Is it expected for PayOrder to complete an order while its linked payment remains APPROVED?

  7. Are there any Sandbox application permissions, seller settings, catalog settings, or account configuration we should verify?

Our inventory-tracked customer checkout implementation is currently paused pending clarification.

We have retained the affected Sandbox order IDs, payment IDs, refund IDs, location/catalog IDs, timestamps, reproduction details, and sanitized test evidence and can provide them to a Square team member if needed.

Thank you!

3

Welcome to the Developer Forum!

Thanks for the detailed explanation & questions. We are currently experiencing some issues with our sandbox environment.

  • Tracked inventory: A tracked catalog variation should decrement automatically after its itemized order is paid/completed. Your described lifecycle appears correct, so please don’t add a manual decrement, as that could later double-decrement inventory.
  • SearchOrders: This was fixed (successfully created order can be retrieved from SearchOrder or via dashboard) as of earlier this morning and the fix is from Sept 24th and onwards. We did not do a backfill so some data prior to this date still would not show up.
  • Refunds: Refunds can remain PENDING; only COMPLETED indicates success. Monitor refund.updated or poll GetPaymentRefund.
  • PayOrder: PayOrder should complete the approved delayed-capture payment.

Again, these issues are all noted and the team is looking into it. In the meanwhile, we recommend testing refund flows in a separate free production account using CASH or EXTERNAL tender types. Production accounts are free and unlimited, and refund lifecycle transitions work correctly there.