How to Check and Fix a Pending Bitcoin Transaction

A Bitcoin payment marked pending has not been confirmed in a block. It may be waiting because its fee rate is low relative to current demand. Check the transaction ID and fee rate, which is the fee paid for each unit of transaction data. Then decide whether to wait or raise the fee. You can replace the transaction with one that pays more, or use a second transaction to raise the combined fee. Fee estimates change and do not promise a confirmation time, so check what your wallet broadcast and what other sources show before spending more.

Find the transaction

In the sending wallet, open activity or transaction details and find the transaction ID, often shortened to TXID. If the wallet does not show a TXID, it may not have broadcast the transaction yet. For a payment sent through an exchange or other service, check that service’s status or contact its support before trying to resend.

Search the TXID in a block explorer, a website that shows Bitcoin transactions and blocks. Check whether it is confirmed, unconfirmed, or missing from that explorer’s results. If it is unconfirmed, note its fee rate and compare it with current fee estimates. Fee rates are commonly measured in satoshis per virtual byte, or sat/vB. Comparing sat/vB is more useful than comparing total fees alone because transactions take up different amounts of block space.

An explorer’s mempool is the set of unconfirmed transactions known to that service. Every Bitcoin node has its own view, so explorers do not all show the same transactions. If the TXID is missing, check another reputable explorer or the wallet that sent it. A missing result from one explorer does not prove the payment was canceled or that the funds are ready to spend again.

Decide whether to wait

Wait when the transaction is not urgent and its fee rate looks competitive with current estimates. If demand falls, miners may be more likely to include a waiting transaction in a block. If demand rises, it may wait longer. An explorer’s projected fee levels change over time and cannot promise when a transaction will confirm.

If the payment is time-sensitive and its fee rate is below current estimates, consider a fee bump. Before raising the fee, check whether the wallet offers a fee bump and review the proposed fee. A fee bump costs more, and neither of the methods below guarantees confirmation by a particular time.

Replace it with RBF

Replace-by-Fee, or RBF, lets a wallet create and sign a replacement transaction with a higher fee. The replacement uses at least one of the same inputs, which are funds the original transaction spends, and has a new TXID. If the replacement confirms, the original cannot also confirm using those funds.

Open the pending transaction in the sending wallet and look for an option such as “Bump fee,” “Speed up,” or “Replace transaction.” Let the wallet calculate the required increase, then review the new fee and payment details before approving it. After broadcasting, look up the replacement TXID to check whether it appears and whether it confirms.

Wallets and Bitcoin nodes handle replacement differently. Some wallets do not offer RBF, and a node may reject a replacement that fails its fee or relay rules. Older guidance focused on whether the original transaction signaled that it could be replaced. Bitcoin Core now enables full RBF by default, but that does not make fee bumping available in every wallet or guarantee that every node will relay a replacement. Follow the wallet’s instructions rather than trying to rebroadcast a transaction manually.

Raise the fee with CPFP

Child Pays for Parent, or CPFP, uses a new transaction that spends an output of the unconfirmed transaction. An output is funds that transaction sends to an address. The new transaction, called the child, pays a high enough fee to make miners more likely to include both transactions in the same block. The sender may use this method if they control an unconfirmed change output, which returns leftover funds to the sender. A recipient may use it if they control an output, or funds sent to them, from the pending payment and their wallet supports CPFP.

CPFP adds another transaction and another fee, so it can cost more overall than replacing the original. Whether nodes relay the child and miners consider both transactions together depends on their policies.

For example, a 200-vB parent paying 2 sat/vB has a 400-sat fee. A 100-vB child would need a 5,600-sat fee to bring the combined fee to 6,000 sats across 300 vB, or an average of 20 sat/vB. Calculate the combined fee rate by dividing 6,000 sats by 300 vB; the result is 20 sat/vB. It is not a current fee recommendation, and it does not guarantee that miners will accept both transactions.

Check the final status

After an RBF or CPFP transaction is broadcast, check its TXID in the wallet and an explorer. A replacement has a new TXID; a CPFP child has its own TXID, while the original parent remains separate. Confirm that the relevant transaction or parent-child pair appears, then check for confirmation in a block; a mempool listing alone does not confirm the payment.

If the status remains unclear, contact the wallet, exchange, or service that broadcast the transaction. Avoid assuming that a missing transaction has expired or that its inputs are safe to spend again. How long a node keeps a transaction in its mempool depends on its policies and conditions, so there is no universal expiration time.