What a payout is
Where a deposit credits a balance when money arrives, a payout debits that balance to send money away to an address the business names — a wallet on a specific chain. The amount and asset are whatever the recipient is owed: a vendor invoice, a payroll line, a partner settlement, or a refund returning money to a customer who already paid.
On a blockchain a payout is an ordinary outbound transaction: signed with the keys that control the sending balance, broadcast to the network, and included in a block. It then accumulates confirmations, and once it reaches the chain's settlement guarantee it is final and no third party can reverse it. The sender cannot undo a mistaken transfer either, which is why getting the destination and amount right before sending matters on a crypto rail.
A payout is distinct from a refund even though a refund is delivered as one: the refund is the business reason, the payout is the outbound transfer that carries it out. Every refund is a payout; not every payout is a refund.
Why it matters to a merchant
Outbound payments are where the money actually leaves, so they carry the sharpest operational risk. A wrong address, a wrong amount, or a duplicate send is irreversible once confirmed — there is no bank to call to recall the transfer. That is why a payout flow is judged less on speed than on control: who is allowed to send, what is checked before funds move, and whether a retried request can ever send the same money twice.
Two safeguards do most of the work. An approval step puts a deliberate human decision between requesting a payout and authorizing it, so the system that drafts a withdrawal is not the one that lets it leave. And an idempotency key on the create request lets a business retry a failed or timed-out call safely — the rail recognizes the key and returns the existing payout rather than sending the money twice.
Payouts on halfin
On halfin a payout is created with a single POST to /api/v1/payouts naming the currency, amount, and destination address, authenticated with an API key whose scoped permissions include payouts — or from the dashboard, with one lifecycle whichever way it starts. halfin validates the destination against the chosen chain, reserves the amount from the merchant balance so a later approval can never overdraw it, and returns the payout in pending-approval. Nothing is signed or broadcast at this point.
The payout waits in pending-approval until an operator with payout permissions releases it from the dashboard; only then does halfin sign and broadcast the transaction. Delivery then follows the chain: halfin waits for the per-chain confirmation threshold, crediting is reorg-aware so a transfer undone by a short reorganization is not reported as done, and when the threshold is met the payout reaches completed and a single payout.completed webhook fires — or payout.failed if it could not be delivered. Verify the HMAC signature on that event before acting on it.
There is one payout primitive — a single approved transfer to a single destination. A mass payout is not a separate endpoint; it is a fan-out over this same create call, one POST per recipient with its own per-line idempotency key, so every transfer is approved, delivered, and reported on its own. A payout only moves what the balance already holds, so if the balance is not in the asset the recipient needs, balance conversion rebalances the treasury first — asset-to-asset, not a fiat off-ramp — and the payout is created against the converted funds.