How to accept Bitcoin payments: a practical guide for online businesses

A customer emails to say they would buy today if they could pay in Bitcoin. Another asks the same thing in your Discord a week later. You have a wallet on your phone, so the quick answer is to paste an address and wait. That works once. By the tenth order you are matching amounts by hand, guessing which payment belongs to whom, and wondering whether an unconfirmed transaction counts as paid.

This guide explains how to accept Bitcoin payments properly: the three ways to set it up, when to treat an order as paid, what network fees really cost, how to deal with price swings, refunds and bookkeeping, and how to switch it on in PapelShip. If your buyers mostly ask for stablecoins, read how to accept USDT payments as well; this post focuses on Bitcoin itself.

How to accept Bitcoin payments: the short answer

To accept Bitcoin, you need a wallet you control, a way to show each customer a unique address and an exact BTC amount, and something that watches the blockchain and marks the order paid once the transaction has enough confirmations. You can do the watching by hand, run your own software, or use a Bitcoin payment gateway that does it for you and plugs into your checkout.

For a website, the practical setup is an invoice per order: the customer chooses Bitcoin, sees a QR code with the amount and address, pays from any wallet or exchange, and the order completes automatically once the network confirms it. Everything below is about making each part of that flow reliable.

Three ways to accept Bitcoin on your website

Every Bitcoin setup sits somewhere between doing everything yourself and handing the work to a service. The differences come down to who watches the blockchain, who holds the funds, and how much work it takes to connect the result to your store.

1. A static wallet address

You publish one address and ask customers to send the price to it. It costs nothing and takes a minute to set up. It also falls apart quickly: every payment lands at the same address, so you can't tell which customer sent which transaction, customers calculate the BTC amount themselves at whatever rate they find, and someone has to check the wallet and deliver by hand. A single reused address also makes your whole sales history easy to read on a block explorer.

2. A self-hosted processor such as BTCPay Server

BTCPay Server is a free, open-source payment processor you run on your own server or hardware, or on a shared instance someone else hosts. It describes itself as having no processing fees and sends funds directly to the wallet you connect. You get invoices, unique addresses and store plugins, and it can also take Lightning payments if you run or connect a Lightning node. The cost is operational: you maintain the server, apply security updates, keep a Bitcoin node in sync, and connect it to your store and delivery yourself.

3. A hosted Bitcoin payment gateway

A hosted gateway runs the infrastructure and gives you a checkout, an API or a plugin. This is the fastest route to accepting Bitcoin on a website. Gateways differ in one important way: some hold your funds and pay you out later (custodial), while others send each payment straight to your own wallet (non-custodial). That choice affects risk, payouts and how much you depend on the provider. Custodial vs non-custodial crypto payments covers the trade-off in detail, and our comparisons with NOWPayments and Coinbase Commerce show how two well-known gateways approach it.

Confirmations: when to treat a Bitcoin order as paid

When a customer sends Bitcoin, the transaction first appears in the mempool, the waiting room of unconfirmed transactions. It is confirmed once a miner includes it in a block, and each further block on top adds one more confirmation. Bitcoin produces a block roughly every ten minutes on average, though the gap between two blocks can be one minute or forty.

An unconfirmed transaction is a promise, not a payment. Most wallets mark transactions as replaceable, which lets the sender rebroadcast them with a higher fee, and in principle a replacement can send the coins somewhere else. The risk on a small order is low, but it isn't zero, and the safe default is to wait for at least one confirmation before you deliver anything.

Bitcoin network fees and processing fees

Two kinds of fees are involved, and they are easy to confuse. The network fee is paid to miners by whoever sends the transaction. It depends on the size of the transaction in bytes and on how busy the network is, not on the amount, so sending $20 can cost the same as sending $20,000. When the mempool is quiet the fee is small; when demand spikes it can rise sharply for a few hours or days.

• –Incoming payments. The customer pays the network fee. If they pay from an exchange, the exchange often deducts its own withdrawal fee from the amount, which is why Bitcoin payments sometimes arrive slightly short.
• –Moving funds later. When you consolidate or move received coins, you pay the network fee. Many small payments mean many inputs, and more inputs make a larger, more expensive transaction. Consolidating when fees are low saves money.
• –Processing fees. A gateway may charge a percentage per payment on top. Self-hosting removes this fee but adds hosting and maintenance costs.

What about Lightning?

The Lightning Network is a payment layer on top of Bitcoin. Payments settle in seconds and fees are usually tiny, which suits small purchases. The trade-offs are practical: the merchant side needs a Lightning node with channels and inbound liquidity, or a provider that manages one, and not every customer's wallet or exchange can pay a Lightning invoice. For most stores selling digital products, on-chain Bitcoin with a one-confirmation policy is simpler to run, and Lightning becomes worth it when you have many low-value payments.

Volatility, and when a stablecoin is the better choice

Bitcoin's price moves while an invoice is open. A good checkout handles this in two ways: it prices your products in your own currency, and it locks the BTC amount for a short window, often 15 to 30 minutes. If the customer pays after the window closes, the invoice expires and a new one is quoted at the current rate.

After the money arrives, the price risk is yours. Some merchants keep received Bitcoin as a deliberate choice; others move it on a schedule to limit exposure. If you or your buyers want a fixed dollar value from start to finish, offer a stablecoin such as USDT or USDC next to Bitcoin. The network choice that stablecoins require is covered in our USDT guide.

Accounting, invoices and refunds

Bitcoin revenue is still revenue, and your bookkeeping should treat it that way. The clean approach is to record each sale at its value in your reporting currency at the time of payment, keep the transaction ID with the order, and issue the same invoice you would for a card payment. How crypto income and later gains are taxed depends on your country, so agree the treatment with your accountant before volume grows.

• –Keep one record per order. Order number, fiat price, BTC amount, rate, transaction ID and confirmation time in one place.
• –Issue a normal invoice. The customer's invoice shows the price in your currency and the payment method, just like any other order.
• –Track what you hold. If you keep Bitcoin, note the value at receipt so later gains or losses can be calculated.

Refunds need a written policy because there is no reverse button. A confirmed Bitcoin payment can't be pulled back, which removes chargebacks but means you send a new transaction to refund. Decide whether refunds return the original fiat value or the original BTC amount, since the two diverge as the price moves, and state it in your terms. Ask the customer for a refund address in writing rather than sending to the address the payment came from, because exchanges often send from shared wallets the customer doesn't control.

How to accept Bitcoin payments with PapelShip

PapelShip includes Bitcoin as part of Crypto POS, alongside ETH, USDT, USDC, LTC, TRX and DOGE. Payments go wallet to wallet, straight to your own wallet, so PapelShip never holds your funds and there is no payout to wait for. The same invoices power your storefront checkout, payment links and the embeddable checkout widget.

1. 01

   Create a store or use payment links

   Sell from a PapelShip storefront, send payment links in chat, or add the checkout widget to your existing site.

2. 02

   Add your Bitcoin wallet

   In your payment settings, enable Bitcoin and enter the wallet that should receive payments. Use a wallet you control and have backed up.

3. 03

   Keep prices in your currency

   Customers see your normal prices. When they choose Bitcoin, the invoice converts the price, fixes the BTC amount and starts an expiry timer you set in the invoice builder.

4. 04

   Let the invoice watch the chain

   Each order gets its own invoice with a QR code, copy buttons for the address and amount, and a live tracker showing the transaction and its confirmations.

5. 05

   Deliver on confirmation

   When the payment confirms, license keys, files or Discord roles are delivered instantly, and the order sits in the same history as card and bank payments, with a PDF invoice.

Crypto fees are 1.69% on the Free plan, 0.69% on Vaultie (€5.99 a month) and 0% on PapelShip+ (€14.99 a month); network fees are set by the blockchain. Companies under €250,000 in annual revenue can apply to the startup program for a 0.10% fee. Full details are on the pricing page, and the crypto payments overview shows the rest of the flow. Cards and crypto can also sit in one checkout.

Start with a setup you won't outgrow

Accepting Bitcoin is easy to start and easy to get wrong at scale. One invoice per order, a clear confirmation policy, honest fee handling and a written refund policy turn it into a payment method that runs itself, with no chargebacks at the end of it.

If your buyers ask for Bitcoin today, set it up properly once, offer a stablecoin next to it, and let confirmations, delivery and records happen automatically.