Why Does a Customer’s Transaction Have Confirmations but Your Node Shows Zero?

14 November 2026

The most common cause is that your node is not connected to the same set of peers as the customer’s wallet, or your node has fallen behind the network’s current best blockchain. The transaction is real and confirmed on the global network, but your local copy of the blockchain has not yet received or validated those blocks. This is a synchronization problem, not a transaction problem.

How Confirmations Work on the Network vs. on Your Node

A confirmation is simply the number of blocks built on top of the block that contains the transaction. When a customer’s wallet shows, say, three confirmations, that means three blocks have been mined after the transaction’s block. Your node will see those same confirmations once it has downloaded and validated those three blocks.

If your node shows zero confirmations, it means one of the following:

• Your node has not yet seen the block that contains the transaction.
• Your node has seen the block but has not finished validating it.
• Your node is on a different chain tip (a fork or a stale branch).

Step-by-Step Diagnosis

Do these in order. Stop when the cause is found.

1. check your node’s block height

Open your node’s debug console or status page. Compare its current block height to a public block explorer (like mempool.space or blockstream.info). If your node’s height is lower, it is behind the network.

If behind: Your node needs to catch up. This can take minutes or hours depending on how far behind it is, your internet speed, and your hardware. Do not restart the node unless you have to - restarting can slow catching up.

2. check peer connections

Your node might be connected only to a small or slow set of peers. In the debug console, run getpeerinfo (Bitcoin Core) or the equivalent for your node software. Look for the synced_headers and synced_blocks values. If they are far below the network height, your peers are not giving you the latest data.

Solution: Add more reliable peers. You can add specific trusted nodes manually, or simply wait - most node software will find new peers over time.

3. Check for a Fork or Orphan Block

If your node’s height matches the network but the transaction still shows zero confirmations, your node may be on a different chain fork. This is rare for a well-connected node, but possible during a chain reorganization or if your node was offline for a period.

Compare the block hash at your node’s tip with a block explorer. If they differ, your node is on a stale chain. You may need to restart your node with the -reindex or -reindex-chainstate flag (Bitcoin Core). This forces your node to re-validate all blocks from the last checkpoint. Expect this to take significant time.

4. Check the Transaction in Your Node’s Mempool

Even if the transaction is confirmed on the network, your node may still have it in its mempool as unconfirmed if your node never received the block that confirmed it. Run getmempoolentry <txid> or the equivalent. If the transaction is in the mempool, your node has not yet processed the confirming block.

Solution: Let your node catch up. Do not manually remove the transaction from the mempool - it will be cleared automatically once the block arrives.

Why this happens in practice

Node was offline or restarted

If your node was shut down for any period, it will be behind. On restart, it begins downloading blocks from the last known tip. During that catch-up window, any transaction confirmed while the node was offline will show zero confirmations locally.

Slow or throttled internet

A node behind a slow connection or a router that throttles peer-to-peer traffic can fall behind. This is common on residential connections with high upload usage.

Firewall or port forwarding issues

If your node cannot accept incoming connections, it relies entirely on outgoing connections. Outgoing peers may be less reliable or slower. Check that your node’s port (default 8333 for Bitcoin) is reachable.

Using a pruned node

A pruned node stores only a limited number of recent blocks. It can still validate new blocks and show confirmations, but if it prunes the block containing the transaction before you check, it will not be able to show the confirmation history. The transaction will appear as if it never happened. This is rare but possible if you check long after the payment.

What to Do About the Payment

If your node shows zero confirmations but the customer’s wallet and a block explorer show confirmations, the payment is valid on the network. The issue is only with your node’s local view.

Do not mark the invoice as unpaid. The transaction has occurred. Instead:

• Use a block explorer to verify the payments/crypto-payment-reconciliation-transaction-hash/">transaction hash and confirm the number of confirmations.
• Manually mark the invoice as paid in your system if your payment processor does not do it automatically when it syncs.
• Investigate why your node fell behind to prevent it from happening again.

Preventing This in the Future

• Set up monitoring that alerts you if your node’s block height falls more than one block behind the network.
• Use a dedicated machine or VPS for your node, not a machine that is regularly shut down.
• Ensure your node has enough inbound peer slots and that your firewall allows incoming connections on the correct port.
• Consider running a second, lightweight node (such as an Electrum server) as a fallback for transaction verification.

The short version: a difference in confirmation counts between your node and the network means your node is out of sync. The transaction is fine. Fix the node, not the invoice.

Back to crypto payments