Home/Methods

E-commerce · Customer service

How to catch refunds that were promised but never paid: a refund watchdog for customer service

A refund watchdog is a read-only report that finds customers who are owed money the store never returned: card orders cancelled without a refund, and accepted returns that were sent to payment but never paid. It runs two plain rules against the order and return records and lists the oldest cases first. Our worst refund failure was a refund button that had never worked while every ticket showed as refunded.

Updated 2026-10-11

What a promised-but-unexecuted refund is

A promised-but-unexecuted refund is a case where the customer paid, or was told they would be repaid, and the money never went back. You catch these cases with a refund watchdog: a scheduled, read-only query that compares what the records say should have been refunded with what was actually refunded, and lists every gap with its age.

Of all customer service failures, an unpaid refund is the one we treat as the most expensive, because a single case can turn into a complaint to the consumer authority, a card chargeback and a 1-star review at the same time. A slow reply annoys a customer; money taken and not returned gives the customer a formal reason to escalate. The failure is also quiet: nothing breaks, the order looks closed, and the customer is the only party who notices.

Rule 1: card orders that were cancelled but never refunded

The first rule looks at orders paid by card. An order is flagged when all four conditions hold: the order is cancelled, the payment gateway is the card gateway, the financial status is still paid, and the total refunded is zero. The money was captured, the order was voided, and nothing went back.

The age of each case is counted in days from the cancellation. The store is derived from the order number prefix, so one report covers every store.

In practice this rule catches orders that customer service cancelled by hand without also pressing refund in the store admin. Cancelling and refunding are two separate actions in most e-commerce platforms, and an agent under time pressure can do the first and forget the second. The watchdog exists for exactly that leak.

Rule 2: returns that were accepted but never paid

The second rule looks at return requests in the return management system. A return is flagged when it carries a refund amount above zero, its status is one of awaiting refund, delivered, in progress or new, and there is no payment date, the paid amount is zero and no payment record exists.

Awaiting refund is the most severe status. In that state the customer has sent the goods back and the refund has been confirmed and sent to payment. Any delay there is direct exposure, so those cases come first.

The age is counted from the moment the return was sent to payment. When that date is missing, the watchdog falls back to the delivery date of the returned parcel, then the approval date, then the creation date, so every case gets an age instead of being silently skipped.

Step 3: rank, filter and work the oldest first

The watchdog prints each case with the order, the customer, the source (card or return), the status and the age, groups the cases by store and puts the oldest at the top. It can be filtered by store, by rule, or by minimum age, for example only cases older than 7 days, and it can emit machine-readable output for a morning briefing.

The watchdog writes nothing. The watchdog does not refund, does not change statuses and does not contact customers. A person opens each case, checks it in the payment system and pays it. Keeping the detector read-only means it can run on a schedule without anyone worrying about what it might do.

The same idea reaches the support inbox. Our reply-drafting engine treats "refund promised but not executed" as an escalation reason: the customer gets only a short holding reply, the ticket gets high priority, and a human handles the money.

What the watchdog must not flag: refused cash-on-delivery orders

A cash-on-delivery order that the customer refused at the door is not a refund case. The store never collected the money, so recording a refund creates a repayment that never happened: the order shows as refunded and the reports subtract money that was never received. The watchdog's first rule only looks at card payments for that reason.

We made this mistake by hand. A manual script of ours cancelled 9 refused cash-on-delivery orders with the refund option switched on, and 3 of them recorded a real refund. A refund cannot be deleted from the order history afterwards. The automated path in our order system already cancelled refusals without a refund; the error was in a script written by hand. The rule we keep: when repairing something manually, copy the parameters from the automated path instead of reinventing them.

The order of operations matters as well. A refused parcel is first marked fulfilled with its tracking number, then cancelled without a refund and tagged as refused. Done the other way round, the order can no longer be fulfilled and the evidence that the goods left the warehouse is lost.

Where we were wrong: the refund button that never worked

Our return system had a button that refunded the card and closed the return ticket in one step. The audit log showed that the button had created 0 refunds, ever. The button sent the system's internal line-item identifier where the payment platform expects its own global identifier, the platform rejected the request, and a try/catch that only logged the error swallowed it. The ticket moved on as refunded.

The exposure was small only by luck: 3 tickets, all tests made on the day the feature went live, all marked paid and closed while the card refund had failed. Each had to be checked by hand. A second bug sat behind the first: once refunds went through, the button refunded the amount the platform suggested instead of the amount the agent had entered.

The fix changed the order of steps. The refund is now sent first; only if the payment platform confirms it is the payment recorded and the ticket closed. If the refund fails, the error is raised and the return stays in its previous status. On a path that moves money, never swallow an error. A catch block that only logs can hide a feature that does not work at all.

A related watchdog taught the same lesson from another side. A check for cash-on-delivery orders that the customer also paid by card caught a case in time, but a timeout on an earlier case in the same loop killed the script before it reached it; by the next run the parcel had shipped. Each case is now isolated, so one slow item cannot sacrifice the items after it, and the timeout went from 120 to 300 seconds.

Limits

The watchdog sees only refunds that the records know about. A refund promised in a chat message, with no return request and no cancelled card order behind it, is invisible to it; that is why the drafting engine escalates such messages to a person.

The card rule requires a total refunded of zero, so a partial refund that is smaller than what was owed is not flagged. The return rule covers only the store that keeps its returns in a structured return system. The watchdog finds cases after they happen; it does not stop an agent from cancelling without refunding.

Checklist

Flag card orders that are cancelled, still paid and have nothing refunded. Flag returns with a refund amount owed, no payment date, no paid amount and no payment record. Put awaiting-refund cases first and sort by age. Keep the watchdog read-only. Never record a refund on a refused cash-on-delivery order. On any money path, refund first and close after, and let failures raise. Isolate each case in a loop so one failure cannot hide the next.

Questions and answers

How do I find refunds that were promised but never paid?

Run two read-only checks. First, find card orders that are cancelled, still have the financial status paid and have zero refunded. Second, find return requests with a refund amount owed that have no payment date, no paid amount and no payment record. List each case with its age, put returns awaiting refund first, and have a person check and pay each one.

Why is an unpaid refund worse than a slow customer service reply?

A slow reply annoys a customer, but money taken and not returned gives the customer formal reasons to escalate: a complaint to the consumer authority, a card chargeback and a 1-star review, often all at once. The failure is also quiet, because the order looks closed in the store and the customer is the only one who notices.

Should a refused cash-on-delivery order be refunded?

No. With cash on delivery the store never received the money, so a refund records a repayment that did not happen and the reports subtract revenue that was never collected. The correct sequence is to mark the parcel fulfilled with its tracking number, then cancel the order without a refund and tag it as refused. A recorded refund cannot be deleted afterwards.

Why do cancelled card orders end up without a refund?

In most e-commerce platforms cancelling an order and refunding the payment are two separate actions. An agent who cancels by hand can forget the refund, and the order then shows as cancelled while the money stays captured. A refund watchdog catches exactly that combination: cancelled, still paid, zero refunded.

How can a refund button fail without anyone noticing?

If the code catches the payment platform's error, logs it and carries on, the ticket moves to refunded while no money moves. Ours had created zero refunds since launch because it sent the wrong kind of line-item identifier. The fix is to send the refund first, record the payment and close the ticket only after the platform confirms, and let any failure stop the step.

All methods