Refunds

Refund requests are worked from a single queue, filtered by status or by order.

There are no instant refunds. Every request is raised first and approved second.

That is the central design decision on this page, and it is what everything else here protects. A refund is the one action in the admin that takes money out of the business on behalf of a single customer, so it is split into a step anyone in support can take and a step only a trusted person can take.

You will find the queue at:

Orders → Refunds

Raise first, approve second

Two separate permissions govern a refund.

• Viewing and raising refunds is one permission.
• Approving and rejecting is the financial permission.

Support and manager roles can queue a refund without being able to release the money.

This is what makes it safe to let the people who actually talk to customers act on a complaint immediately. They put the refund in the queue with the amount they think is right, and someone with the financial permission decides.

It also means a raised refund is a record, not a payment. Nothing has left your account because a request exists.

The ceiling on what can go out

An order can never refund more than it was billed. This deserves more than a one-line promise, because it is the guarantee that makes the whole queue trustworthy.

If two people approve two refunds on the same order at the same moment, can they together give back more than the customer paid?

No. An approval that would take the order's approved refunds past the order total is rejected outright.

The check is not run against the single request in front of you. It is run against the total of everything already approved on that order, so a second refund is measured on top of the first rather than in isolation.

The cap is enforced in two independent places:

1. The refund itself is rejected if approving it would pass the order total.
2. The payment ledger carries the same cap, applied as each ledger entry is written.

Two independent caps rather than one is the point. Neither is a check someone has to remember to run, and neither depends on the other having worked. For an over-refund to get through, both would have to fail on the same order at the same moment.

An order that has already been fully refunded therefore has nothing left to give, whoever is asking.

Approval cannot inflate the request

Approving releases the amount recorded on the request.

If a larger figure is submitted at approval time, it is clamped back down to the recorded amount.

So the number the approver sees is the number the approver can pay. The approval step is a yes-or-no on an amount that was already written down — it is not a second chance to choose a different one.

If the amount on the request is wrong, the request is wrong. Reject it and raise the right one.

Three ways to settle

A refund can be settled in one of three ways.

Back to the original payment. The money returns by the route it arrived on. This is the default expectation for a card order.

As store credit on the customer's balance. The value stays with you and the customer spends it later. Store credit needs a customer on the order, since a balance has to belong to somebody — a guest order with no customer record cannot be settled this way.

Manually. For cash, cheques, and transfers settled out of band. The admin records that the refund happened and for how much; you move the money yourself.

The manual option exists so that a refund settled outside the system is still on the order's record. A refund that happened but was never recorded is exactly the kind of gap that makes reconciliation impossible later.

Approved means the money actually moved

For a card order refunded to the original payment, the refund is issued at the payment provider before the request is marked approved.

The order of those two steps is what makes the status meaningful. Approved is not a note that someone decided to refund. It is a record that the provider took the instruction.

If the provider rejects it, the request stays pending, with the reason recorded. You retry from the same button once the cause is cleared.

The retry cannot double-refund. So a failure you are not sure about is safe to retry — the wrong response to an ambiguous error is not to guess, it is to press it again.

One at a time, and not while contested

Two rules keep the queue unambiguous.

• An order can carry only one pending refund request at a time.
• A refund cannot be raised or approved on an order with an open chargeback.

The first stops the same order accumulating overlapping proposals that each look correct on their own.

The second keeps you out of a fight you are already in. While the bank is deciding whether to take the money back, refunding it yourself risks paying the same amount twice.

The ledger keeps the history

Every settled refund is a new entry in the payment ledger.

Ledger rows are never edited or deleted. A correction is an additional entry rather than a change to an existing one.

That is a deliberate trade. It means the ledger holds mistakes as well as money — a wrong refund and its correction both stay visible.

The alternative would be a tidier ledger that cannot be trusted, because a row that can be edited proves nothing about what happened. The order's financial history stays intact, and it can be read as the sequence of events it actually was.

Choosing how to settle

Refund to the original payment when the customer paid by card and expects their money back where it came from. This is the normal case, and it is the only one where the provider confirms the movement for you.

Use store credit when the customer is staying with you and prefers the value to the cash, and when the order has a customer record to hold the balance.

Use manual settlement only when the money genuinely moved another way and the record needs to catch up with reality.

Reject rather than adjust when the amount is wrong, because approval cannot change it.

The question to ask before approving anything:

Is this amount the one I would be willing to see on the order's permanent ledger, given that it can be corrected but never erased?

Related