When a Customer's Payment Sits Unconfirmed
A retail counter can hand over goods the moment a card payment clears, but a Bitcoin payment is different: the coins are visible on the network long before they are settled. A merchant who treats an unconfirmed transfer as revenue is lending goods against a promise. The fix is a short written policy, not a distrust of customers.
Key takeaways
- An unconfirmed transfer is not settled revenue, even when the amount and address are correct.
- A transaction that spends unconfirmed inputs cannot be accelerated until the parent confirms.
- The free route needs a size of 0.5 KB or less and a fee rate of at least 0.0001 BTC per KB.
- At 36 TH/s a day of mining output is $1.31 net, a useful scale for judging how long a pending invoice is worth chasing.
A payment is not revenue until it confirms
The network shows a broadcast transaction within seconds, which creates a tempting illusion of completion. What the customer has done is ask the network to include the payment in a block. Until a block contains it, the transaction can theoretically be replaced or left out, and the merchant has no settled claim. One confirmation is the first real signal; more confirmations make reversal progressively harder.
For low-value items, a single confirmation may be enough risk to accept. For a high-value order, a small business should wait for several. The right number is a commercial decision, not a technical one, and it should be written down so staff apply it consistently. The worst outcome is not a slow customer; it is two staff members applying different rules on the same afternoon.
The double-spend rule and what it protects
An accelerator will not touch a transaction that attempts a double spend. That rule protects the merchant as much as the network: if a sender could push a conflicting payment through an acceleration service, the confirmation a shop relies on would mean much less. The service is for legitimate transactions that are simply underpaying on fee rate, not for rewriting history.
In practice, a double-spend attempt is rare at a retail counter, but the rule matters when a customer claims a payment is stuck and asks the merchant to "push it through". If the wallet shows a conflict, no accelerator will help, and the conversation should move to a fresh payment. Staff should know that refusing is the correct response, not an unhelpful one.
Chained payments at the counter
The more common complication is a payment that depends on an earlier unconfirmed transaction. This happens when a customer consolidates coins and pays in the same session, or when a service forwards funds it has not yet received. The child transaction cannot be included before the parent, so an acceleration request on the child will be rejected.
The remedy is sequential. Accelerate the parent, wait for it to confirm, then resubmit the child if it is still pending. A merchant cannot do this on the customer's behalf without the transaction details, so ask for both IDs and check the input list. If the customer cannot provide them, the practical option is to wait or to request a new payment from confirmed coins.
Free versus paid for a business
For a business, the free route is the default and the paid route is an exception with a reason. The free conditions are a maximum size of 0.5 KB and a minimum fee rate of 0.0001 BTC per KB, with an hourly quota processed in submission order. A simple customer payment usually fits. A batched payout or a wallet that spends many small inputs often does not.
The ViaBTC TX Accelerator applies the same non-cancellable, non-refundable terms to both routes, so the decision has to be made before submission. Put the rule in the policy: free first, paid only when a documented deadline or a customer relationship justifies it, and always with a note of who approved it. That single sentence prevents ad hoc spending.
Recording a pending invoice correctly
Accounting treatment should match the settlement state. A pending payment belongs in a suspense or pending account, not in revenue, and it moves to revenue when the confirmation threshold is reached. If the payment never confirms, the entry is reversed rather than written off, which keeps the audit trail clean. The exact account names depend on the bookkeeping system, but the principle does not.
Record the transaction ID, the amount, the exchange rate at the time of confirmation and the confirmation count. If the customer later disputes the order, that record answers the question in seconds. It also makes reconciliation with the wallet straightforward, because every invoice line can be traced to a specific on-chain event rather than to a screenshot.
The table uses a small mining rig as a clock. It shows what an outage costs at three sizes, which is a handy way to judge how much staff time a pending payment deserves before the chasing costs more than the delay.
| Rig size | Net per day | 6 hours offline | 24 hours offline | 72 hours offline |
|---|---|---|---|---|
| 36 TH/s | $1.31 | $0.33 | $1.31 | $3.93 |
| 144 TH/s | $5.25 | $1.31 | $5.25 | $15.75 |
| 360 TH/s | $13.13 | $3.28 | $13.13 | $39.39 |
A policy that staff can follow
Keep it to one page. State the confirmation threshold by order value, the approved accelerator route, who can authorise a paid submission, and what to tell the customer while waiting. Add the transaction details staff must collect and where to record them. A policy that fits on a card at the till will be used; a ten-page manual will not.
Review it after the first busy month. If most payments confirm within one block, the threshold may be stricter than necessary. If several needed acceleration, the checkout flow may be encouraging low fee rates. The policy is a feedback tool as much as a rulebook, and the pattern of exceptions tells you where the process should change.
Worked example
Use the 36 TH/s rig to put a number on an hour of waiting.
- Daily BTC: 36 × 0.00000044861 = 0.00001615 BTC.
- Gross USD: 0.00001615 × 84,692 = $1.368, shown as $1.37.
- Listed 4% on the block-reward component: $1.368 × 0.04 = $0.055, leaving $1.313, shown as $1.31.
- Six hours offline: $1.313 ÷ 4 = $0.33.
- Twenty-four hours: $1.313.
- Seventy-two hours: 3 × $1.313 = $3.94, shown as $3.93 after rounding the daily figure.
- At 144 TH/s: 144 × 0.00000044861 = 0.00006460 BTC, or $5.47 gross and $5.25 net.
- At 360 TH/s: 360 × 0.00000044861 = 0.00016150 BTC, or $13.68 gross and $13.13 net.
Frequently asked questions
How many confirmations should a shop wait for?
That is a commercial choice based on order value; one confirmation is common for small purchases, while larger orders usually justify waiting for several before goods are released.
Can a merchant accelerate a customer's payment?
Only with the transaction ID and the customer's consent, and only if the payment meets the free conditions or the merchant chooses the paid route; the request cannot be cancelled once submitted.
What happens if the customer used unconfirmed coins?
The payment cannot be accelerated until the earlier transaction confirms, so ask for both IDs, help with the parent first, and treat the order as pending until the chain settles.
Tell the customer the honest timeline
An unconfirmed payment is a normal event, and the customer usually understands a clear explanation better than a vague assurance. Say what has been submitted, what happens next and what the shop will do if it does not settle. Keep the wallet history and the fee page with the policy so the numbers in the conversation are current, and review the threshold after the first month of real orders.
Sources: ViaBTC accelerator, wallet and pricing pages for submission conditions and account charges. Readings on 21 Sept 2026: network hashrate 1,003 EH/s, 3.125 BTC per block, 144 blocks daily, BTC $84,692. Published 24 Oct 2026; mining output assumes continuous uptime and no power cost[1].