What a reorg is
A blockchain is a chain of blocks where each block points back to the one before it. At any moment, more than one valid block can be produced at the same height — two miners or validators can extend the chain at nearly the same time, each unaware of the other. For a short window the network then holds competing versions of recent history. The protocol resolves the split by picking one branch as canonical — typically the longest or heaviest chain — and discarding the rest.
When the network switches from the branch it had been following to a different one, that is a reorganization. The blocks on the abandoned branch are orphaned: they were once part of the chain and are no longer. Any transaction that was included only in an orphaned block is no longer confirmed. It usually returns to the pending pool and can be mined again into a later block, but until then it has effectively un-settled.
Most reorgs are shallow — one or two blocks deep — and happen routinely near the tip of the chain, which is exactly why a transaction in the most recent block is the least safe. The deeper a transaction is buried under later blocks, the more work an attacker or an unlucky natural fork would have to redo to dislodge it, so the probability of it being reorged away falls off sharply with each additional block on top. Chains with fast or deterministic finality bound reorgs to a small, fixed depth; probabilistic chains like Bitcoin never make a transaction perfectly irreversible, only progressively harder to reverse.
Why it matters for a crypto payment
For a merchant, a reorg is the reason that seeing a payment in a block is not the same as having been paid. If you treat a transaction as settled the instant it appears, a reorg that orphans its block leaves you having shipped an order against money that quietly reverted to unconfirmed — and may never be re-mined if the sender does not rebroadcast. Reorgs are the specific failure mode that confirmation thresholds exist to defend against.
The defense is to wait. Each confirmation — each block stacked on top of the one containing the payment — makes a reorg that would undo it exponentially less likely. A sensible payment system does not act on a deposit until it is deep enough that a reorg reaching it is improbable for that particular chain, and it stays ready to walk back a credit if a reorg does strike before that depth is reached.
Reorgs on halfin
halfin credits deposits reorg-aware. When a deposit is first detected, the invoice does not jump to paid — it reflects that a payment is on its way and being confirmed while blocks accumulate, and is only marked paid once the chain has reached the confirmation threshold for that network. If a reorg orphans the block that carried the deposit before it is settled, the credit does not stand: the invoice does not get stranded in a paid state on the strength of a transaction the chain has since dropped.
Because thresholds are tuned per chain, the depth at which a deposit is safe from reorgs differs by network — a fast-finality chain can settle sooner than one that needs more blocks to bury a payment out of reorg range. This is reflected in invoice state along the way: a confirming state while blocks build, then paid once the threshold is met. A deposit that is reversed by a reorg after it had begun confirming surfaces as a distinct event rather than silently disappearing, so an integration can react to a reversal as deliberately as it reacts to a payment, instead of inferring it from a raw block count.