How to Accept Bitcoin Payments on Your Website (Merchant Guide)

Some of your customers would rather pay with the coin they already hold than type a card number, and for many of them that coin is Bitcoin. If you want to accept Bitcoin payments on your website, the hard part is not receiving coins. It is knowing which order a payment belongs to, when it is safe to deliver, and what to do when someone sends the wrong amount.

This guide walks through the options, how a Bitcoin checkout works in practice, how many confirmations to wait for, and how to deal with price swings and fees. It is written for online businesses: shops, SaaS, hosting, digital goods and similar.

Why accept Bitcoin payments at all?

• Customers who already hold BTC: Bitcoin is still the coin most people think of first. Offering it removes a reason to leave checkout.
• No chargebacks: a confirmed Bitcoin transaction cannot be reversed by the payer's bank. Refunds happen only when you decide to send one.
• Global reach: a buyer in any country can pay without international card declines or currency conversion at checkout.
• A second payment rail: if a card processor pauses your account, crypto keeps orders coming in.

There are honest downsides too. Bitcoin's price moves, on-chain fees rise when the network is busy, and a block takes about ten minutes on average, so confirmation is slower than on networks like TRON. That is why most merchants offer Bitcoin next to a stablecoin such as USDT rather than instead of it. Our guide on accepting USDT payments covers the stablecoin side.

Three ways to accept Bitcoin payments

Posting one wallet address on your site works for donations, but it breaks as soon as two customers pay similar amounts at the same time. You cannot tell who paid for what. A gateway solves this by giving every invoice its own deposit address.

How a Bitcoin checkout works with a payment gateway

With mistKET, Bitcoin uses the same flow as every other asset on the platform:

1. Your backend creates an invoice: one signed API request with the amount, the price currency (USD, EUR, GBP, TRY, RUB or AED) and your order ID. You get back a checkout URL. You can also create the invoice in the merchant panel and send the link by chat or e-mail.
2. The customer opens the hosted page: they see the exact BTC amount, a native SegWit address and a QR code. The QR uses the standard bitcoin: payment URI, so most wallets fill in the address and amount by themselves.
3. The rate is locked: the BTC amount is fixed for the lifetime of the invoice, so the customer is not chasing a moving price while they open their wallet.
4. The gateway sees the transaction: unconfirmed transactions are picked up from the mempool, so the customer gets an immediate "payment received" message instead of staring at a timer.
5. Confirmations are tracked: once the required confirmations are reached, your server receives signed invoice.paid and invoice.confirmed webhooks (HMAC-SHA256). Our article on crypto payment webhooks shows how to verify them.
6. Your balance is credited: the payment lands in your BTC balance, net of the agreed fee, and you request a payout to your own address whenever you like.

Confirmations: when is it safe to deliver?

A transaction in the mempool has been broadcast but not yet written into a block. Until it is confirmed, it can in rare cases be replaced or dropped. Each new block on top of it makes reversal far less likely. Bitcoin produces a block roughly every ten minutes, but the gaps vary a lot.

mistKET currently waits for two confirmations on Bitcoin before marking an invoice confirmed. A sensible fulfilment policy looks like this:

Tell customers up front that Bitcoin confirmations take longer than card payments. One line on the checkout or the order page prevents most "where is my order?" messages.

Volatility, fees and wrong amounts

Price volatility

You price your product in fiat, for example 49 USD, and the invoice converts it to BTC at a locked rate. After that, the coins you receive are Bitcoin, and their value keeps moving. Balances on mistKET are kept per asset, so a BTC payment stays BTC until you withdraw it. If you do not want price exposure, withdraw regularly and convert on an exchange you use, or steer customers who do not care about the coin toward USDT.

Network fees

The customer pays the Bitcoin network fee when they send. What counts is the amount that arrives at the deposit address. Customers withdrawing from an exchange sometimes forget that the exchange deducts its own withdrawal fee, so a smaller amount arrives. The checkout page warns about this, but it is worth repeating in your own payment instructions.

Underpaid and overpaid invoices

• Underpaid: if less than the required amount arrives, the invoice is marked underpaid and the customer can send the rest. The deadline is extended so they have time to top up. You can also set a small tolerance percentage for your account.
• Overpaid: larger amounts are flagged separately and still count as paid. You decide whether to refund the difference.
• Late payments: transfers that arrive shortly after the timer expires are still matched within a short grace window; anything later is held for review instead of being credited blindly.

Setting up Bitcoin payments step by step

1. Apply as a merchant: send your website, business type, expected volume and the assets you want, including Bitcoin. The team reviews each application before issuing API keys.
2. Decide your fulfilment rule: write down when an order is delivered, based on the confirmation table above.
3. Integrate: create invoices with one signed POST and handle the webhook. Any language that can send HTTPS and compute an HMAC works; the API documentation lists the endpoints. No API work? Use payment links from the panel.
4. Test with a small amount: pay a real invoice yourself, watch it move from pending to paid to confirmed, and check that your order system reacts correctly.
5. Write clear customer instructions: "Pay in BTC on the Bitcoin network. Send the exact amount shown; if you pay from an exchange, add its withdrawal fee."
6. Set a payout routine: request payouts to your own wallet on a fixed schedule. Each payout is reserved immediately, sent after approval and recorded with its transaction hash.

Common mistakes to avoid

• Reusing one address for every customer, which makes reconciliation impossible.
• Delivering instant digital goods on an unconfirmed transaction.
• Hiding crypto at the bottom of the checkout where nobody sees it.
• Accepting payments on the wrong network. Bitcoin sent to an address of another chain is not something the gateway can match.
• Ignoring webhook failures. Log every delivery and make your handler idempotent by order ID, since webhooks can be retried.

Taxes, records and the rules where you operate

Accepting Bitcoin does not take you outside tax or consumer law. Keep a record of every invoice with its fiat value at the time of payment; the merchant panel shows expected and received amounts and transaction hashes, which makes bookkeeping easier. Rules differ by country, and some, such as Turkey and mainland China, restrict or ban using crypto as a means of payment. Check what applies to your business before you launch, and only sell products that are legal where you and your customers are.

If you want more background before you start, read our overview of how to accept crypto payments on a website.