What zero confirmation crypto payments are, why they stall, the double-spend risk, and a practical way for merchants to decide when to accept one and when to wait.
A zero-confirmation payment is a crypto transaction that has been broadcast to the network but not yet included in a block. The money is visible, but the network has not locked it in. For a merchant, the question is simple: do you hand over the goods now, or wait? The answer depends on the amount, the coin, the customer and what you are selling. This guide explains the mechanics, the real risk, and a decision framework you can apply today.
When a customer pays in crypto, their wallet signs a transaction and sends it to the network. Nodes relay it, and it waits for a miner to include it in a block. Until that happens, the transaction is initiated and broadcast but not yet verified in a block, which is exactly what zero confirmations means.
Once a miner does include it, the transaction has one confirmation. Each block added afterward gives it another. Bitcoin.org says the first confirmation typically arrives within 10 to 60 minutes. More confirmations mean more blocks sit on top of your payment, and rewriting that history gets harder with each one.
So the confirmation count is a measure of how hard a payment would be to undo. Zero is the weakest state, one is better, and the common convention for large transfers is six. That number is an industry habit, not a protocol rule: it simply gives a comfortable safety margin at a tolerable wait.
If you want the vocabulary of coins, networks and confirmations laid out for checkout, see our explainer on coins, networks and confirmations.
Most zero-conf situations are not attacks. They are traffic and fees.
A payment may stay unconfirmed if the network is congested or the sender attached a fee lower than what miners currently prioritize. In that case the transaction waits in the mempool, the holding area for valid but unmined transactions, until a miner picks it up.
Three practical consequences follow:
This is why a good checkout shows the payer a clear status: detected, confirming, completed. It also explains many support tickets that begin with a customer insisting they already paid. If you are tuning the experience, our piece on fixing crypto checkout fees and abandonment covers the friction points.
The danger of accepting a payment at zero confirmations is the double-spend. The Bitcoin Developer Guide describes it plainly: a malicious sender can create a second transaction spending the same input, and only one will be added to the blockchain. If the version that reaches the chain is the one paying the attacker’s own wallet, you have shipped goods for nothing.
The same guide adds that fraudsters can try to manipulate the network so their own version of the transaction is included, which is why it treats zero-confirmation payments as generally untrustworthy without risk analysis.
Bitcoin Magazine makes a related point: zero-conf transactions may be technically valid, but they are not secured by consensus until a miner includes them in a block. And for lightweight wallets, Bitcoin.org’s guidance is that zero confirmations are only safe if you trust the specific person paying you.
Double-spending is not free for the attacker, and it is not a universal threat. It needs technical skill, timing and a target worth the effort. That is why the risk scales with value and with how fast you release the goods:
The merchant’s real exposure is the gap between releasing value and the payment becoming hard to reverse. Shrink the gap or the value, and the risk shrinks with it.
You may see “zero-conf” used for Lightning channels too. That is a different trust model. Lightning Dev Kit’s documentation explains that zero-confirmation channels require trusting your peer not to double-spend, and that they are controversial for putting trust into a system built to be trustless. Do not confuse that with accepting an ordinary on-chain payment at zero confirmations.
The Bitcoin Developer Guide gives merchants a few concrete tools. You can use Bitcoin Core RPCs to check a transaction’s confirmation score and compare unconfirmed transactions across peers to spot double-spend attempts. It also notes that third-party services can add risk analysis by monitoring peers for conflicting transactions or tracking fees to estimate confirmation time.
In practice, a merchant or payment team looks at a handful of signals:
| Signal | What it tells you | Action |
|---|---|---|
| Fee level relative to current network demand | How soon a miner is likely to include it | Low fee: expect a delay, do not release high-value goods |
| Conflicting transaction seen on the network | Possible double-spend attempt | Stop, refuse release until confirmed |
| Order value | How much you lose if it fails | Higher value: require more confirmations |
| Customer history | Whether you have a track record | Known customer: more flexibility |
| Reversibility of what you deliver | Whether you can claw back access or goods | Revocable access: lower risk |
The guide’s own advice for a delayed or suspicious payment is to compare unconfirmed transactions across peers, refuse payment until confirmation, and use human judgment to flag high-risk customers. Human review sounds old-fashioned, but it works. Many risk-minded teams borrow habits from card acceptance too, such as assessing transaction risk before accepting payment: look at the customer, the order and the pattern, not just the payment rail.
One structural habit also helps. Give each invoice its own deposit address, so a payment can be matched to an order without ambiguity. We explain why in one address per invoice.
There is no universal rule, and nobody can promise zero-conf is safe. What follows is the way we suggest merchants think about it, not a protocol standard. Adjust it to your margins and your fraud tolerance.
Instant and revocable (SaaS access, game credits you can claw back, a license key you can disable) is the lowest-risk category. Instant and irrevocable (a downloadable file, a gift code) is medium. Physical shipping, services rendered or anything you cannot recover is highest.
Pick amounts that match your loss tolerance. A typical structure looks like this:
| Order value | Suggested approach |
|---|---|
| Small, such as a few dollars | Release on detection if the fee is reasonable and the goods are low cost |
| Medium | Wait for at least one confirmation, or release only revocable access |
| Large | Wait for multiple confirmations before shipping or delivering anything irreversible |
The thresholds are yours to set. What matters is that you set them in advance, so support staff are not improvising at 2 a.m.
Block times differ a lot between networks, so the cost of waiting differs too. A chain that confirms in a couple of minutes makes waiting almost painless, which removes most of the temptation to accept zero-conf. Litecoin, for example, is built around quick blocks; our guide to accepting Litecoin with 2.5-minute confirmations shows how that changes checkout. Some coins also offer their own fast-settlement features. Dash is one case, covered in our guide to Dash InstantSend and ChainLock.
Write the policy for a payment that disappears: who cancels the order, how access is revoked, how the customer is told. A payment that never confirms is not a refund case, because the funds never moved. Say so clearly in your checkout messages.
Track how many zero-conf releases you made, how many later failed, and what they cost. After a few months you will know whether your thresholds are too tight or too loose.
We process payments for merchants every day, and the zero-confirmation question comes up constantly, usually phrased as “why is my customer’s payment stuck?” Our honest view is that zero-conf is a risk setting, not a feature to chase.
Most merchants do not need to accept unconfirmed payments at all. They need a checkout that explains pending states clearly, a coin list that includes fast networks, and rules that match order value. The merchants who get hurt are usually those who release high-value, irreversible goods on the first sign of a payment because a customer was impatient.
We also think the answer should not live in someone’s head. Put your thresholds in writing, tie them to the type of goods, and review them. Marketplaces and platforms that pay out sellers should be stricter still, because a failed incoming payment that has already been paid out becomes your loss. Our no-KYC onboarding is built to get you started quickly, but fast onboarding does not change blockchain physics: a payment is only as final as the confirmations behind it.
If you are choosing which coins to offer, lean toward ones that settle quickly for everyday checkout and keep slower, high-value coins for situations where waiting is acceptable.
— Dustin
You do not have to choose between a slow checkout and an exposed one. A few levers help:
For a broader look at how the whole flow fits together, from invoice to settlement, our plain-English guide to how crypto payments work is a good companion.
On the other side of the checkout, a customer staring at zero confirmations usually has two questions: is my money gone, and what do I do?
First, check the transaction ID in a block explorer for the coin you used. If it shows as unconfirmed, it is in the mempool and still waiting. Second, look at the fee. If it was low and the network is busy, waiting is often the only option, and many transactions eventually confirm. Third, remember that a transaction left unconfirmed long enough can be dropped, after which the funds are spendable again from the sender’s wallet.
Do not send a second payment before you know what happened to the first. Contact the merchant with the transaction ID and let them check their side. A merchant with clear status messages can usually settle this in one reply.
CryptoPayr is a no-KYC crypto payment gateway that lets you accept 110+ coins, including Bitcoin and Ethereum, through hosted checkout, e-commerce plugins, payment links and an API. There are no setup or monthly fees. Pricing is volume-based: the listed tiers are Standard at 2%, Growth at 1.5%, Scale at 1% and Enterprise at 0.1%, based on monthly transaction volume, or a flat $0.10 per payment on our flat per-payment plan.
If you sell online, start with crypto payments for e-commerce. If you run a marketplace that splits commissions and pays sellers, see crypto payments for marketplaces. You can also review how crypto processing works across the full flow.
It is a crypto transaction that has been sent to the network but not yet included in a block. The sender has signed it and nodes have seen it, but no miner has recorded it on the blockchain. Until that happens, it is not final.
It depends on the amount and what you deliver. The Bitcoin Developer Guide treats them as generally untrustworthy without risk analysis because of double-spend attempts. For small or revocable sales the risk may be acceptable. For large or irreversible sales, wait for confirmations.
There is no protocol requirement. Six is a widely used convention for large Bitcoin transfers, but smaller orders often use fewer, and faster coins reach comfortable levels sooner. Set your own thresholds by order value and by how reversible your delivery is.
Usually because the network is busy or the fee attached was lower than what miners are currently prioritizing. The payment waits in the mempool until a miner includes it. If it waits too long it may be dropped, and the funds then stay with the sender.
Look up the transaction ID in a block explorer, or check the status in your payment gateway dashboard. A payment counts as received for most merchants once it has the number of confirmations your policy requires, not when it first appears.
Open a free CryptoPayr account and take your first crypto payment the same day.
Get started for free
A crypto payment arrived short of the invoice. Learn why underpayments happen, how to verify them on-chain, and how merchants can fix and prevent them.
Send crypto payment alerts to a Discord channel with webhooks: which events to post, what each message should hold, and how to keep it reliable and private.
Crypto payments can't be charged back, so disputes work differently. Learn what merchants and buyers can do: refunds, evidence, scam reports and prevention.