Auto-Approving Cancellations and Returns: What Post-Purchase Hub Does Instead

If you have just switched on self-service cancellation requests, the next question is almost always the same: can I approve the easy ones automatically? It is a fair thing to want. Reviewing forty low-value cancellations a week is not a good use of anyone’s morning.

The honest answer is that Post-Purchase Hub will not auto-approve anything, and the readme is unusually direct about it: “No, and it never will.” Here is the reasoning, and what to do instead — which, in practice, gets you most of the speed you were after.

Why nothing is approved automatically

The plugin’s position is that a cancellation request lands in a queue and nothing happens to the order until a person approves it. No rule engine, no “under fifty dollars goes through”, no exceptions. The Actions settings say the same thing twice, in the card description and again in the help text under the status checkboxes: a request is never an automatic cancellation.

The reasoning holds up. Approving a cancellation is not a data operation — it is a claim about the physical world. Has the parcel been picked? Has the label printed? Has it already left with the courier? WooCommerce order status is a decent proxy for that, but only a proxy, and the gap between the two is exactly where an automatic approval does damage: stock returned for a parcel already on a van, a customer told their order is cancelled while it is in transit to them.

The second reason is scope. The plugin never touches a payment gateway and never issues a refund; approving changes the order status and optionally restocks. An automatic approval would therefore produce a cancelled order that is still fully paid, quietly, with nobody aware of it. That is a worse outcome than a request sitting in a queue for two hours.

What the rules actually do

There is real automation on the Actions tab — it just runs at the other end of the process. Instead of deciding requests for you, the rules stop requests you would have declined from ever being submitted.

• Cancellable statuses — by far the biggest filter. An order outside the statuses you ticked never shows the button, so the request never exists. Turning an action off entirely goes further: it is removed from the customer’s pages and refused at the API as well.
• Cancellation requests per order — caps how many times one order may ever be the subject of a request.
• Wait between requests — hours before a second attempt on the same order is allowed.
• Response time you promise — hours, shown at submission and in the confirmation email. This is what stops a pending request turning into a chasing email.
• Restock on approval — the one thing that genuinely happens without you, once you have said yes.

Tighten the status list and the queue shrinks dramatically — usually more than any approval rule would have saved you, because a request that is never submitted costs nothing at all. Choosing those statuses well is the highest-leverage half hour in the whole setup.

Making the review itself fast

The remaining work is the queue, and it is built to be worked in batches rather than one email at a time. It sits at WooCommerce → Requests, with a count in the menu of everything waiting on you.

Each row carries the request number, the order, the customer, the type, the reason they chose, how long it has been waiting and its current status. Type, age and status all sort, so “oldest pending cancellations” is one click.

A routine that works for most stores:

1. Twice a day, not continuously. Once before picking starts and once after it finishes. Anything arriving between passes is covered by the response time you promised.
2. Sort by age and clear the oldest first. The complaint is almost never the decision — it is the silence before it.
3. Decide from the status, then the note. If the order has not been picked, approve. If it has, read the customer’s reason before declining, because a good reason sometimes justifies intercepting a parcel.
4. Use the internal note on anything unusual. It is never shown to the customer, and three weeks later it is the only record of why you said no.

Handled this way, a queue of forty is fifteen minutes — and unlike an inbox, it tells you at a glance whether anything is outstanding.

A sensible policy, without a rule engine

What people are really asking for when they ask about auto-approval is: how do I stop thinking about the easy cases? That is a policy question, and you can answer it without any automation.

• Write down one rule for yourself — for example, approve anything still in a pre-pick status, whatever the value.
• Decline categories rather than individual orders: custom and made-to-order items, anything already past your cut-off.
• Review the reason data monthly. It is the only structured signal you get on why people cancel, and it usually points at something fixable upstream.

Start conservative and widen as the history accumulates — which means keeping the history. On the Advanced tab, Keep resolved requests for sets how many days a resolved request survives the daily cleanup, and zero keeps everything. If you intend to review your own decisions, zero or a generous number is the setting you want.

If you genuinely need automation

Be realistic about what is on offer. The plugin ships filters throughout — the stage map, action availability, tracking detection and invoice sources are the documented ones — but there is no supported hook advertised for deciding requests, and building one means taking on precisely the responsibility the default design was avoiding. The PHP source and test suites are public on GitHub if you want to judge that for yourself. And a refund still will not happen by itself.

Where to go next

The queue only gets busy if requests are getting through, so start upstream: setting the cancellation rules first, then handling the spike during a flash sale. If you fulfil through a supplier, returns as a dropshipper covers the extra handoff that makes fast approvals harder.