How Many Confirmations Before a Crypto Payment Is Safe?

The honest answer to how many confirmations a crypto payment needs is that it depends on two things: which chain the money arrived on, and how much the order is worth. One confirmation is plenty for a $10 digital download paid in USDT on Tron. A $5,000 pallet that leaves your warehouse on a truck and was paid in Bitcoin deserves several blocks. "Safe" is not a constant you can look up in a table and forget — it is a risk decision, made once per network and per product type, and then encoded into your checkout so nobody has to think about it again.

What a confirmation actually is

A confirmation is a block. That is the whole concept. When a buyer hits send, their transaction is broadcast to the network and sits in the mempool, a waiting room of unmined transactions. When a miner or validator includes it in a block, you have one confirmation. Every block built on top of that one adds another.

Nothing about your transaction gets more "verified" by the second block. It was already valid or it was not. What changes is the cost of erasing it. To reverse a transaction that is buried under blocks, an attacker has to build a competing chain that does not contain it and make that chain longer than the honest one. Each additional block roughly multiplies the work required, so the probability of a successful reversal falls off a cliff rather than a slope. Six blocks on Bitcoin is not magic — it is just the depth at which the arithmetic stopped being interesting to anyone, and the number stuck.

Zero confirmations and the double-spend risk

A transaction in the mempool is a promise, not a payment. It is a signed message saying "I intend to move these coins," which the network has seen but not yet committed to. It can be replaced, evicted, or simply never mined.

The specific mechanism worth understanding is Replace-By-Fee. On Bitcoin, a sender can broadcast a transaction paying you, then broadcast a second transaction that spends the same inputs back to themselves with a higher fee. Miners are economically rational and take the higher fee. Your payment evaporates while the buyer walks away with the goods. This is not a theoretical attack; it is a feature of the protocol working exactly as designed, and it takes no special skill to run.

• RBF replacement — the same coins are re-spent elsewhere with a higher fee before anyone mines your version.
• Fee starvation — an underpriced transaction sits in the mempool for hours and eventually gets dropped by nodes.
• Chain reorganisation — rare and shallow on major chains, but real. A one-block reorg quietly un-confirms a one-confirmation payment.

Zero-conf is defensible in exactly one situation: when you can undo delivery. If the customer is buying a software licence you can revoke, or an account credit you control, accepting on sight is a reasonable trade for a better user experience. If the thing being delivered leaves your hands permanently, wait for a block.

Probabilistic finality versus near-deterministic finality

Not every chain treats "final" the same way, and this is where most confirmation advice goes wrong by pretending Bitcoin's rules are universal.

Probabilistic chains

Bitcoin, Litecoin, Dogecoin and Bitcoin Cash never declare a transaction final. They give you a probability that approaches one. Bitcoin's ten-minute average block time is also an average, not a schedule — blocks arrive on a Poisson distribution, so a "one confirmation" wait might be ninety seconds or it might be forty minutes. Ethereum sits in the middle: blocks land every twelve seconds, but proof-of-stake adds an explicit finalisation step that takes roughly two epochs, about thirteen minutes, after which reversal requires slashing a third of the total stake.

Fast-finality chains

TON (which Payora brands as Gram), Solana, XRP and Stellar reach something much closer to deterministic finality in seconds. A validated XRP ledger is done. A finalised Solana slot is done. Tron uses a middle path: blocks appear every three seconds, and once roughly nineteen have been signed by a supermajority of super representatives the block is marked solidified and will not be reorganised. That is why USDT on Tron feels instant at checkout while the same token on Bitcoin-era thinking would feel glacial.

How many confirmations per network in practice

These are sensible defaults for a merchant, not laws of physics. Wait times are approximate because block times vary.

Scale the threshold to value and reversibility

The question is never "is this payment safe" in the abstract. It is "what does an attacker gain, and what does the attack cost." Reversing a Bitcoin transaction one block deep means out-mining the network briefly, which is expensive. Nobody spends that to steal a $9 ebook. So the sane model has two axes: how much money is on the table, and whether you can claw the delivery back.

1. Digital and revocable, any value — licences, downloads, account credit, hosting. One confirmation, or zero if you are comfortable revoking. Your recourse is the kill switch.
2. Under ~$100, physical — one confirmation on any chain in the table. The attack costs more than the loot.
3. $100–$1,000, physical — the chain's normal threshold: 2–3 on Bitcoin, solidified on Tron, finalised on Solana.
4. Over ~$1,000, irreversible — go to 6 on Bitcoin and full finality elsewhere. The extra forty minutes costs you nothing; a reversed pallet costs you the pallet.
5. Anything shipped same-day — treat the confirmation gate as the gate on the picking slip, not on the order confirmation email.

Notice what is absent from that list: chargebacks. A confirmed on-chain payment cannot be pulled back by the buyer's bank ninety days later, which is a genuinely different risk shape from cards. Confirmations are the only window you have to worry about, and it closes in minutes. That is the trade discussed in more depth in accepting payments without a merchant account.

How Payora decides a payment is final

Payora gates every coin on that coin's own finality rule rather than applying one number across twenty assets. Bitcoin is counted in blocks. Tron waits for solidification. TON waits on the masterchain. Solana waits for a finalised slot. Only once the rule for that specific asset is satisfied does your server receive the signed invoice.paid webhook — HMAC-SHA256, timestamp window, idempotency key — so the merchant is never the one guessing whether a payment has settled. If you want the verification code, it is in the docs and walked through in the webhook signature article.

Amounts that do not match are not silently dropped. If a buyer sends 0.0009 BTC against a 0.001 BTC invoice, or sends 0.002 by mistake, both the under-payment and the over-payment are recorded in an append-only ledger against that invoice. You decide the policy — top-up, partial fulfilment, refund — with the real number in front of you instead of a rounding error. The coins are confirming into an address Payora generated for this invoice alone, so nothing gets mixed up with another payment. The confirmation counter is the only thing between the buyer's send and money you already control.

Sensible defaults ship with the free CMS modules for WooCommerce, PrestaShop, Magento 2 and eighteen other platforms, so a small shop can install, keep the defaults, and be right on day one. You can also watch the gate work on the live checkout demo.

Pick your thresholds once, write them down, and let the gateway enforce them. Create a free Payora account and see how each network reports finality against a real invoice — accepting is 0%, and the fees for moving money out (1.5% on the Free plan plus the network fee, $50 minimum withdrawal) are on pricing.