Why "accepts Bitcoin" tells you very little
Most hosts that take Bitcoin bolted it onto a billing system designed for cards. That works, but the details decide whether paying in BTC is pleasant or a monthly chore: whether a payment is on-chain or Lightning, who generates the invoice address, how many confirmations the host waits for before it hands you a server, what happens when you overpay or underpay, whether you can get a refund, and whether the billing model assumes a stored card that can be charged on the first of the month. This page goes through each of those, and ends with exactly how BitVPS handles them, including the ones it does not do well.
On-chain versus Lightning
An on-chain payment is a normal Bitcoin transaction: it goes into the mempool, a miner includes it in a block roughly every ten minutes, and the recipient decides how many blocks to wait. Fees depend on mempool congestion and on the fee rate your wallet chooses; for a server costing tens of dollars the fee is usually a small fraction, but during congestion it can be noticeable and a low-fee transaction can sit unconfirmed for hours. Lightning payments settle in seconds for a fee of a few satoshis, but you need a funded channel or a custodial wallet, and the host needs a node with inbound liquidity.
For hosting specifically, the practical difference is at the small end. A one-day server costing under a dollar is awkward on-chain because the fee can approach the price and because most processors enforce a minimum. Lightning is the natural fit for that. For a month or more of hosting, on-chain is fine, and it has the advantage that it works with every wallet, including cold storage.
- Ask: does the host accept Lightning at all, and is it native (its own node) or through a processor that converts for it?
- Ask: what is the minimum order in BTC? Processors commonly impose a floor of a few dollars per coin.
- Ask: does the invoice lock the BTC amount, and for how long? Fifteen minutes is common; if you take longer, the rate may be re-quoted.
Payment processor versus self-hosted BTCPay
There are two ways a host turns your Bitcoin into a paid invoice. It can run its own payment server, most often BTCPay Server, which generates a fresh address from the host’s own wallet for every invoice and watches the chain itself. Or it can use a hosted processor, which generates the address, watches for the payment, and tells the host’s billing system when it is paid; the processor may settle in crypto or convert to fiat for the host.
From the buyer’s side the difference is who sees what. With self-hosted BTCPay, only the host sees the invoice. With a processor, the processor also sees the invoice amount, the address it generated, the incoming transaction and typically the IP that loaded the payment page, and it has its own terms about screening transactions. For a small hosting payment this is rarely an identity problem on its own, since you do not open an account with the processor, but it is one more record. Hosts that run BTCPay usually say so because it is a selling point; if the payment page is on a third-party domain, it is a processor.
Confirmations and provisioning delay
A card payment is approved in a second. A Bitcoin payment has a built-in wait, and the host chooses how long. Zero-confirmation acceptance means the server is created as soon as the transaction appears in the mempool; it is fast but a few hosts have been burned by replace-by-fee double spends and most no longer do it for anything larger than trivial amounts. One confirmation, typically ten to thirty minutes, is the common compromise. Some processors wait for two or more on larger invoices.
- Pay with a fee rate that targets the next block or two. Saving a few cents on fees and waiting two hours for a server is a bad trade.
- Send the exact amount the invoice shows, in one transaction. Processors match payments to invoices by address and amount; two partial payments often need manual handling.
- Keep the transaction ID until the server is live. If the payment is not credited, it is the only thing support can use to find it.
- Expect the provisioning email, not the payment page, to be the signal. Payment pages usually show "paid" after detection and "confirmed" after the first block; the server is built after the second state.
Refunds, overpayments and underpayments
Crypto payments are final on the chain, so refunds are a policy question for the host, not a button. Read the terms: many hosts state that crypto payments are non-refundable, some offer account credit instead of a refund, and a few will send coins back to an address you provide after a support ticket. Also check how underpayments are handled. If the exchange rate moves while you are paying, or your wallet deducts the fee from the amount, the invoice can land a few percent short; a good processor credits the partial amount and lets you top up, while a strict one expires the invoice and leaves you to chase the funds through support.
Prepaid versus postpaid, and how granular the term is
Card billing is naturally postpaid or auto-renewing: the host stores a payment method and charges it on a schedule. Bitcoin cannot be pulled from your wallet, so every crypto host is prepaid in some form, and the models differ in how you top up and what happens when the balance runs out.
| Model | How you pay | When the money runs out | Good for |
|---|---|---|---|
| Monthly invoice | One invoice per billing cycle, due before renewal | Grace period, suspension, then deletion on the host’s schedule | Long-lived servers where you remember to pay |
| Account balance | Deposit crypto into a balance; usage is deducted hourly or daily | Services stop when the balance hits zero; balance is often non-withdrawable | Many short-lived servers under one account |
| Prepaid term in days | Pay for an exact number of days up front; extend before expiry | Server deleted at end of the paid period after a reminder | Accountless use, temporary servers, precise spend control |
| Annual prepay | One or more years paid at once | Renewal notice; service lapses if unpaid | Hosts aimed at stable long-term projects |
Granularity matters more than it looks. A host that only bills monthly cannot sell you a server for three days of testing; a host that bills by the hour from a balance can, but you need an account to hold the balance. Day-granular prepaid terms sit between the two: no account, but a one-day minimum. Whichever you choose, find out the exact timeline from expiry to deletion, because with crypto nobody can save the server by charging a card you forgot about.
How BitVPS handles each of these
- On-chain only. BitVPS accepts Bitcoin on-chain, plus Monero, Ethereum, Solana and other coins through the same crypto checkout, and cards via Stripe. There is no Lightning option. That is the main gap for very small or very frequent payments, and it is stated here plainly.
- Processor, not self-hosted. The crypto checkout is handled by a payment processor that generates a one-time address per invoice; you do not open an account with it and no KYC applies at these sizes, but it does see the invoice. Card payments go through Stripe, which is what the privacy policy describes.
- Confirmation wait. The server is provisioned after the payment confirms, so with Bitcoin plan on roughly ten to thirty minutes for the first block, longer if you choose a low fee. Monero and the faster chains are usually credited within minutes. The access-link email is the signal that the server exists.
- Minimums and rate lock. Each coin has a small minimum, a few dollars, shown at checkout; cards go down to $0.50. The crypto amount is fixed for the lifetime of the invoice, so pay promptly. Underpayments are credited against the order and support can top up or refund.
- Prepaid in days. You choose a term from one day up to years; the price is the monthly rate divided by 30 times the days, identical for every payment method. Monthly recurring subscriptions are card-only. The server is deleted at the end of the paid period unless extended; a reminder email goes out before that. Extending is done from the access page and can be paid in any supported coin.
- No account, so no order history. Each server has its own magic link; there is no page listing everything you have ever bought. Keep the emails.
Which plan to pick
Because the Bitcoin fee is roughly fixed per transaction, it is proportionally smaller on longer terms; paying for a month or a quarter at once on the BVX11 (2 vCPU, 2 GB, 40 GB NVMe, from $10/mo in the EU) is more efficient than paying daily. For a one-day test, the crypto minimum means you may need two or three days on the cheapest plan, or a card. For a Bitcoin node itself, start at the 160 GB tier so pruning is a choice rather than a necessity. Configure a server, choose BTC at checkout, send the exact amount with a sensible fee, and the access link arrives on the first confirmation.