What finality means
When a transaction is included in a block it is recorded, but recording is not the same as being permanent. Most chains can briefly produce competing versions of their most recent history — for example two valid blocks at the same height — and then resolve the conflict by keeping one branch and discarding the other. This is a reorganization, or reorg. A transaction that was only in the discarded branch drops back to unconfirmed and may never make it onto the canonical chain. Finality is the moment past which that can no longer happen: the transaction is settled and the network will not unwind it.
Chains reach finality in two broad ways. Under probabilistic finality — used by proof-of-work chains such as Bitcoin — a transaction is never absolutely irreversible, but each additional block built on top of it makes a rewrite exponentially more expensive and less likely. In practice the chain is treated as final once enough confirmations have accumulated that reversing it is economically infeasible. Under deterministic finality, used by many proof-of-stake and BFT-style chains, a transaction becomes irreversible once a specific consensus condition is met — often after a small, fixed number of blocks or a defined checkpoint — and is not expected to be reorganized after that.
Because the mechanism and the speed differ so widely, the same block depth does not mean the same thing on every network. A handful of blocks may represent strong finality on a fast-finality chain and weak, easily-reorged history on another. Finality is therefore a per-chain property, not a single universal number.
What it means in a crypto payment
For a merchant, finality is the line between seeing a payment and being able to rely on it. A deposit can appear in a wallet or block explorer within seconds, but acting on it — settling, fulfilling an order, releasing goods — before it is final carries the risk that a reorg pulls the transaction back out and the money disappears. Waiting for finality is what makes a received payment safe to treat as money in hand.
Each network sets its own bar. A chain with fast, deterministic finality lets a payment settle sooner, while a chain that relies on confirmation depth needs more blocks before the same payment is safe to accept. Picking how long to wait is a trade-off between checkout speed and reversal risk, and a sensible policy reflects the actual finality characteristics of the chain the customer paid on rather than one number applied everywhere.
Finality on halfin
halfin treats a payment as settled only once it has reached finality for the network it arrived on. A detected deposit does not jump straight to paid: the invoice first reflects that a payment is on its way and being confirmed, and is marked paid once the chain has reached the per-chain confirmation threshold that stands in for finality on that network. Crediting is reorg-aware, so a deposit undone by a reorganization before it is final does not leave a paid invoice behind — the credit only sticks once the transaction is deep enough to rely on.
Because thresholds are tuned per chain, the same invoice can reach finality at a different pace depending on which network was used to pay it — a fast-finality chain can confirm sooner than one that needs more blocks to be safe. The invoice lifecycle reflects this: a confirming state while the transaction approaches finality, then paid once it is reached, with overpaid and underpaid evaluated against the amount that ultimately settled. Webhooks follow the same path, emitting a confirming event and then a paid event, so an integration can wait for finality rather than reacting to a raw block count.