A customer returns one item from a three-item order paid partly by gift card. How much do you refund and to what?

Five things have to be unwound, not one

The instinct is that a refund is a payment run backwards. It is not, and every part of the original transaction has to be reversed separately.

The promotion. If the three items qualified for a multi-buy or a basket-threshold discount, removing one may mean the remaining two no longer qualify. The refund is the difference between what was paid and what the remaining basket is worth, not the returned item's price.

The tax. Recalculated on the new basket total rather than taken as a proportion of the refund, because rounding is applied per line and per rate, and because in some jurisdictions the rate depends on the composition of the order.

The tender. The order was paid with a gift card and a card. Refunding all of it to the card hands the customer cash for stored value, which is a fraud vector and usually against policy.

The shipping. Whether outbound delivery is refunded depends on why the item came back — a change of mind and a faulty item are treated differently, and in some jurisdictions the difference is a legal one rather than a policy choice.

The goods. Physically received, inspected, graded, and either restocked or disposed of, which is a separate flow from the money and does not necessarily happen at the same time.

Worked, because the arithmetic is the answer

Original order
  3 x shirt @ 20.00                              60.00
  promotion "buy 3, pay for 2"                  -20.00
  subtotal                                       40.00
  tax at 20%                                      8.00
  delivery                                        3.99
  total                                          51.99
  tendered   gift card 15.00 + card 36.99

Customer returns one shirt (change of mind)

  Remaining basket: 2 x shirt @ 20.00            40.00
    promotion no longer qualifies                 0.00
  subtotal                                       40.00
  tax at 20%                                      8.00
  delivery (not refunded, change of mind)         3.99
  what they should now have paid                 51.99

  Refund due                                      0.00

The customer returns an item and receives nothing, because the promotion they lose is worth exactly what the item was. This is correct, it is deeply counter-intuitive to the customer, and the support team needs the explanation on screen — which is only possible if the discount was attributed at line level when the order was priced.

Change one assumption — the promotion was a flat 10% rather than a multi-buy — and the answer becomes a partial refund, because the remaining basket still qualifies. The rule cannot be inferred at return time; it has to have been recorded.

Split tender needs a stated order

With two tenders there is a policy question, and it should be answered once rather than per case.

The conventional order refunds stored value first — gift card, store credit, loyalty balance — and only then the card. It prevents converting non-cash value into cash, and it is what most retailers do.

The customer usually does not get to choose, and the reason is that letting them choose is the exploit.

There is a second-order case worth naming: the refund exceeds what was put on one tender, so it spans both. Apportioning proportionally is the usual rule and it needs to be stated, because the alternative — refund the card fully, then the gift card — produces the outcome you were trying to avoid.

The original authorisation has probably expired

The mechanical constraint that surprises people building this.

A payment has two stages: an authorisation that holds funds, and a capture that takes them. Before capture you can void, which releases the hold and is clean — no money moved, nothing appears on the customer's statement.

After capture, and after the authorisation's validity window has passed, there is nothing to void. The money is a completed transaction, and returning it is a refund: a new movement, referencing the original, settling on its own timeline, appearing separately on the customer's statement, and typically taking days to arrive.

Two consequences. The customer sees the deduction and the credit as two entries rather than one that vanished, which generates contacts. And a refund can fail independently — an expired card, a closed account — so the system needs a state for "refund attempted and rejected" and a fallback, which is usually store credit or a manual payout.

There is also a window in some payment schemes where a partial capture or a partial reversal is possible before settlement, which is cheaper and faster than a refund. Whether you can use it depends on the provider and on how long ago the order shipped, and a good implementation prefers it when available rather than always issuing a refund.

Money and goods move on different clocks

The last design decision: when does the customer get their money?

On receipt at the warehouse is fast and generous, and pays out before anyone has confirmed that what came back is what went out.

On grading, after inspection, is safer and slower, and the delay is the single largest driver of returns-related contacts.

On dispatch of the return, using carrier scan data, is the fastest and carries the most risk.

Most retailers choose by value and by customer history, which means the rule is configurable rather than fixed. Whichever is chosen, the state model needs the intermediate states to exist — return_authorised, in_transit, received, graded, refunded — because collapsing them means nobody can answer "where is my refund", and that question is the most common contact in the whole flow.

Grading also decides what happens to the goods: back to sellable stock, to a discounted channel, or written off. That decision has an inventory consequence and a financial one, and it is not the same event as the refund.

A refund unwinds a priced basket rather than reversing a payment. The item price is almost never the answer, and the promotion is the reason.