Accept Bitcoin
for digital downloads.

Taking Bitcoin for a digital download is not hard. Taking it safely is a small engineering problem: you need a wallet you control, a quote the buyer can trust, a payment check that cannot be faked, and a download that expires.

Most “accept Bitcoin” advice stops at “paste a wallet address on your site.” That gets you a payment. It does not get you a reliable order. The buyer can pay the wrong amount, reuse another buyer’s transaction ID, or claim a payment that never happened. You can hand over a file before the money is really yours.

This guide covers the whole path for a digital product: quote, checkout, verification, delivery, and the edge cases that otherwise turn into support tickets.

What you need before the first sale

• A self-custody wallet. Not an exchange balance. Back up the seed phrase offline, and test recovery before you take a real payment.
• A receiving address strategy. A fresh address per order is strongest. If your wallet cannot do that, use a dedicated address per product and pair it with a unique amount and a short time window.
• A storefront page. It can be a static page. It needs the product, the fiat price, the BTC quote, and a clear “pay with Bitcoin” action.
• A verification endpoint. A serverless function or small server that checks the transaction against an independent source, not the buyer’s screenshot.
• Private file storage. The deliverable must not sit at a public URL. A public link is a permanent leak, even if you later delete the file.
• A written delivery and refund policy. Digital goods are usually final, but “usually” is not a policy. Put the terms on the product page and checkout.

The five-step flow

1. Price in fiat, quote in Bitcoin

Keep the product price in the currency you understand. At checkout, convert it to BTC at a live rate, then lock that amount for a short window — ten to fifteen minutes is common. Show the fiat price, the BTC amount, and the expiry time on the same screen.

Use integer satoshis in your code. Floating-point BTC amounts invite rounding bugs, and a one-satoshi mismatch should not be a support ticket.

2. Show a QR code and an exact amount

The buyer should be able to scan a QR code, copy the address, or open a bitcoin: URI. The URI can include the address, amount, and a label. Test it with at least two wallets before launch; wallet support for URI parameters is not perfectly uniform.

Make the network fee explicit. The buyer pays the miner fee. If your checkout implies the fee is included, you will spend the first week explaining why the received amount is lower than the sticker price.

3. Verify the transaction on-chain

Never trust a transaction ID by itself. Check that the transaction exists, that one of its outputs pays your address, and that the amount covers the quote. Then decide how many confirmations you require.

This is the step most DIY stores get wrong. The full check, including a code example and the common traps, is in how to verify a Bitcoin payment before delivering a file.

4. Gate the download

Do not send a permanent file URL. On a successful check, issue a short-lived signed token that names one product and expires quickly. The download endpoint validates the token and streams the file from private storage. The plaintext file should never be reachable directly from the public web root.

If you sell multiple products, scope the token to the product ID. A token for a $4 checklist should not unlock a $19 storefront kit.

5. Record only what you need

For reconciliation, store the product ID, the transaction ID, the amount, and the timestamp. You do not need a customer database to deliver a file. If you collect an email for support, say so and keep it separate from the payment flow.

Compare your options

There is no universal winner. A hosted gateway is sensible if you want invoices and do not want to run infrastructure. A static store is sensible when you want a small catalog, a direct wallet, and no platform account. BTCPay Server is sensible when you want open-source tooling and are willing to operate it.

Edge cases that turn into support tickets

• Underpayment. Do not unlock. Show the shortfall and let the buyer send the difference or contact you.
• Overpayment. Decide whether to deliver and keep the difference or refund the excess. Put the rule in your policy.
• Payment after the quote expires. The BTC amount may no longer match the fiat price. Do not silently accept it. Give the buyer a fresh quote or a refund path.
• Zero-confirmation payments. A mempool sighting can be replaced or orphaned. For cheap products, the risk may be acceptable; for expensive ones, wait for confirmations.
• Duplicate transaction IDs. If several orders share one address, a buyer may submit another buyer’s txid. Use a unique address per order or a unique amount-and-time window, and mark used transaction IDs as consumed.
• Wrong network or asset. A testnet transaction or a different coin is not payment. Check the network and the asset explicitly.

Costs, taxes, and rules

The obvious saving is the card processor’s percentage. The costs do not disappear; they move:

• Network fees are paid by the buyer, but they affect whether a small product is practical.
• Hosting and verification cost something, even if it is only a free-tier worker and your time.
• Volatility is yours once the payment arrives. Some sellers convert immediately; others keep a BTC balance deliberately.
• Tax and consumer law still apply. Bitcoin does not make a sale invisible to a tax authority, and it does not remove refund rights that your jurisdiction grants.
• Support is real work. Every edge case above needs an answer a buyer can understand.

FAQ

Keep reading