Every store that takes a manual payment method ends up with a drawer full of orders that were never paid for. Someone checks out with bank transfer and forgets. A cash-on-delivery order is placed by a browser who is not really going to be home. A draft order you sent a wholesale buyer sits open for a week. Each one looks like a sale in your dashboard, each one is holding inventory, and not one of them will clear itself. The order just waits, pending, until a human notices it and decides what to do, and on a busy store that human notices late, if at all.
This is one of the most repeated requests in the merchant communities, and it always arrives the same way: someone asks how to automatically cancel and archive unpaid orders after a set number of days, or how to cancel a pending order and unblock the inventory it is sitting on. The early answers are some version of "Shopify cannot do that, you will need an app or a script." The merchant is not asking for anything exotic. They want the one thing a checkout that takes delayed payment obviously needs: a rule that gives the customer a fair chance to pay, then tidies up the order that does not. The platform running their whole business has no built-in way to apply it.
The sale was never real. The only thing that is real is the stock it is holding, and Shopify will not let it go on its own.
Why an unpaid order quietly costs you a real one
The damage is not the pending order itself. It is the inventory underneath it. When an order is placed, Shopify commits the stock to that order, and that commitment holds while the order waits in pending payment. So a unit that nobody has actually paid for is off the shelf, unavailable to the next customer who has their card out and ready. On a low-stock product, or during a launch, a handful of stale unpaid orders is enough to show a product as sold out while real, paying demand bounces off it.
The second cost is your own clarity. An orders list padded with sales that will never settle makes every number you glance at slightly wrong. Your revenue looks higher than it is, your bestseller list includes things nobody bought, and your fulfilment queue has phantom rows you have to read past. The work of telling a real order from a dead one falls on you, every day, by eye. It is exactly the kind of repetitive, judgement-light tidying that never gets done in a busy week, and the unpaid orders pile up behind everything else.
What Shopify actually does, and where it stops
Shopify is happy to take an order that is not yet paid. What it does not do is manage the waiting. The gap is the whole middle of the job: noticing the order has gone cold, nudging the customer to pay, deciding the wait is over, cancelling cleanly, and putting the stock back. It shows up in three places merchants hit fast.
First, there is no auto-cancel for unpaid orders. Shopify has no native setting that says "cancel any order still unpaid after N days." Cancelling is a manual action you perform one order at a time from the admin, choosing whether to restock and whether to notify the customer on each one. There is no timer, no batch, and no rule. If you have fifty pending orders, clearing the dead ones is fifty trips through the same menu.
Second, Flow can watch but cannot cancel. Shopify Flow, free on every plan, can react to an order being created and can tag it or send an internal note. But Flow has no action that cancels an order, so the one step that actually matters is the step it cannot take. You can build a Flow that flags an order as unpaid; you cannot build one that cancels it when the flag has been true for three days and restocks what it was holding.
Third, the timing and the judgement are on you. Even once you decide to keep on top of it, you are the one choosing how long to wait for a bank transfer versus a cash-on-delivery order, whether to chase the customer first, which orders are too valuable to cancel on a timer, and what to say when you do. Cancel too eagerly and you kill an order that was about to pay; cancel too late and the stock has been frozen for a week. The platform hands you the raw pending status and leaves every decision that makes the cleanup safe to a person and a calendar reminder.
Why the usual fixes don't hold
Once a merchant feels the pile growing, they reach for one of a few workarounds. Each gets you partway and each breaks in a familiar spot.
"I will just clear them out every Monday." Fine for the first month, when you remember and the list is short. It collapses the moment volume climbs, because now you are scanning the orders list, separating the paid from the pending, checking which of the pending ones are genuinely dead, and cancelling each by hand with restock ticked. It is slow, it is dull, and it is the first chore to slip when the week gets busy, so the stock stays frozen and the list keeps growing.
"I will set a Flow rule for it." A reasonable instinct, and Flow can genuinely help you spot the orders by tagging them. But Flow cannot cancel an order or restock its inventory, which is the entire point, so the rule gets you a tidy tag and leaves the actual cleanup exactly where it was: in your hands, one order at a time. You have automated the noticing and none of the doing.
"I will install an auto-cancel app." There are apps for precisely this, and for many stores they are a fair answer, which by itself proves the native gap is real. But most run on a single blunt rule: cancel anything unpaid after X hours, optionally restock. That is better than nothing and still misses the judgement. A flat timer treats a first-time bank transfer the same as a repeat wholesale buyer on net terms, fires off a cold cancellation with no attempt to collect the money first, and cannot tell the order that just paid sixty seconds ago from the one that is truly dead.
What the automation actually has to do
The real job is not "cancel everything unpaid after two days." It is "for each pending order, give the customer a fair, method-appropriate window and a clear way to pay, nudge them once or twice, then cancel and restock only the ones that stay cold, while never touching the order that just settled or the wholesale account you do business with." That is reading, timing, and routing, run per order across everything sitting unpaid. As a Dugong playbook, in plain prose, it reads like this:
# trigger
On each order sitting in pending payment
# steps
1. Read the order: payment method, value, and whether the
customer is new, repeat, or a known wholesale account
2. Set the window to fit the method: longer for a bank
transfer or agreed invoice, shorter for an abandoned manual checkout
3. Nudge the customer to pay, once or twice, with the
amount and a clear way to complete it
4. Recheck at the deadline that it is still unpaid, so a
late payer is never cancelled by a stale timer
5. Cancel the cold ones and restock the held inventory in
the same step, with the reason logged as unpaid
6. Tell the customer it lapsed, kindly, with a link to
reorder so the door stays open
7. Hold high-value and wholesale orders for a human, and
log every nudge, cancel, and restockSeven lines. The compiler fills in everything beneath: watching the pending status on every order, holding each for a window that fits how its payment method settles, sending a real reminder with a way to pay instead of going straight to the axe, rechecking the payment state at the last moment so the customer who paid late is left alone, then cancelling the genuinely dead ones and releasing their stock back to the shelf in one clean move, with a friendly note out to the customer and the high-value exceptions parked for a person. The merchant never sat in the orders list on a Monday sorting paid from pending. They described how a careful shop owner would handle a slow payer, and let the compiler do the volume and keep the timing fair.
Why this is a compiler problem, not an app problem
There are capable auto-cancel apps, and for many stores they are a fine answer. But the thing that makes this safe is not a single timer, it is a read of the specific order in front of you: how its payment method actually settles, whether this is a one-off browser or an account you invoice every month, whether a reminder has gone out yet, and whether the money quietly arrived while the clock was running. Those are judgements about a particular situation, weighed together, and the right move changes with each order, which means the work is never set-and-forget. It is decided fresh every time.
A natural-language compiler fits because unpaid-order cleanup was never really a cancel-button problem. It is a timing and judgement problem wearing a cancel button's clothes. Firing a blunt cancellation on a timer is the easy part, which is why apps do it. The hard part is everything around it: wait the right amount for this method, ask for the money first, confirm it is still unpaid, restock as you cancel, and keep your hands off the orders that deserve a human. You can write that brief in a paragraph. You could never hold it in your head across every pending order this week. It sits in the same family as the overselling problem no one automates, where the stock count has to stay honest in real time, and as the order change that races your warehouse, where the right move depends on reading the live state of the order before you act.
The workflow worth building this week
If you take bank transfer, cash on delivery, manual invoices, or you send draft orders, this is the automation to set up before your next restock, because every pending order is a unit of stock frozen on a sale that may never settle, and the only thing between you and clean inventory is a cleanup you keep not getting to. It pairs naturally with the inventory work we have written about, like the restock alert that never fires, where freeing held stock means the next waiting customer can actually buy it, and it feeds the same flywheel as the Shopify automations no one builds, where the work that compounds is the part merchants never get to.
Describe it the way you would brief a careful shop owner: when an order sits unpaid, give the customer a fair window for how they chose to pay, remind them once or twice with an easy way to settle, and if it stays cold, cancel it, put the stock back, send a kind note with a link to reorder, and bring me anything big or wholesale before you touch it. That is the whole brief. The compiler does the watching, the waiting, the chasing, and the restocking. You keep your attention for the orders that are real, and you stop letting paying customers bounce off stock that a dead order was sitting on.
If you are a Shopify merchant who has wired up an unpaid-order cleanup that
chases payment first and restocks as it cancels, or you have a story about
the launch that showed sold out while half the orders were dead, the inbox
is open: field-notes@dugong.live. We are collecting case
studies for the next issue.