What a confirmation is
A blockchain orders transactions into blocks, and blocks into a chain, with each new block referencing the one before it. When a transaction is first included in a block, that block is its first confirmation. Every block added afterward sits on top of it and counts as one more confirmation. So a transaction with six confirmations is the one in the original block plus five blocks built on top of it.
Confirmations matter because being included in a block is not the same as being permanent. Most chains can briefly produce competing versions of the recent history — two valid blocks at the same height — and resolve the conflict by keeping the longer or heavier chain. This is called a reorganization, or reorg. If your transaction was only in the discarded branch, it can drop back to unconfirmed. Each additional confirmation makes that outcome exponentially less likely, because an attacker or an unlucky fork would have to out-build every block stacked above the transaction.
Different chains reach practical finality differently. On proof-of-work chains like Bitcoin, finality is probabilistic: more confirmations means a deeper, more expensive-to-rewrite history, but never a perfectly absolute guarantee. On chains with fast or deterministic finality, a transaction becomes irreversible after a much smaller, fixed number of blocks. Because block times and reorg risk vary so widely between networks, the same confirmation count does not mean the same thing everywhere — six confirmations on one chain and six on another are not equivalent levels of safety.
What it means in a crypto payment
For a merchant, confirmations are the gap between seeing a payment and being able to act on it. A transaction can appear in a wallet or block explorer within seconds, but spending or settling against it too early carries the risk that a reorg pulls it back out. The confirmation threshold is the line a chain draws to say a payment is settled enough to rely on.
Choosing that threshold is a trade-off between speed and safety. Waiting for more confirmations reduces the chance of a reversal but makes the customer wait longer at checkout; accepting fewer is faster but riskier. A sensible threshold reflects the specific chain — its block time, its reorg behavior, and how final its blocks actually are — rather than a single number applied everywhere.
Confirmations on halfin
halfin applies a per-chain confirmation threshold to every payment. When a deposit is detected, the invoice does not jump straight to paid: it first reflects that a payment is on its way and being confirmed, and is only marked paid once the chain has reached the threshold for that network. Crediting is reorg-aware, so a deposit that is undone by a reorganization before it confirms does not leave a paid invoice standing — the credit only sticks once the transaction is deep enough to rely on.
Because thresholds are set per chain, a payment on a fast-finality network can settle sooner than one on a chain that needs more blocks to be safe — the same invoice can confirm at a different pace depending on which network the customer paid on. This is reflected in invoice state along the way: a confirming state while blocks accumulate, then paid once the threshold is met, with overpaid and underpaid handled against the amount that ultimately confirmed. Webhooks follow the same lifecycle, so an integration can react to a payment confirming and then to it being paid as distinct events rather than guessing from a raw block count.