Accepting Bitcoin Too Quickly: What Zero Confirmations Actually Risks

A Bitcoin payment that appears in your wallet has been broadcast, not settled. The difference matters for a merchant deciding when to release goods. Against a Bitcoin payment gateway with guaranteed fiat settlement, which operates these controls by obligation, the gaps elsewhere become obvious.

What a broadcast transaction is

It has been sent to the network and is waiting to be included in a block. Nodes have seen it. Your wallet shows it as pending.

Until it is in a block, it can be replaced by a conflicting transaction spending the same funds elsewhere.

How a replacement happens

The sender broadcasts a transaction to you, then broadcasts another spending the same coins to themselves with a higher fee. Miners prefer the higher fee, so the second one confirms and yours does not.

This is straightforward if the original transaction signalled that it may be replaced, which many wallets do by default.

When zero confirmations is reasonable

Small amounts, where the effort of the attack exceeds the value. A cafe accepting a coffee payment is not a realistic target.

When the transaction does not signal replaceability and pays a competitive fee, which means it will likely confirm in the next block.

When the customer is present and identifiable, which changes the risk calculation entirely.

When your provider absorbs the risk, which several do below a threshold, using their own analysis.

When it is not

Anything valuable enough to justify the effort. Digital goods delivered instantly, because the fraudster gets the goods before the replacement is visible. Anonymous online orders where you have no recourse. The same attack targets businesses harder, which is what a payment processor for high-risk e-commerce is built to resist.

The practical policy

Tier it by amount. Small payments accepted at broadcast with a risk score. Ordinary amounts at one confirmation, roughly ten minutes. Large amounts at three to six.

A flat policy of six confirmations for everything is safe and loses customers on small orders. A flat policy of zero is exposed on large ones.

What your provider should offer

Configurable thresholds. Replacement signalling detection, so a transaction that can be replaced is treated differently. Fee adequacy assessment, since a transaction with a low fee may sit unconfirmed for hours.

Ask whether the provider absorbs the risk at zero confirmations and up to what amount. Some do, and that is a real part of the service.

The related problem: the stuck transaction

A genuine payment with too low a fee can remain unconfirmed for hours during congestion. The customer has paid and your system shows nothing.

That is not fraud and it generates the same support conversation. Tell customers at checkout what fee level is needed, or use a provider that highlights an underpaid fee rather than leaving the payment pending silently.

For digital goods specifically

Instant delivery plus zero confirmations is the combination that gets exploited. If you sell something delivered immediately, require at least one confirmation regardless of amount. For trading and settlement specifically, Collect & Exchange publishes its terms in full.