Paying for infrastructure in crypto, practically

Paying a hosting invoice in cryptocurrency is a two-minute operation once and a twenty-minute one the first time. The friction is not the technology — it is three mistakes that nobody writes down because writing them down means admitting they happen. All three are avoidable, and one of them is unrecoverable.

Picking a chain, by what it costs you

The coin you hold is usually the coin you pay with, and that is fine. But if you are buying for the purpose, the sensible criteria are transaction fee, confirmation time, and whether you care about the payment being publicly linkable to an address you use elsewhere.

Chains by cost and confirmation time

Chain	Typical wait	Linkable	Notes for a recurring invoice
Tron (TRC-20)	~1 min	Yes	Usually the cheapest way to move a stablecoin. Fees are paid in TRX, so keep a little of it around or the transfer simply fails to build.
Litecoin	~15 min	Yes	Cheap, boring, extremely reliable. A good default when you do not need a stablecoin.
Monero	~20 min	No	The only one on this list where the amount and the counterparty are not public. Fees are low and predictable.
Bitcoin	~20 min	Yes	Fees swing with congestion, occasionally by an order of magnitude. Fine for an annual invoice, irritating for a monthly one.
Ethereum (ERC-20)	~3 min	Yes	Fast and dependable, and the fee can exceed a small invoice outright. Check before sending, not after.

A stablecoin ticker is not a chain. USDT exists on Tron, on Ethereum and on several others; the addresses look different and the funds do not cross between them. Choosing “USDT” is only half a decision — the other half is the network, and it is the half that goes wrong.

Why the amount ends in odd decimals

An invoice for $39.00 that asks you to send $39.87 looks like sloppy rounding. It is the opposite: those decimals are how your payment is matched to your order without anyone attaching your name to it.

A provider that does not collect identity has a problem at reconciliation time. Two customers paying $39 on the same afternoon produce two indistinguishable transactions. Giving each invoice a unique fractional amount turns the amount itself into the reference — a nonce, in effect. It costs you a few cents and it removes the need for the provider to know anything about you.

The three ways it goes wrong

1. Wrong network — the expensive one

You copy a stablecoin address from an invoice expecting one chain and send on another. Whether this is recoverable depends entirely on whether the recipient controls a key on the chain the funds actually landed on. If they do, it is a support ticket. If they do not, nobody on earth can recover it, and a provider telling you otherwise is buying time.

The rule that prevents almost all of these: match the network on the withdrawal screen to the network on the invoice before you look at the address at all. The address is the last thing to check, not the first.

2. Round number — the annoying one

Covered above. Recoverable, always. Costs you an hour and a message.

3. A second payment to fix the first — the compounding one

This is the one that turns a small problem into a real one. Something looks wrong, so you send again. Now there are two transactions, one of which may be on the wrong chain, and any refund has to be untangled before anything else can happen.

Write to support before sending anything a second time. Nearly every genuinely unrecoverable case starts with a well-intentioned second payment.

The rate window, and what it protects

An invoice quoted in dollars and settled in coin has to fix an exchange rate at some moment. Most providers hold it for a short window — thirty minutes is common — and the window exists to protect both sides from a move between issue and confirmation.

What happens after the window is the part worth knowing before you need it. Reasonable behaviour is to credit the payment at the rate when it actually lands and settle the difference either way, with a small threshold below which nobody chases anybody. Unreasonable behaviour is to treat a late payment as unpaid while keeping the funds. Ask which one you are dealing with; the answer takes one sentence and tells you a lot.

Keeping books when the invoice is in coin

Your accountant does not care about the chain, and does care about three fields. Capture them at the moment of payment rather than reconstructing them at year end, when the rate you used is a guess.

1. The fiat amount on the invoice, which is what the service actually cost.
2. The coin, the quantity and the transaction hash, which is your evidence the payment happened and is verifiable by anyone.
3. The rate you acquired the coin at, if you bought it for the purpose. In many jurisdictions the difference between acquisition and spending is itself a taxable event, and that is a question for someone local rather than for a hosting page.

Keep the transaction hash with the invoice. It is the one piece of evidence that does not depend on the provider still existing, still having the record, or still being on good terms with you — which is the same reason to prefer verifiable things generally.

Our own handling of all of this is on the payment methods page: which chains, how many confirmations each needs, and exactly what happens in each of the three failure cases above, including the one where the honest answer is that the money is gone.

Written by the engineers who run the platform, and re-read 27 days ago. If something here is wrong or has gone out of date, say so from the panel — that is where about half of these came from.