A blockchain deposit is not a fact when you first see it. It is a proposal the chain can still retract.
Most integrations treat the node callback as an event: transaction seen, balance credited, user notified. That holds until the chain reorganises, until the provider replays the same transaction after a reconnect, or until a pending transaction gets replaced with a higher fee.
We keep the deposit as its own record with its own state machine, separate from the balance: seen, confirmed to a depth, credited, and, because this state has to exist, reversed. Crediting becomes a transition rather than a side effect of receiving a webhook.
Two details carry most of the weight.
Confirmation depth is a risk policy, not a constant in a config file. Small amounts can move on shallow confirmation, and amounts that change your exposure wait longer. Same chain, different thresholds, decided by the people who own the risk rather than by whoever wrote the listener.
The reversal path has to be designed on day one. A deposit that disappears after being credited is not a rare exception you handle later, it is what happens when a probabilistic ledger meets a deterministic one.
We have built custodial wallets and on-chain payment flows through three market cycles, and the pattern holds: the hard part was never watching the chain. It is deciding at which point what you saw becomes money.
That line between seen and spendable is a number, and someone in your organisation owns it.