What Is Replace-by-Fee (RBF) and Why Does It Matter for Merchant Payments?

05 November 2026

Replace-by-Fee (RBF) is a Bitcoin feature that allows a sender to replace an unconfirmed transaction with a new one that pays a higher fee. For merchants accepting on-chain Bitcoin payments, this creates a risk: a customer can broadcast a low-fee transaction, then replace it with a different transaction - potentially sending funds to a different address or changing the amount - while the original invoice appears to be pending. Understanding RBF is essential for setting safe confirmation thresholds and avoiding lost revenue.

How RBF Works

In the Bitcoin network, a transaction is not final until it is included in a block and confirmed. Before confirmation, the transaction sits in the mempool - a pool of unconfirmed transactions that miners pick from. RBF lets the sender mark a transaction as replaceable (using a flag in the transaction data) or, in some wallets, replace any unconfirmed transaction even without the flag (known as "full RBF" via nodes that accept it).

If the sender wants the transaction mined faster, they can create a new transaction that spends at least one of the same inputs (the unspent outputs from previous transactions) and pays a higher fee. Miners typically prefer the higher-fee version, so the original transaction is dropped and the replacement takes its place.

For a merchant, the concern is not the fee increase itself. The risk is that the replacement transaction changes where the funds go or what amount is sent. A customer could:

• Send a small test payment to the merchant's invoice address, then replace it with a transaction that sends the full amount back to themselves.
• Replace a correct payment with one that sends less crypto to the merchant's address, or sends the correct amount to a different address entirely.
• Broadcast multiple replacements, creating confusion about which transaction should be considered the real payment.

The risk to merchants

The danger for merchants is specific to unconfirmed transactions. If you treat an unconfirmed transaction as final - for example, by releasing goods or services immediately - you have no guarantee that the payment will eventually confirm. The customer can replace the transaction up until the moment it is mined into a block, and the replacement may not pay you at all.

This risk is most relevant for:

• Digital goods or services that can be delivered instantly (e.g., downloads, access codes, API credits).
• Low-value transactions where waiting for confirmations is impractical.
• Self-hosted payment processors like BTCPay Server, where you control the confirmation threshold.

Exchanges and payment processors that accept unconfirmed deposits often have their own risk models, but they typically require a higher number of confirmations for larger amounts or use monitoring tools to detect replacements.

How to protect your business

1. Set an Appropriate Confirmation Threshold

The most effective defense is to wait for at least one confirmation before treating a payment as settled. For most merchant use cases, one confirmation is sufficient - the probability of a successful double-spend attack after one confirmation is extremely low. For high-value transactions, three to six confirmations are standard.

BTCPay Server and similar self-hosted tools let you configure the required number of confirmations per store or per invoice. If you set a zero-confirmation threshold, you are accepting the RBF risk.

2. Use a Payment Processor That Handles RBF

If you use a hosted payment processor (like Coinbase Commerce or BitPay), the processor typically handles RBF detection on its side. These services monitor the mempool for replacements and will not mark an invoice as paid until the transaction is confirmed or until they have verified that no replacement has occurred. This removes the burden from you, but it also means you rely on the processor's policies and uptime.

3. Monitor the Mempool for Replacements

If you run your own node and payment processor, you can monitor the mempool for transactions that spend the same inputs as a pending payment. Tools like bitcoin-cli or mempool.space APIs can flag replacements. However, this requires technical setup and constant monitoring - manual checks are not practical for a business processing many payments.

4. Use Lightning Network as an Alternative

Lightning Network invoices settle instantly and are not subject to RBF. Each Lightning payment is a multi-step protocol that ensures the recipient receives the funds before the sender can cancel. For small to medium payments, Lightning eliminates the unconfirmed-transaction risk entirely. See our guide on Lightning Network invoices for details.

What to Do If You Suspect an RBF Attack

If a payment shows as unconfirmed and you suspect it has been replaced:

• Do not release goods or services.
• Check the transaction ID (TXID) in a block explorer. If the TXID no longer appears in the mempool, the transaction may have been replaced.
• Look for a new transaction from the same sender address with a different TXID and a higher fee. If the new transaction does not pay your invoice address, the customer has not paid you.
• Contact the customer. If the replacement was accidental (e.g., the wallet software automatically bumped the fee), ask them to send a new payment to the same invoice address.

The Bottom Line

Replace-by-Fee is a legitimate Bitcoin feature, not an attack. Most customers will never use it maliciously. But the risk is real, and the mitigation is simple: do not treat unconfirmed transactions as final. Set a confirmation threshold that matches your risk tolerance, and use payment tools that monitor for replacements. For instant settlement, consider Lightning Network. That combination keeps your business safe without requiring you to become a mempool expert.

Back to crypto payments