Zero-Confirmation Payment

Overview

When a wallet broadcasts a transaction, nodes may validate and place it in their local transaction pools. A merchant can detect the transaction and provide immediate service without waiting for the first block.

The risk is that mempools are not authoritative or globally identical. The sender can create a conflicting transaction, use replacement rules, or submit different versions to different nodes. A low-fee transaction can also be evicted or remain unconfirmed for a long time.

Risk controls can examine input history, fee competitiveness, broad propagation, conflicts, transaction replaceability, customer reputation, and order value. Direct connections to multiple nodes improve visibility but do not create finality.

Zero-confirmation acceptance is more suitable when the product can be revoked, the value is small, or fraud loss is tolerable. Physical goods, withdrawals, and irreversible high-value delivery usually require block confirmation.

Applications should clearly separate detected from confirmed status. If the transaction is replaced or disappears, the payment must move to review rather than remain permanently paid. Merchant systems also need idempotency so later confirmation does not create duplicate credit.

Zero-confirmation payment is a business risk choice, not a special settlement guarantee. It trades assurance for speed and must be calibrated to actual network behavior and loss exposure.

Merchants should measure actual loss and confirmation behavior rather than assume zero-confirmation acceptance is always unsafe or always reliable. Network upgrades, fee-policy changes, and wallet replacement defaults can alter risk. A tiered policy can combine immediate provisional access with delayed withdrawal or irreversible fulfillment, preserving speed while limiting the value exposed before confirmation.