How to Accept Bitcoin in Your Online Store Without a Middleman

A small business owner hand-stitches a leather wallet at a wooden workbench, with a closed laptop beside the tools.

To accept bitcoin in an online store, you need three pieces: a wallet you control, payment software that creates a unique invoice for each order, and a plugin that connects that software to your checkout. The plugin is the least important choice. What matters is who holds the money between checkout and your wallet. One option is a custodial processor that takes a percentage and can freeze your balance. The other is self-custodial software that pays you directly.

TL;DR:

  • The real decision is custody: a custodial processor holds your coins and takes a cut, while self-custodial software sends payments straight to your wallet.
  • Each order gets its own invoice and address, which lets your store match payments to orders automatically.
  • On-chain bitcoin suits larger baskets. Lightning suits small purchases that need to settle in seconds.
  • Your store software should only ever hold a watch-only extended public key, never your private keys.
  • Raise your wallet's address gap limit, or a restored wallet may appear to be missing customer payments.
MYNTLI

Want self-custodial bitcoin payments, without the server work

See how Myntli installs and manages a BTCPay node that pays straight into your own wallet.

Visit →

Table of Contents

Three Ways an Online Store Can Take Bitcoin, and Who Holds the Money in Each

A person places a small ceramic cup on a table beside a large handcrafted wooden armchair in a workshop showroom.

Every bitcoin checkout setup falls into one of three models. The difference between them is not the look of the payment page. It is where the coins sit after your customer pays.

Custodial processors. The processor receives the bitcoin, credits your account and pays you out later, often converted to dollars. Setup is easy, but you pay a percentage on every sale. You also usually go through identity checks, and your balance can be held or frozen under the processor's terms.

Self-hosted, self-custodial software. You run open-source payment software such as BTCPay Server on your own server, connected to your own bitcoin node. Payments land directly in your wallet, and no third party takes a cut or can freeze funds. The catch is that you now maintain a server, a node that must stay synced, and software updates.

Managed self-custodial hosting. Someone else runs the server and node, but your store is configured with your wallet's public key. Customers still pay straight into your wallet. You trade a flat fee for not doing the system administration.

Model Who holds funds Typical cost Can funds be frozen? Your workload
Custodial processor The processor Percentage per sale Yes, under their terms Low
Self-hosted BTCPay Server You Server costs plus your time No High: node, updates, backups
Managed self-custodial You Flat monthly fee No Low

Our view: for most small and mid-sized stores, managed self-custodial is the right choice. Custodial processors bring back the same percentage fees and counterparty risk that make card payments annoying. Fully self-hosted setups are excellent, but only if someone on your team actually wants to patch servers. For a deeper breakdown of the trade-offs, see our guide to custodial vs non-custodial crypto payment processors.

What Actually Happens at Bitcoin Checkout: Invoice, Address, Confirmation

Hands hold a small hardware wallet with a dark, switched-off screen over a neat desk.

When a customer picks bitcoin at checkout, the payment software creates an invoice. That invoice locks in the price in bitcoin at the current exchange rate, generates a fresh receiving address, and starts a countdown. The customer scans a QR code or clicks a payment link, and their wallet fills in the amount automatically.

A fresh address for every order. Payment software derives a new address for each invoice from your wallet's extended public key. That is how your store knows which payment belongs to which order without asking the customer for a reference number. It also keeps your customers' payment histories from being trivially linked on the public blockchain.

A price lock with an expiry. Because the bitcoin price moves, the quoted amount is only valid for a limited window. BTCPay Server's default invoice expiry is 15 minutes, and you can change it in the store settings. If the window is too short, customers paying from slow exchange withdrawals miss it. If it is too long, you absorb more price movement.

Confirmations. An on-chain payment is first broadcast to the network and then included in a block. The Bitcoin whitepaper models the network producing a block roughly every 10 minutes. Each additional block on top makes reversing the payment harder. You decide how many confirmations to wait for before marking an order paid:

  • Zero confirmations for instant digital goods of low value.
  • One confirmation for most physical goods.
  • Several confirmations for high-value orders.

Underpayments. Customers who pay directly from an exchange sometimes have the withdrawal fee subtracted from the amount sent. That leaves the invoice a few cents short. BTCPay Server lets you set a payment tolerance percentage, so an invoice that is fractionally underpaid still counts as paid instead of leaving the order in limbo.

On-Chain or Lightning: Match the Payment Rail to Your Basket Size

Bitcoin gives your online store two payment rails, and each fits a different kind of order.

On-chain payments settle directly on the Bitcoin blockchain. The customer pays a network fee that depends on how busy the network is, not on the order value. That makes on-chain sensible for a $300 order and awkward for a $4 sticker, where the fee can be a noticeable share of the price during congested periods.

Lightning payments move over payment channels and settle in seconds, usually for a tiny fraction of the on-chain fee. Lightning invoices follow the BOLT 11 payment encoding specification, which builds an expiry into every invoice.

Under BOLT 11, a Lightning invoice that doesn't state its own expiry defaults to 3,600 seconds: one hour, after which it can't be paid.

Lightning has a cost. Receiving Lightning payments yourself means running a Lightning node with channels that have enough inbound liquidity to accept payments. That is genuinely more operational work than on-chain. If you sell low-priced digital goods, tips or subscriptions, it is worth it. If your average order is $150 of furniture parts, on-chain alone is fine.

Our recommendation: enable both if your setup supports Lightning, and let the customer choose. Offering only on-chain payments to buyers of $5 items guarantees abandoned checkouts whenever fees spike.

Set Up the Wallet First, and Watch the Gap Limit

The wallet is where your money actually lives, so choose it before you touch any plugin. For a store, you want a wallet that can export an extended public key (an xpub, or zpub for native SegWit addresses). Your payment server only needs that public key to generate receiving addresses and watch for payments. It never needs your private keys or seed phrase.

Use a dedicated wallet or account for the store. Mixing store revenue with personal coins makes bookkeeping painful and links your personal transaction history to your business. A separate account under your hardware wallet works, as does a separate wallet entirely.

Keep the seed phrase offline. If your store server is compromised, an attacker who finds only an xpub can see your incoming payments but cannot spend a single satoshi. That is the main security advantage of a watch-only setup.

Pro Tip: Raise the address gap limit in your wallet software to 100 or more before you go live. Your store generates a new address for every invoice, including the many invoices customers open and never pay. Wallets stop scanning for funds after a run of unused addresses. If more unused addresses than that pile up in a row, a wallet restored from your seed may show a balance lower than what you actually received. The coins are safe on the blockchain, but your wallet won't look for them until you raise the limit and rescan.

20 addresses: that is the default gap limit in BIP 44, and a store with a busy abandoned-cart rate can blow past it in an afternoon.

The BIP 44 specification sets that limit of 20 for good reason in personal wallets. A merchant wallet behaves differently, so adjust it.

Volatility, Refunds and Taxes: The Operations Work After Checkout

A person wraps a ceramic vase in tissue paper next to an open plain cardboard box on a packing table.

The setup guides usually stop at "payment received." Running a bitcoin-accepting online store involves three more decisions.

Price volatility. When you accept bitcoin into your own wallet, you hold bitcoin. If you price in dollars and need dollars to pay suppliers, decide on a routine in advance. For example, sell a fixed share of each week's bitcoin receipts to cover costs and keep the rest. A self-custodial setup gives you that choice. A custodial processor that auto-converts makes it for you, and charges for the privilege.

Refunds. Bitcoin payments are final, and there is no chargeback mechanism. That protects you from friendly fraud, but you have to issue refunds yourself. BTCPay Server includes a refund flow that creates a claimable payout link for the customer. The link lets you refund either the original bitcoin amount or the original fiat value, so write your refund policy to say which one you use.

Taxes. Rules vary by country, so check with an accountant where you operate. In the United States, the IRS guidance on digital assets treats them as property. A business that receives digital assets as payment generally recognizes income at their fair market value when received. Selling those coins later can create a separate capital gain or loss. Keep the dollar value recorded on each invoice, because your payment software's export becomes your audit trail.

Connecting Bitcoin Payments to Your Online Store Platform

Once the payment server and wallet are ready, the plugin is the easy part. BTCPay Server has integrations for most common shop platforms, including:

  • WooCommerce
  • Shopify
  • Ghost
  • Magento
  • PrestaShop
  • Drupal Commerce
  • Invoice Ninja

Each integration does the same job. It sends order details to your payment server, displays the invoice to the customer, and updates the order status when payment is confirmed. The steps that cause trouble are usually these:

  • Webhook delivery. Your store has to receive payment notifications reliably. Firewalls, caching plugins and security plugins that block inbound requests are the most common reason an order is paid but still shows "pending."
  • Currency settings. Make sure the store currency matches the invoice currency, or you'll quote the wrong amounts.
  • Order status mapping. Decide which payment states map to "processing" versus "completed" in your shop.

If your platform isn't on that list, BTCPay Server's API lets a developer create invoices and receive webhooks from any custom checkout. For the full picture of how a gateway like this fits together and what it costs to run, read our explainer on how a non-custodial crypto payment gateway works.

Take Bitcoin in Your Online Store Next Week, With No Server to Run

Everything in this guide assumes someone is keeping a node synced, applying updates and debugging webhooks. Myntli does that part for you. For a flat $29 a month, you get a hosted BTCPay Server store on our node, connected to your WooCommerce, Shopify, Ghost, Magento, PrestaShop, Drupal Commerce, Invoice Ninja or ReplaPay shop. Payments go straight into your own wallet. We take no percentage, never hold your funds, and require no KYC on your store. If you want the node on hardware you own, we'll install a full BTCPay Server node on your server for $449.

One honest caveat: self-custody means the seed phrase is your responsibility, and nobody can recover it for you, including us. If you don't have a self-custody wallet yet, Myntli will walk you through setting one up. Do that step carefully before your first sale.

Frequently Asked Questions

Do I need to run a bitcoin node to accept bitcoin in my online store?

Self-custodial payment software needs a node to verify payments independently. You can run that node yourself or use a managed host that runs it for you. Custodial processors don't require a node, but they hold your funds until they pay you out.

Can customers get a chargeback on a bitcoin payment?

No. Bitcoin transactions are final once confirmed, so there is no chargeback mechanism like there is with cards. Any refund has to come from you, usually through a refund link generated by your payment software.

Is it safe to give my store software my extended public key?

An extended public key lets software generate receiving addresses and see incoming payments, but it cannot spend funds. The main risk if it leaks is privacy, because someone could view your store's payment history. Never enter your seed phrase or private keys into store software.

Should I accept Lightning, on-chain bitcoin, or both?

If your average order is small, Lightning prevents network fees from eating into the purchase. On-chain alone works fine for larger orders. Offering both lets customers choose, which reduces abandoned checkouts when on-chain fees rise.

How many confirmations should I wait for before shipping an order?

One confirmation is a reasonable default for most physical goods. Low-value digital goods can often be delivered on zero confirmations. High-value orders justify waiting for several blocks.

Sources