What a refund is
A refund is money a merchant returns to a customer in connection with a purchase the customer already paid for — a full cancellation, a partial credit for a missing item, or returning the surplus when someone paid more than they owed. The defining trait is that a refund is anchored to an original payment: it returns value toward the party who paid, for a stated reason, rather than being an arbitrary transfer with no origin.
In a crypto-payments setting this anchoring matters more than usual, because there is no built-in undo. A confirmed on-chain payment settles with finality; once a transaction is included in a block and has enough confirmations, no party can reverse it. So a refund cannot be the original transaction running backwards. It is a separate, fresh outbound transfer on the same network, sent because the merchant decided value is owed back. That makes a refund a deliberate operator action by definition, not something a network or a bank can force.
Refund versus chargeback and reversal
A refund is easily confused with two things it is not. A chargeback is a card-network forced reversal: a customer disputes a charge with their bank and the funds are clawed back out of the merchant's account, usually with a dispute fee. On-chain crypto settlement has no equivalent — there is no issuer to reverse a confirmed payment — so the only way money goes back to a customer is a merchant-initiated refund. A protocol-level reversal, meanwhile, is not a normal operation at all; the closest thing is a chain reorganization briefly undoing a very recent, not-yet-final transaction, which is a settlement state rather than a customer remedy.
Because the original payment stays put, a refund is a new transfer in its own right. It moves value back the way it came, and like any outbound transfer it incurs the network fee of the chain it is sent on. It is reasoned about relative to the original invoice — the refunded amount can be the whole payment or only part of it — which is what keeps the return traceable back to the sale instead of floating free.
Refunds on halfin
On halfin a refund attaches to the invoice the customer already paid. halfin recorded who paid, how much, in which asset, and on which network, and the refund inherits that context, so an operator does not re-key a destination and an amount from a support email — the refund reasons from the payment that actually happened. The same operation covers the everyday cases: a full cancellation returns the entire paid amount, a partial credit returns the value of one line item, and an overpayment is handled by returning just the surplus.
Returning money out of a balance is sensitive, so refunds run through the same control model as payouts: an operator with the right permission initiates and approves the refund, behind halfin's scoped API keys — a read-only reporting key cannot trigger one. Each refund is recorded with its actor, amount, destination, and link to the source invoice, so the audit trail runs from the sale, to the payment that settled it, to the return. For a merchant, that means returns are controlled, auditable, and easy to reconcile, while the original confirmed transaction is left untouched and final.