Refunds
A refund is a record against an order, with lines naming what is being refunded and why.
Where to find it
Architect Panel → Commercial:
- Carts — the cart itself and its options
Architect Panel → Data:
- Datastores — then View Data on the cart table, and look for the row actions
The structure
- The refund — against an order, with notes and a status.
- Refund lines — each naming an order line, a reason and its own status.
- Refund payments — how the money went back, with method, reference, amount and currency.
Three levels because refunds are rarely simple: part of an order, for different reasons, sometimes returned by more than one route.
Reasons are defined, not typed
Refund reasons are a list you maintain — arrived damaged, wrong item received, and whatever else your business sees. Choosing from a list rather than typing is what makes refunds analysable.
Which is the point: refund reasons are the cheapest quality data you will ever collect. A supplier whose products arrive damaged, a product whose description misleads, a picking process that sends the wrong thing — all of it is visible in the reasons, and invisible in free text.
Keep the list short and distinct
Six or seven reasons that clearly differ. A long list means people pick the first plausible one, and the data stops meaning anything.
Refund per line, not per order
Even when refunding everything. Line-level refunds tell you which product had the problem; an order-level refund tells you an order was refunded, which is much less useful.
The payment record matters
Recording how the money went back — method, reference, amount — is what lets finance reconcile refunds against the gateway. Without it, a refund in the shop and a refund in the payment provider are two facts nobody can connect.
Decide who can refund
Refunding is giving money away, and the permission to do it should be deliberate. Most shops want a value threshold above which a second person is involved.
Refunds and stock
A refunded item may or may not come back into stock — damaged goods do not. Decide the rule and apply it consistently, because stock that quietly includes returned damaged items is stock you cannot sell.
Read the reasons monthly
Not the refund total. The total tells you what it cost; the reasons tell you what to fix, and fixing the cause is the only thing that reduces the total.
Worked example
A shop refunds line by line against a list of six reasons, recording the return payment reference each time. A monthly review of reasons showed a third of damage refunds came from one product line, which turned out to be packaged inadequately; changing the packaging removed most of them.
Recommendations
- Refund per line, always, with a reason.
- Six or seven distinct reasons, no more.
- Record the return payment so finance can reconcile.
- Review reasons monthly, not just totals.