Replace-by-Fee and Unconfirmed Payments: What Canadian Merchants Need to Know

When a customer pays in Bitcoin at your counter or through an online checkout, the transaction does not settle the moment it hits your screen. It sits in a holding area called the mempool until miners bundle it into a block. During that window, the sender can, under certain conditions, broadcast a replacement transaction that redirects those same coins elsewhere. That mechanism is called Replace-by-Fee, or RBF.

Understanding RBF is not about fearing every Bitcoin payment. Most transactions confirm without incident. But knowing how the protocol works, which signals to watch for, and where the real risk concentrates helps you set sensible policies without slowing down every sale.

How Replace-by-Fee Works at the Protocol Level

Bitcoin transactions compete for block space by paying a fee per byte of data. When the network is busy, a transaction with a low fee can sit unconfirmed for hours. RBF was formalized in Bitcoin Improvement Proposal 125 to solve a practical problem: it lets a sender replace a stuck transaction with a higher-fee version, moving it to the front of the queue.

The replacement transaction spends the same inputs as the original. Miners follow standard rules: they accept the replacement if it pays a higher fee and meets a few other criteria. Once the replacement lands in a block, the original becomes invalid because its inputs are already spent.

From a technical standpoint, a sender signals that a transaction is replaceable by setting the sequence number field on each input to a value below 0xFFFFFFFE. Wallets that support BIP 125 typically set this flag automatically, either always or as a user option. Wallets that do not support RBF leave the sequence numbers at the default, which signals the transaction is not opt-in replaceable.

One important nuance: not all nodes and miners enforce RBF identically. Full-RBF, a more aggressive variant, allows replacement of even transactions that did not signal opt-in. As of mid-2025, full-RBF adoption among miners has grown noticeably, which narrows the gap between flagged and unflagged transactions from a risk standpoint.

Detecting the RBF Signal as a Merchant

Several Bitcoin tools surface the RBF flag to merchants and customers. Here is what to look for depending on how you are accepting payments.

Payment processors and point-of-sale apps. Most merchant-focused tools, including BTCPay Server and Strike for Business, expose an RBF indicator on incoming transactions. BTCPay labels unconfirmed payments and can be configured to hold an invoice in a pending state until one or more confirmations arrive. Check whether your processor shows an "RBF enabled" or "replaceable" flag on the payment notification screen, and what your processor does with a zero-confirmation payment by default.

Raw transaction data. If you are running your own node or using a block explorer, you can inspect the sequence numbers directly. A sequence value below 0xFFFFFFFE on any input indicates opt-in RBF. Tools like mempool.space display this plainly as "RBF: yes" on the transaction detail page.

Wallet software on the sending side. Wallets like BlueWallet, Sparrow, and Electrum send opt-in RBF transactions by default or make it easy to enable. Strike, Cash App (for on-chain sends), and some exchange withdrawal flows also signal RBF. Hardware wallets like Ledger and Trezor follow the settings of the software companion they are paired with.

For a deeper look at reading transaction details before releasing goods, see how to verify a bitcoin payment before you ship.

Practical Risk by Transaction Size and Context

The theoretical attack works like this: a customer sends you an RBF-flagged transaction, you release goods or services immediately, and the customer then broadcasts a replacement transaction sending those coins back to themselves or to a different address. The original transaction, the one to you, never confirms.

In practice, the risk is not uniform across all sale types.

Low-value in-person sales. For a coffee, a lunch, or a small retail purchase, the cost and complexity of executing a deliberate RBF attack typically outweighs the value of the goods. Broadcast timing, miner selection, and the need for the replacement to propagate before your transaction confirms all work against the attacker. Most merchants in this category treat a zero-confirmation transaction similarly to how they treat a contactless card tap: acceptable for small amounts where the friction of waiting is worse than the residual risk.

Mid-range and high-value sales. For electronics, jewellery, or any item where the margin on a single transaction matters, waiting for at least one confirmation changes the risk calculus significantly. A confirmed transaction cannot be replaced by RBF. The fee is paid, the block is found, and double-spending requires outpacing the entire mining network, which is a separate and far harder attack.

Digital goods and online orders. Because you control when the download link fires or when the order ships, you have more flexibility. Waiting for one confirmation before releasing a digital product adds a few minutes of delay but eliminates zero-confirmation risk entirely.

To understand how confirmation times translate into actual wait times under different network conditions, see how long a bitcoin payment takes to confirm.

How Many Confirmations Should You Require?

There is no single answer, and the right number depends on factors specific to your business: sale value, whether you can reverse delivery, and how much friction you are willing to add.

A widely cited rule of thumb in the Bitcoin merchant community is:

• Zero confirmations for very small amounts where the cost of delay exceeds the risk of loss. Unconfirmed is not unacceptable; it is a risk tolerance decision.
• 1 confirmation for typical retail transactions. One block reduces RBF risk to near zero and takes roughly 10 minutes on average, though actual times vary.
• 3 to 6 confirmations for high-value sales, large B2B invoices, or situations where reversing delivery is difficult or impossible.

Your payment processor may enforce its own minimums. BTCPay Server, for example, defaults to one confirmation before marking an invoice "settled," though you can adjust this per store. Some processors targeting brick-and-mortar use cases offer a lightning-speed mode that accepts zero-confirmation transactions below a configurable threshold and holds larger amounts for confirmation.

For a side-by-side look at your options, see how to verify a bitcoin payment before you ship.

Lightning Network: No Confirmation Waiting Required

The RBF question is specific to on-chain Bitcoin transactions, where the mempool and miner confirmation process apply. Lightning Network payments work differently at a fundamental level.

On Lightning, a payment travels through a pre-funded channel network and settles with cryptographic finality the moment the recipient claims the payment preimage. There is no mempool, no replacement mechanism, and no waiting for blocks. A Lightning payment that reaches your node is final in the same sense that a completed card authorization is final.

For Canadian merchants accepting in-person payments, Lightning is increasingly the practical answer to zero-confirmation risk. The tradeoff is channel liquidity management and the need for either a hosted node (through services like Voltage or a payment processor that abstracts this away) or a self-hosted node you maintain yourself.

For a fuller comparison of the two rails, see on-chain vs Lightning: which bitcoin payment rail to use. For setup guidance specific to point-of-sale environments, see accepting bitcoin at the point of sale.

What This Means for Canadian Merchant Policy

Canadian businesses accepting Bitcoin face the same RBF mechanics as merchants anywhere, but a few local considerations are worth keeping in mind.

FINTRAC's dealer-in-virtual-currency rules apply to businesses that regularly exchange or transfer virtual currency, not to merchants simply accepting Bitcoin as payment for goods or services. That said, your recordkeeping practices for Bitcoin transactions should be consistent with your general AML recordkeeping regardless of FINTRAC applicability. The CRA treats Bitcoin received as business income at fair market value on the date received, so the CAD value at the time of payment matters regardless of when you convert.

None of this changes the RBF calculus directly, but it reinforces why confirmation-based policies are worth documenting. If a transaction never confirms because it was replaced, the payment did not occur, and your books should reflect that. A consistent confirmation policy makes those records cleaner.

Rules in this space change. Verify current CRA and FINTRAC guidance directly or speak with a qualified Canadian accountant or lawyer before finalizing your policies.

---

Frequently Asked Questions

Can I tell whether a customer's wallet will send an RBF transaction before they pay?

Not with certainty, because the flag is set on the transaction itself rather than broadcast in advance. What you can do is check the incoming transaction the moment it appears in your payment terminal or processor. If your setup shows an RBF indicator, that tells you whether the specific transaction is flagged. If you need this visibility, choose a processor that surfaces it explicitly, or check mempool.space directly using the transaction ID.

Does RBF mean Bitcoin payments are unsafe for merchants?

No. The risk exists on a spectrum. Small amounts with RBF-flagged transactions carry a low but nonzero risk if you release goods before confirmation. Confirmed transactions carry no RBF risk at all. Lightning payments have no RBF exposure by design. Most merchants manage this the same way they manage other small fraud risks: set a policy based on transaction value and delivery reversibility, then apply it consistently.

What happens if a transaction I received gets replaced before confirming?

The coins go back to the sender or to a new address the sender specifies, and your invoice goes unpaid. Your payment processor should mark the invoice as expired or failed. At that point, the customer has not paid, and you should treat the situation like any other non-payment before releasing goods or services.

Is full-RBF different from opt-in RBF, and should it change my policy?

Opt-in RBF requires the original transaction to signal replaceability via sequence numbers. Full-RBF allows replacement of any unconfirmed transaction, regardless of that signal. Full-RBF adoption among miners has been increasing, which means the absence of an RBF flag on a transaction is less protective than it used to be. If you are accepting zero-confirmation payments for anything above a very small threshold, waiting for one confirmation is the cleaner policy regardless of the flag.

How does this apply to the Lightning payments I accept alongside on-chain?

Lightning payments are not subject to RBF. They settle with cryptographic finality and do not go through the mempool. If a Lightning payment shows as received by your node or processor, it is final. The confirmation-count policies discussed in this article apply only to on-chain transactions.