Refunds
Work through the refund queue, choose how each refund is paid out, and keep refunds within the order total.
You use the refund queue when a customer should get money back. Litestore doesn't support instant refunds of part of an order. Instead, one person raises a refund request and another person approves it. The one exception is cancelling a whole order, which refunds it in full straight away and needs the financial permission. See Orders.
Refund queue
The queue is at:
Orders → RefundsThe queue filters by status or by order.
A refund is the only action in the admin that pays money out of the business to a single customer. For that reason, Litestore splits it into a step that anyone in support can take and a step that only someone with the financial permission can take. Most of the behaviour described here exists to support that split.
Request and approval
A refund needs two separate permissions. One permission lets someone view and raise refunds, and the financial permission lets someone approve and reject them.
People with the support and manager roles can queue a refund without being able to release the money.
This means the people who talk to customers act on a complaint straight away. They add the refund to the queue with the amount they propose, and someone with the financial permission makes the decision.
Raising a refund only creates a record. No money leaves the store's account until the request is approved.
Refund limit
An order can never refund more than the customer was billed.
Litestore doesn't only check the request you're looking at. It adds the request to everything already approved on that order, so a second refund is checked against the total including the first.
Litestore enforces this limit in two independent places:
- It rejects the refund itself if approving it would go past the order total.
- The payment ledger applies the same limit each time it writes an entry.
These checks run automatically, and neither of them needs to be started by hand. Because they're independent, an over-refund could only get through if both failed on the same order at the same time.
Once an order has been fully refunded, no further refunds are possible, regardless of who requests them.
Approved amount
The approver can only pay the amount shown on the request. Approving a refund is a yes-or-no decision on an amount that was already recorded, and the approver can't change it to a different figure.
Refund methods
| Method | When you use it |
|---|---|
| Back to the original payment | The money goes back the way it came in. This is the usual choice for customers who paid by card. |
| Store credit on the customer's balance | The value stays with the store, and the customer spends it later. Store credit needs a customer on the order, because a balance has to belong to someone. A guest order with no customer record can't be settled this way. |
| Manually | You settle cash, cheques and transfers outside Litestore. The admin records that the refund happened and how much it was, and you move the money yourself. |
With the manual option, you keep a record on the order of refunds you paid outside the system. Without that record, reconciling the order later would be impossible.
Approval status
When you refund a card order to the original payment, Litestore issues the refund at the payment provider before it marks the request approved.
Because of this order, the approved status means that the provider has accepted the refund, not just that someone chose to issue it.
If the provider rejects the refund, the request remains pending and Litestore records the reason. Once you've fixed the cause, retry from the same button.
Refund locks
An order can have only one pending refund request at a time. This prevents an order from collecting overlapping requests that each look correct individually.
A refund can't be raised or approved on an order that has an open chargeback. While the bank is reviewing whether to take the money back, a refund from the store could return the same amount a second time.
A refund request is settled once
A refund request ends as approved, rejected or canceled. The database records at most one of those outcomes, so a request can never end up in a partial or unclear state.
Refund history
Each settled refund adds a new entry to the payment ledger.
Litestore never edits or deletes ledger rows. To correct a mistake, it adds another entry instead of changing an existing one, so both the incorrect refund and its correction remain visible.
If ledger rows could be edited, they wouldn't be a reliable record of what happened. Because they can't, the order's financial history stays intact, and it reads as the actual sequence of events.
Quick reference
Refund to the original payment when the customer paid by card and the money should go back to that card. This is the normal case, and it's the only method where the payment provider confirms the refund.
Use store credit when the customer plans to keep shopping with the store and would prefer credit to cash. The order must have a customer record to hold the balance.
Only use manual settlement when the money was actually paid another way and you need to record it.
If the amount is wrong, reject the request instead of trying to adjust it, since approval can't change the amount.
Before you approve a refund, keep in mind that the amount will be added to the order's permanent ledger, where it can be corrected with a new entry but never removed.
Related
Returns
A return comes back in, only resellable items go back into stock, and the refund follows.
Payments
Stripe takes the payments, the transaction ledger records them, and Litestore tracks disputes.
Disputes
Litestore tracks each chargeback against its order and blocks some actions while the dispute is open, and the evidence goes to Stripe.