Returns

Returns, refund requests, and chargebacks are separate records with separate states.

The separation is deliberate. Goods coming back, money going out, and a bank reversing a payment are three different events, and they do not always happen together. A customer can send an item back and be refused a refund. A refund can be paid without anything being sent back. A chargeback can arrive with neither.

Keeping them apart means each one can be approved, rejected, or left open on its own, and none of them silently drags the others along.

Three records, three states

A return moves from requested to one of:

approved
rejected
canceled

A refund request reaches exactly one of the same three outcomes.

A chargeback is not something you move at all — it is written into the admin by your payment provider.

Five records carry all of this:

Return
ReturnItem
RefundRequest
RefundRequestItem
PaymentDispute

The item records are why a return and a refund can each cover part of an order rather than all of it.

The important word in both cases is exactly one. A refund request ends as approved, rejected, or canceled, and the store refuses to record a second outcome on top of the first.

Returns behave the same way, because rejected and canceled are terminal. A settled return cannot be re-approved into a second refund — not by a mis-click, not by two people working the queue at once, and not by someone reopening it a month later.

Raising a return

A return starts one of two ways: the customer requests it, or you raise it against the order yourself.

Two rules constrain what can go on it.

• An order can have only one active return at a time.
• Only delivered units that have not already been returned can go on it.

The second rule is what stops the same unit being returned twice and refunded twice.

Approving a return does not restock it

Approval is a decision. Receipt is a fact.

Restocking happens when you mark an approved return received, not when you approve it. Until the goods are in your hands, an approved return has changed nothing about what you can sell.

That ordering keeps your stock figures honest. If restocking happened at approval, every return a customer never actually posted would leave you with phantom units you cannot pick.

When you do mark it received, units go back to the location the order shipped from, and each one leaves a movement in the stock ledger. The ledger entry is what lets you explain later why the count changed.

What goes back on the sellable shelf

Not everything that comes back can be sold again.

A returned line whose recorded condition reads as any of these is not put back on the sellable shelf:

damaged
used
broken
worn

Variants you do not track stock for are not restocked either, since there is no count for them to return to.

So the condition you record at receipt is not paperwork. It is the decision about whether that unit re-enters your sellable inventory.

Receipt proposes the refund, it does not pay it

Marking a return received raises a pending refund request for the returned value.

That request is a proposal. It still has to be approved by someone with the financial permission before any money moves.

Sometimes the order cannot take a refund at that moment:

• There is an open chargeback on it
• It has already been fully refunded
• A refund request is already pending on it

In those cases the receipt still succeeds and the proposal is skipped. The goods are recorded as back and restocked as normal; only the automatic refund proposal is left out. You are never blocked from receiving stock because of a money problem on the order.

Those two permissions are the reason a support agent can do the whole return without ever being able to release money. They take the goods in, restock them, and leave a request behind for someone else to settle.

The ceiling on refunds

Approved refunds on an order can never add up to more than the order total.

This is not a check in the interface that a stubborn sequence of clicks could get around. The store itself refuses to record a refund that would push the order past what it was billed.

It holds across separate refunds, across separate returns, and across two people approving at the same moment, because the limit is checked against the running total on the order rather than against the one request in front of you.

Chargebacks on the record

A chargeback is stored against its order with:

• Its status
• Its amount
• Its evidence deadline

It can also be assigned to a member of your team, so an open dispute has an owner rather than sitting in a queue everyone assumes someone else is watching.

When the totals disagree

An order carries stored totals, and it also has a payment ledger listing what actually moved.

Those two should always agree. If they ever do not, the order is listed by the OrderMoneyDrift alarm.

That alarm exists so a reconciliation problem is something the store tells you about, rather than something you find at the end of the quarter.

Which record do I need

Use a return when goods are coming back and you need to decide what re-enters stock.

Use a refund request when money needs to go back, whether or not anything was shipped back — receipt raises one for you, and you can raise one directly for cases where nothing is being returned.

Use the chargeback record only to track a dispute your provider has already opened. You cannot start one here, and you do not resolve it here.

When money and stock both need to move, do them in that order: receive the goods, then settle the money. The full path is:

1. A customer requests a return, or you raise one against the order. An order can have only one active return at a time, and only delivered units that have not already been returned can go on it.
2. You approve or reject it, then mark it received when the goods arrive — restocking what is resellable and proposing a refund for the returned value.
3. An admin with the financial permission approves, rejects, or cancels the refund request — once. Money and stock move together and the order totals stay reconciled.

The rule underneath all of it:

Every one of these records settles exactly once, so the state you leave an order in is the state you will find it in.

Related