How to Accept Bitcoin Payments: A Guide for Merchants

Before you take your first bitcoin payment, you need four things settled: a wallet you control, a way to price goods in your local currency, a process for confirming payment, and a record of every transaction for your books. Skipping any of these creates problems later, usually when a customer says they paid and you can't match the transaction. This guide walks through the setup in order, then covers what drives cost and time, the mistakes that cost merchants money, and a checklist to work through before going live.

Decide how you will accept bitcoin payments online

There are two broad routes, and the choice shapes everything that follows.

A hosted processor or payment gateway. A third-party service generates an address or invoice for each order, watches the blockchain, and tells your store when payment arrives. Most gateways convert to your local currency at settlement, so you receive fiat and never hold bitcoin. Setup is usually a plugin or an API key, plus a business verification step. You pay a processing fee, and you accept that the provider holds the funds briefly and sets the minimum payment amount.

A wallet you control directly. You generate addresses yourself, either in a software wallet or a hardware wallet for larger sums, and check incoming transactions manually or through your own integration. There is no processing fee beyond network costs, and no intermediary — but you carry the price risk, the security burden and the reconciliation work.

For most merchants selling physical goods or subscriptions, a processor is the lower-risk starting point because it handles confirmation and conversion. Direct wallet acceptance suits businesses that want to hold bitcoin, sell high-ticket items where fees matter, or already have crypto-literate staff.

What to check before signing with a processor

• Settlement currency and timing: does it pay out in fiat, in bitcoin, or both, and on what schedule?
• Whether it supports the coins and networks you expect customers to use.
• Refund policy: can you refund in fiat, and at what exchange rate?
• Underpayment and overpayment handling: does it accept a partial payment, or void the invoice?
• Data handling and the jurisdiction of the provider, since record-keeping duties fall on you, not them.

Set up your wallet and confirm you control the keys

If you use a hosted processor, your "wallet" is really an account with them — check what happens to your balance if the account is closed or the provider stops operating. If you hold your own keys, generate the wallet on a device that stays offline for storage, back up the recovery phrase in more than one physical location, and test the restore process before you rely on it. A wallet you cannot recover is not a wallet.

For direct acceptance, decide which address type to publish. Reusing a single static address is convenient but makes it hard to match payments to orders and exposes your balance history to anyone who sees it. Generating a fresh address per invoice is the safer default.

Price in your local currency and lock the rate

Bitcoin's price moves. If you quote a price in bitcoin and the customer pays an hour later, you may receive less value than you intended. Two approaches avoid this:

• Price in fiat, convert at checkout. The customer sees a bitcoin amount based on the current rate, usually with a short validity window — commonly a few minutes to a quarter of an hour, set by the processor.
• Price in bitcoin and accept the volatility. Simpler to display, but you bear the risk between quote and confirmation.

The first is standard for retail. Whatever you choose, state the exchange-rate source and the validity window in your checkout terms so a customer who pays late understands why the amount was recalculated or the invoice expired.

Build the checkout flow and confirm payment

1. Generate an invoice or address at the moment the order is placed, tied to the order ID.
2. Display the amount, the address and a QR code. Include the network so customers don't send on the wrong chain.
3. Wait for confirmation. A transaction sits in the mempool until a miner includes it in a block. One confirmation is often treated as sufficient for small amounts; larger orders may warrant waiting for several. A zero-confirmation transaction can be replaced before it confirms, so don't release goods on an unconfirmed payment for high-value orders.
4. Match the payment to the order automatically where possible, and reconcile manually as a fallback.
5. Release the order and record the transaction ID, the fiat value at the time of payment, and the settlement details.

Handling underpayments and late payments

Customers occasionally send slightly less than the quoted amount, or pay after the invoice expires and the rate has moved. Decide your policy in advance: accept small shortfalls within a tolerance your processor sets, request the difference, or void and refund. Write it into your terms so support staff apply it consistently.

What affects time and cost

No single figure applies across providers or countries, but the factors are predictable.

For a rough illustration only, a processor charging a small percentage on a modest order will cost less in absolute terms than the same percentage on a large one, but a fixed minimum fee can make small orders uneconomic. Run your own average order value through a provider's published pricing before committing.

Mistakes that cost merchants money

• Releasing goods on an unconfirmed transaction. The payment can be replaced before it confirms.
• Publishing the wrong network. Sending bitcoin on a different chain than the one you display usually means the funds are unrecoverable.
• No refund procedure. Decide how refunds work, in what currency, and at which rate, before the first dispute.
• Poor record-keeping. Store the transaction ID, timestamp, fiat value and settlement record for every sale. Your accountant and tax authority will want them.
• Ignoring the exchange-rate window. A checkout that quotes a stale rate invites disputes.
• No plan for key loss. If you hold your own wallet, a lost recovery phrase means lost funds, full stop.
• Skipping staff training. Support staff need a script for "I paid but my order isn't marked paid".

Pre-launch checklist

• Processor contract or wallet reviewed, including settlement, refunds and underpayment rules.
• Wallet recovery phrase backed up and a restore tested.
• Checkout tested end to end with a small live payment on each supported network.
• Exchange-rate source and quote validity window documented in your terms.
• Confirmation threshold set by order value.
• Refund and expired-invoice policy written and shared with support.
• Bookkeeping fields defined: transaction ID, fiat value, fees, settlement date.
• Local regulatory and tax requirements checked with a qualified adviser.
• Customer-facing help text drafted for common payment problems.

The practical takeaway

Accepting bitcoin is mostly an operations problem, not a technical one. Pick a settlement route that matches your risk tolerance, price in your local currency, set a confirmation threshold, and keep clean records from the first sale. Test the whole flow with a small payment before you announce it, and write down how you handle refunds, underpayments and expired invoices. Get those four things right and the rest is routine.

This article is general information, not financial, legal or tax advice.