How many confirmations a crypto payment needs, and why it differs by network

A crypto payment is not received the moment it is sent. The transfer first appears in the network, then gets included in a block, and only after more blocks are built on top of it does it become hard to reverse. This article explains what a confirmation is, why CryptoLike waits for a set number of them before crediting a payment, why that number differs between Bitcoin, Litecoin, Ethereum and TRON, and where to find the current threshold for each asset.

#What is a blockchain confirmation?

A confirmation is a block added to the chain on top of the block that contains a transfer. The block that includes the transfer counts as the first confirmation; each block after it adds one more. CryptoLike counts confirmations on the transfer's own network and shows them to the payer on the checkout page as "n of N confirmations", where N is the threshold of the asset.

A transfer with no confirmations yet is only a request waiting in the network to be included in a block. How long it waits depends on the network and, on Bitcoin and Litecoin, on the fee the payer's wallet attached to it. Once it is in a block, confirmations grow at the pace of the network's blocks. The glossary entry on confirmations gives the short definition.

#Why does a crypto payment wait for confirmations?

Recent blocks can be replaced. When two versions of the chain compete, the network keeps one and drops the other, and a transfer in a dropped block can disappear — this is a block reorganisation. CryptoLike waits for the asset's confirmation threshold so that a payment is credited only when such a reversal is no longer a practical risk.

That is why a CryptoLike payment has two separate stages:

• pending — the transfer was detected in the network. The payer sees "Payment detected. Waiting for confirmation.", your server receives invoice.pending, and the amount is only in your pending balance, not available yet.
• paid — the transfer reached the threshold. The funds are credited to your balance and your server receives invoice.paid. Ship the order on this status.

If a reorganisation does revert a transfer that was already confirmed, the payment is recomputed and you receive invoice.reverted: paid_amount decreases and the status is recomputed. Stop fulfilment until a new invoice.paid arrives. For payments to a static address the same case produces deposit.reverted. What happens to the statuses, the ledger and the webhooks when a block is dropped before or after the threshold is described step by step in block reorganisations explained.

#Why is the threshold different on each network?

CryptoLike sets the confirmation threshold per asset because networks differ in two ways that decide how quickly a transfer becomes hard to reverse: how often blocks are produced, and how the network makes blocks final. A block every 12 s and a block every 10 min carry different weight, and a network with explicit finality behaves differently from one where certainty only grows with every block.

• Proof of work (Bitcoin, Litecoin). Miners compete to produce blocks. There is no moment when a block is declared final; instead, each new block makes replacing the earlier ones more expensive. The threshold is a number of blocks after which a reversal is considered impractical.
• Proof of stake (Ethereum). Validators propose a block in every 12-second slot and vote on checkpoints. A finalized block cannot be reverted without destroying at least a third of all staked ETH.
• Delegated proof of stake (TRON). 27 elected super representatives take turns producing blocks every 3 s. A block becomes irreversible ("solidified") once enough of them have built on top of it, typically in about 1 minute.

Tokens follow their network: USDT and USDC on Ethereum are confirmed by Ethereum blocks, USDT on TRON by TRON blocks. That is why the same stablecoin can have different thresholds on TRON and on Ethereum — the comparison of USDT TRC20 vs ERC20 goes into the details.

Checked on 2026-09-24 against the network documentation listed in Sources.

#How many confirmations does CryptoLike require?

CryptoLike does not use one number for all assets: the confirmation threshold is set per asset in the catalogue. The current value is the confirmations field of each asset in GET /v1/currencies — "confirmations required before a deposit is credited" — and the coins catalogue shows the same number next to every asset. The checkout page shows it as "n of N confirmations".

The catalogue is public, so you can read the thresholds without an API key:

curl -s https://api.cryptolike.net/v1/currencies \
  | jq '.currencies[] | {ticker, network_name, confirmations, maintenance}'

The same threshold applies to payments (invoices) and to deposits to static addresses of the asset. Deposit webhooks carry both numbers — confirmations and required_confirmations — so your system can show progress too. Because the threshold is configuration, do not hard-code it: read it from the API when you need it.

#How long does a confirmation take?

The time for a CryptoLike payment to become paid is roughly the time until the transfer is included in a block plus the threshold multiplied by the network's block interval. The checkout page turns this into an estimate for the payer — "n of N confirmations, usually about X min" — rather than a promise, because block times vary and a transfer can wait before it is included.

Things that make the wait longer:

• A low network fee. On Bitcoin and Litecoin, a transfer with a low fee can wait longer before a miner includes it.
• Network load. Busy periods delay inclusion on every network.
• A slow block. On proof-of-work networks the 10 min and 2.5 min intervals are averages; single blocks can take much longer.

The status on the checkout page updates by itself, and the confirmation count refreshes at least every 15 s, so the payer does not need to reload the page.

#What should a merchant do while a payment is pending?

While a CryptoLike payment is pending, the transfer is visible but not yet available on your balance, so keep the order in its "awaiting payment" state and do not ship. The CMS plugins do exactly this: a detected transfer leaves the order waiting, and only invoice.paid moves it to the paid status you configured.

Three practical rules:

1. Ship on paid, not on pending. pending can still end as underpaid, or disappear in a reorganisation.
2. Handle invoice.reverted. If it arrives after you shipped, treat the order as a case for review; the plugins move such orders to a review status.
3. Read the threshold, do not assume it. Show "confirming" states from the webhook fields or from GET /v1/invoices/{id}, not from a timer of your own.

The full event list and delivery rules are in the webhooks documentation.

#Sources

Public network facts in this article were checked on 2026-09-24:

• Bitcoin developer guide: block chain and difficulty target
• Litecoin: block time and proof of work
• Ethereum blocks and slot time
• Ethereum proof-of-stake and finality
• TRON consensus: block interval and solidified blocks

#FAQ

#Is a crypto payment final once it is in a block?

No. A block can still be replaced in a reorganisation. CryptoLike keeps the payment pending until the transfer reaches the asset's confirmation threshold, and only then marks it paid and credits your balance.

#Why do confirmation thresholds differ between networks?

Networks produce blocks at different intervals — about 10 min on Bitcoin, 2.5 min on Litecoin, 12 s on Ethereum, 3 s on TRON — and make blocks final in different ways. CryptoLike therefore sets the threshold per asset and publishes it in GET /v1/currencies.

#Where can I see the threshold for a specific asset?

In the confirmations field of GET /v1/currencies, in the coins catalogue, and on the checkout page as "n of N confirmations" once the payer has chosen the asset.

#Can a paid payment change?

Only through a reversal: if a reorganisation reverts a confirmed transfer, CryptoLike recomputes the payment and sends invoice.reverted. Stop fulfilment until a new invoice.paid arrives.

#Why is my payment still pending?

The transfer is in the network but has not reached the threshold yet, or is still waiting to be included in a block — for example because of a low network fee or network load. The checkout page shows the current count; no action is needed unless the payment later becomes underpaid.