How On-Chain Stablecoin Settlement Works: Confirmation, Finality, Reconciliation

On-chain stablecoin settlement works by generating a unique deposit address per invoice, watching the blockchain for a confirmed transfer of the exact invoiced amount, treating it as final once the chain's finality threshold is reached, and reconciling it back to the invoice via webhooks. There is no intermediary ledger and no payout step — the on-chain transfer is the settlement. Finality ranges from sub-second on Solana to ~12 seconds on Ethereum to probabilistic finality on Bitcoin.

We build Settlematic, a non-custodial stablecoin invoicing and payment gateway. This is a technical explainer of how settlement, confirmation, and reconciliation work under the hood. Figures are sourced to Ethereum and Solana documentation and to Circle and Tether transparency pages, verified 7 September 2026.

The four stages of on-chain settlement

A non-custodial stablecoin payment moves through four stages, each of which a gateway must handle correctly:

• Issuance — a unique deposit address is generated and cryptographically bound to a settlement destination the merchant controls.
• Detection — the gateway watches the chain for a transaction to that address and reads the amount and token contract.
• Confirmation — the gateway waits for the chain's finality threshold before treating the transfer as final.
• Reconciliation — the confirmed transfer is matched to the invoice, the invoice is marked PAID, and a webhook is fired to the merchant's systems.

Stage 1: Address-bound issuance

Every invoice or checkout session gets a unique deposit address. In Settlematic, that address is cryptographically bound at issuance to a settlement wallet the merchant configures — cold storage, an operating wallet, or a multisig. The binding happens at issuance, not at payment time, which means the gateway cannot redirect an address after the invoice is created, and it never holds the private keys. This is the core of non-custodial settlement: the address is a deterministic pointer to the merchant's own wallet. For the security model in detail, see our address-bound settlement explainer.

Stage 2: On-chain detection

Once the customer broadcasts a transaction, the gateway watches the mempool and the chain for a transfer to the bound address. For ERC-20 tokens like USDC and USDT, detection means reading the token contract's Transfer event for the relevant address and amount. For native assets like ETH, it means reading the transaction value directly. The gateway records the transaction hash, the amount, the token contract, the sending address, and the block number.

Because each address is single-use and bound to one invoice, attribution is unambiguous: any transfer that lands at that address belongs to that invoice. This is what makes reconciliation reliable without a central ledger. For the deeper confirmation mechanics, see our on-chain payment confirmation guide.

Stage 3: Finality and confirmation thresholds

Finality is the point at which a confirmed block can no longer be reorganized out of the chain. Each network has a different finality model, and a gateway must apply a threshold appropriate to the chain and the payment value:

The practical implication: a USDC payment on Solana can be treated as settled in under a second, while a high-value Bitcoin payment may warrant several confirmations (tens of minutes) before being treated as final. Settlematic applies per-chain thresholds and can be configured for higher confirmation requirements on high-value invoices.

Stage 4: Reconciliation and webhooks

Once the chain's finality threshold is reached, the gateway reconciles the confirmed transfer against the invoice. It compares the received amount to the invoiced amount, handles partial payments and overpayments explicitly, marks the invoice PAID, and fires a webhook to the merchant's ERP, accounting, or backend system. The webhook payload typically includes the invoice ID, transaction hash, amount, token, network, sender address, and timestamp — everything an accounting system needs to record the receipt without manual entry.

Because the address is bound to the invoice at issuance, reconciliation does not depend on a memo field, a reference number, or a manual match. The address itself is the reference. For the integration patterns, see our crypto payment webhooks and reconciliation guide.

Why this beats a custodial ledger

A custodial processor receives the payment at a controlled address, credits an internal ledger entry to the merchant, and pays the merchant out on a batch schedule (daily or weekly). The merchant's "balance" is a claim against the processor, not an asset the merchant owns, and it can be frozen, delayed, or lost in insolvency. On-chain non-custodial settlement removes that layer: the on-chain transfer is the settlement, the funds are owned by the merchant the moment finality is reached, and there is no payout step to delay or freeze. Reserves backing the stablecoins themselves are attested by the issuers — Circle for USDC and EURC, Tether for USDT.

Edge cases a gateway must handle

• Underpayments — the confirmed amount is less than the invoice; the invoice stays partially paid or unpaid and the merchant decides whether to accept or chase the balance.
• Overpayments — the confirmed amount exceeds the invoice; flagged for manual handling and an outbound refund.
• Wrong-token or wrong-chain payments — a transfer to the address in an asset or on a chain not enabled for that invoice; flagged, since the address is single-use and the gateway can detect the mismatch.
• Stale rate locks — if the customer pays after the rate-lock window expires, the quoted crypto amount may no longer match the fiat invoice; the gateway recomputes and flags for review.
• Chain reorganizations — rare on final chains, but the gateway must wait for finality before marking PAID to avoid crediting a transaction that gets reorged out.

How Settlematic implements this

Settlematic supports USDC, USDT, and EURC across Ethereum, Polygon, BSC, Solana, and Tron (plus Bitcoin for BTC). Every invoice or checkout address is bound at issuance to a settlement wallet you control. We detect confirmation, apply per-chain finality thresholds, reconcile the amount against the invoice, and fire webhooks — without ever holding keys or interim balances. Pricing is a flat subscription with no percentage of volume. For the product surface, see how it works and Gateway.

Getting started

• Configure a settlement wallet (cold storage, operating wallet, or multisig) and connect it in Settlematic.
• Enable the stablecoins and chains you want to accept on your invoices or checkout sessions.
• Run a real invoice end to end in the sandbox and inspect the webhook payload before going live.

Test on-chain settlement end to end in the free sandbox, or check pricing for current plan limits. Finality figures sourced from Ethereum and Solana documentation; reserve figures from Circle and Tether, verified 7 September 2026; protocols evolve.