Refunds

Use the refund queue when a customer should get money back. You can filter the queue by status or by order.

Litestore has no instant refunds. Someone first raises a request, and then someone approves it.

Everything else on this page protects that rule. A refund is the one action in the admin that takes money out of the business for a single customer. Litestore therefore splits it into a step that anyone in support can take and a step that only a trusted person can take.

You'll find the queue at:

Orders → Refunds

Raise first, approve second

A refund needs two separate permissions:

• One permission lets someone view and raise refunds.
• 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 makes it safe to let the people who talk to customers act on a complaint straight away. They add the refund to the queue with the amount they think is right, and someone with the financial permission decides.

A raised refund is a record, not a payment. No money leaves your account just because a request exists.

The limit on what can go out

An order can never refund more than the customer was billed. This guarantee is what makes the whole queue trustworthy, so it is worth explaining properly.

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. Litestore rejects any approval that would take the order's approved refunds past the order total.

Litestore doesn't check only the request in front of you. It adds the request to everything already approved on that order, so it measures a second refund on top of the first.

Litestore enforces this limit in two independent places:

1. It rejects the refund itself if approving it would go past the order total.
2. The payment ledger applies the same limit each time it writes an entry.

Having two independent limits is the point. Nobody has to remember to run either check, and neither depends on the other working. An over-refund could only get through if both failed on the same order at the same moment.

Once an order has been fully refunded, there is nothing left to give back, whoever asks.

Approval can't raise the amount

Approving a refund pays out the amount recorded on the request.

If someone submits a larger figure when approving, Litestore lowers it back to the recorded amount.

The amount the approver sees is the amount the approver can pay. Approval is a yes or no on an amount that was already written down. It isn't a chance to choose a different one.

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

Three ways to pay a refund

You can settle a refund in one of three ways.

Back to the original payment. The money goes back the way it came in. Customers who paid by card usually expect this.

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, because a balance has to belong to someone. You can't settle a guest order with no customer record this way.

Manually. Use this for cash, cheques and transfers that you settle outside Litestore. The admin records that the refund happened and how much it was, and you move the money yourself.

The manual option keeps a refund that you paid outside the system on the order's record. A refund that happened but was never recorded makes reconciliation impossible later.

Approved means the money actually moved

When you refund a card order to the original payment, Litestore issues the refund at the payment provider before it marks the request approved.

That order of steps is what gives the status its meaning. Approved doesn't just mean someone decided to refund. It means the provider accepted the instruction.

If the provider rejects the refund, the request stays pending and Litestore records the reason. Once you've fixed the cause, retry from the same button.

A retry can't refund twice. If you're unsure whether a refund failed, it is safe to retry. Don't guess after an unclear error. Press the button again.

One at a time, and not during a chargeback

Two rules keep the queue clear:

• An order can have only one pending refund request at a time.
• Nobody can raise or approve a refund on an order that has an open chargeback.

The first rule stops an order from collecting overlapping requests that each look correct on their own.

The second rule keeps you from paying twice. While the bank decides whether to take the money back, a refund from you could return the same amount a second time.

The ledger keeps the 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.

This is a deliberate choice. The ledger keeps mistakes as well as money, so both a wrong refund and its correction stay visible.

A tidier ledger with editable rows couldn't be trusted, because an editable row proves nothing about what happened. With this approach, the order's financial history stays intact, and you can read it as the sequence of events that actually took place.

Choosing how to pay a refund

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

Use store credit when the customer is staying with you and would rather have credit than cash. The order must have a customer record to hold the balance.

Use manual settlement only when the money really did move another way and the record needs to catch up.

If the amount is wrong, reject the request instead of trying to adjust it, because approval can't change the amount.

Before you approve anything, ask yourself:

Would I be happy to see this amount on the order's permanent ledger, knowing it can be corrected but never erased?

Related