WooCommerce Orders Auto-Cancelling? Causes & Fix

Orders come in, sit on Pending payment, and then cancel themselves — often almost exactly an hour later, and often after the customer has already paid. This isn't WooCommerce misbehaving. It's a timer doing precisely what it was told. Here's how to find out what it's racing against.

Last updated: 16 Jul 2026 · ~6 min read

What auto-cancelling actually is

When stock management is on, WooCommerce reserves stock for unpaid orders — but not forever. The Hold stock (minutes) setting decides how long. Past that, a scheduled job sweeps up pending orders created through checkout and cancels them, releasing the stock back to the shop. Default: 60 minutes.

That's sensible behaviour for abandoned carts, and quietly catastrophic when payment confirmation is delayed. The customer paid, their bank is happy, and their order says Cancelled — because from WooCommerce's side, nothing ever confirmed the money arrived, and the hour ran out. The timer isn't the bug. It's just the thing holding the knife.

The most common causes (most likely first)

1. The hold stock window expires before the gateway confirmation landsThe order was paid, but the webhook or IPN was slow, retried, or arrived after the sweep. Tell: cancelled orders whose age at cancellation is suspiciously close to your hold stock value — and a successful charge sitting in the gateway dashboard for an order marked Cancelled.
2. The confirmation never arrives at allA broken Stripe webhook or PayPal IPN means the order was never going to move off pending, and hold stock simply executes it on schedule. Tell: it's every order through one gateway, not the occasional one, and the gateway's webhook log shows failures.
3. The payment method is legitimately slower than the windowDelayed and asynchronous methods — SEPA Direct Debit, iDEAL, Klarna, Multibanco, Boleto, bank transfer — can take hours or days to confirm. A 60-minute window guarantees they cancel. Tell: only certain payment methods are affected, and they cancel with mechanical regularity.
4. Hold stock is set far too low, or overriddenSomeone set it to 5 or 10 minutes, or a plugin filters the value. Tell: orders die within minutes of checkout — far too fast to be a webhook race. Check the field itself before you check anything else.
5. Something other than WooCommerce is cancelling themAbandoned-cart, order-cleanup, fraud-screening and inventory plugins all cancel orders on their own schedules. Tell: the order note names a plugin or a user rather than reading like WooCommerce's own automatic cancellation — and the timing doesn't match your hold stock value at all.
6. A cron backlog fires the sweep in burstsWordPress cron only runs when the site gets traffic, so on a quiet store the cancel job can sit and then run late — cancelling a batch of orders in one clump. Tell: cancellations arrive in bursts rather than steadily, and WooCommerce → Status → Scheduled Actions shows overdue jobs.

Where to look first

• Open WooCommerce → Settings → Products → Inventory and read Hold stock (minutes). Note the number — it's the stopwatch every other clue gets measured against.
• Open a cancelled order and compare its creation time to its cancellation time. Gap matching your hold stock value? That's cause 1, 2 or 3. Nothing like it? Something else is cancelling them (cause 5).
• Check your gateway dashboard for the same order. A successful charge behind a cancelled order means the customer paid and you must recover the order manually — and it confirms the race, not the timer, is the problem.
• Is it every order through one gateway, or occasional ones? Every order points at a dead webhook (cause 2). Occasional ones point at a slow one (cause 1). Only certain payment methods points at cause 3.
• Read the cancelled order's notes. WooCommerce's own automatic cancellation reads differently from a plugin's or a person's — the note tells you who pulled the trigger.

How to know you fixed it

Frequently asked