What a deposit is
On a blockchain, value moves by transaction: a payer signs and broadcasts a transaction that sends funds to a destination address. Seen from the receiving side, that incoming transaction is a deposit. The payer controls when and how much to send; the recipient controls the address it lands on, by holding the private key behind it. A deposit is therefore the moment funds arrive at an address from outside, as opposed to a transfer the recipient initiates themselves.
A deposit is not instant or final the instant it is broadcast. It first sits unconfirmed in the network's pool of pending transactions, then gets included in a block, and only becomes hard to undo as more blocks build on top of that one. Most chains can briefly produce competing versions of recent history and resolve the conflict by keeping the longer or heavier chain — a reorganization, or reorg. A deposit that was only in the discarded branch can drop back to unconfirmed, which is why a single appearance on-chain is not yet a settled deposit.
Because a deposit is just an on-chain transaction to an address, it carries the properties of the network it was sent on. It is chain-specific — a deposit on Bitcoin is unrelated to a deposit on Ethereum or Tron — and it is irreversible once deep enough, because no central party can claw back a confirmed blockchain transaction. The amount that actually arrives is whatever the payer sent, which may differ from what was expected.
What it means in a crypto payment
In a crypto payment flow, the deposit is the payment itself. A merchant's system presents a receive address, the customer sends funds to it, and the payment service watches that address for an incoming transaction. Detecting the deposit early — while it is still confirming — lets the merchant show that a payment is on its way, but acting on it too soon risks a reorg pulling it back out. The settled deposit, confirmed deeply enough to trust, is what a balance or an invoice should ultimately be credited against.
The amount a deposit carries is set by the payer, not the merchant, so a deposit can land short of or above what was expected. Against an invoice this produces underpayment or overpayment, which a payment service has to reconcile rather than assume an exact match. A deposit also needs to be matched to its destination unambiguously: the same address may receive many deposits over time, and each incoming transaction is a separate event to detect, confirm, and credit on its own.
Deposits on halfin
halfin detects deposits across the chains it supports — Bitcoin, Ethereum and its ERC-20 tokens, the EVM L2s Base, Arbitrum and Polygon, BNB Smart Chain, Tron, the XRP Ledger, and Solana with its SPL tokens. When a deposit arrives at an address, the payment does not jump straight to settled: halfin applies a per-chain confirmation threshold and credits reorg-aware, so a deposit undone by a reorganization before it confirms does not leave a paid invoice or a credited balance standing. The credit only sticks once the transaction is deep enough on its network to rely on.
Deposits drive two surfaces. Against an invoice, the amount that confirms is reconciled to what was requested — settling it, or flagging it as underpaid or overpaid — and the invoice moves through a confirming state before it is marked paid. Against a static deposit address, an incoming deposit funds a balance rather than one specific invoice, and a balance.credited webhook lets an integration react once the funds have landed and confirmed. Because thresholds are set per chain, the same deposit can settle at a different pace depending on which network the customer paid on, and a deposit that is later reversed by the chain is reflected rather than silently kept.