How it works
What we watch, and what happens when something breaks
Three detection rules, one alert per problem, and reporting built on what the payments actually did.
The gap
Two records that people assume are one
Your platform keeps a refund — the commercial fact that you decided to pay someone back. The money itself moves under a separate payment transaction, which can sit pending, or come back as a failure, hours later and silently.
Most of the time they agree, which is exactly why nobody checks. When they disagree, the order still says refunded, your books still say refunded, and the money is still in your account.
One order, two records
Your admin reads the first one. So does your accountant.
Detection
Three ways a refund quietly doesn’t happen
The refund failed outright
The gateway said no — a declined card, a balance too low to cover it, an account that has since closed. The money never left your side.
You hear straight away. Email and webhook, the moment we see it.
The refund is stuck pending
Accepted, then nothing. No error is ever reported, so nobody goes looking. This is the one that catches most stores out.
You hear after two hours. Again at twenty-four, if it is still sitting there.
No money ever moved
A refund sits on the order with no payment behind it at all. Rare, and effectively impossible to spot by hand.
You hear after thirty minutes. Long enough to rule out a slow gateway.
Refund failed on order #10428
checkout_com returned insufficient_merchant_balance two minutes after the refund was recorded.
The customer has not received £182.00.
Thresholds are yours to set. Every alert ends with the same sentence — the amount your customer has not received. It is the only number that matters at three in the morning.
Alerting
One alert per problem. Not one per check.
Monitoring tools earn their reputation for noise by re-announcing the same fault every few minutes. Each broken refund gets an identity and a lifecycle, and only real changes reach you.
Failures page you, delays email you
A failed refund goes to email and to your own systems at once. A refund that is merely slow lands in an inbox and waits.
Say “I’m on it” and it goes quiet
Acknowledging stops the alerts while the dashboard keeps tracking severity. No one gets pinged about a problem someone already owns.
Getting worse is news, staying broken isn’t
A pending refund crossing your critical threshold alerts once more. Sitting in the same state does not.
You get told when it recovers
Some refunds come good on their own. When the money finally moves, the alert closes itself and says so.
Refunded another way? It stays closed
Paid by bank transfer and closed it by hand? The transaction stays failed forever, but we never reopen your decision.
Send it wherever you work
Email out of the box, plus a signed webhook for Slack, Teams, PagerDuty, n8n or your own back office.
Reporting
Numbers a refund report cannot produce
Every analytics tool can tell you how much you refunded. Only something reading the payment underneath can tell you how much of it arrived.
Recovery rate
The share of finished refunds that actually reached the customer. A tool that counts refunds counts the failures as successes.
Gateway reliability
Which payment provider fails to return money, and how often. Something you can take to them, or act on by moving.
Time to money
How long refunds really take to reach a customer, per gateway. Not how long they took to record.
The ordinary things too
Refunded value per currency, most-refunded products, and daily trend — without adding another app.
See it against your own orders
Everything described here runs on the free plan. The difference between reading about it and knowing is one install.