Paying for hosting with cryptocurrency is a solved problem right up to the moment someone sends the right asset on the wrong network. That mistake is not recoverable, and it accounts for most of the support load at any provider that accepts more than one chain.
This guide explains how crypto top-ups work on this site, why the network selector matters more than the coin selector, and what to check before you press send. The specifics below — seven payment options, a 30 USD minimum, fixed confirmation counts and a manual review step — are the current behaviour of this deployment, not a generic description of the industry.
The model: a balance, not an invoice
There is no per-order crypto checkout. You top up your account balance once, and services are paid for from that balance. That has three practical consequences:
- One transfer can cover several services. A top-up is credited once and stays available.
- The minimum top-up is 30 USD. Smaller amounts are not accepted, which keeps network fees from swallowing the value.
- Every top-up is a separate payment record. Each one has its own address, amount, expiry and confirmation count, and each is reviewed before it is credited.
The dashboard keeps the ledger: pending top-ups, credited top-ups, and the debits that paid for orders.
The seven payment options
Each option is a specific asset on a specific network. They are not interchangeable, even when two of them share an address.
- BTC — Bitcoin mainnet. Native bitcoin only. A transfer on Lightning, on BNB Smart Chain as a wrapped token, or on Ethereum as WBTC is a different network and will not be credited.
- ETH — Ethereum mainnet (chain id 1). Native ether only, not an ERC-20 token sent to the same address.
- USDT — Tron (TRC20). The Tether contract on Tron,
TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t, with 6 decimals. - USDT — BNB Smart Chain (BEP20). The Binance-Peg contract
0x55d398326f99059fF775485246999027B3197955, chain id 56, with 18 decimals. - SOL — Solana mainnet-beta. Native SOL. A token transfer on Solana is not a SOL payment.
- TRX — Tron mainnet. Native TRX. USDT on Tron uses the same address but is a different asset and a different contract call.
- BNB — BNB Smart Chain mainnet. Native BNB.
Two of these share an address and are still different payments: USDT-TRC20 and TRX both arrive at the Tron address, and only the asset you selected is credited. The same applies on the EVM side, where the ETH address can technically receive BNB and BEP20 USDT; a transfer is credited against the network you chose when you opened the payment, not against whatever happens to land.
Why the network matters more than the coin
USDT exists on a dozen chains. The token on Tron and the token on BNB Smart Chain have the same ticker, the same issuer and the same face value, and completely different contracts, decimals and address formats. Sending one to the other is not a routing problem that support can fix; the funds are usually unrecoverable, because the receiving wallet does not control the keys that hold the token on the other chain.
The same logic applies one layer up. A BEP20 token sent to a Bitcoin address is not a near miss. An ERC-20 USDT transfer to the ETH address is a token transfer, not the native ether payment the screen asked for, and it is not credited automatically.
The safe rule: choose the network in the payment screen first, then copy the address from that screen, then check that your wallet or exchange is set to that exact network before you paste anything.
The step-by-step
- Open the top-up screen in the dashboard and enter the amount in USD. It must be at least 30 USD.
- Select the asset and the network together. Nothing is preselected, deliberately: the two fields are one decision.
- Read the amount. The screen shows three separate numbers — the USD amount, the exchange rate used, and the exact amount of the asset to send. They are not the same number and they are not interchangeable.
- Copy the amount exactly. Trailing zeros are trimmed for readability, but the value is carried at the asset's full precision: 8 decimals for BTC, 6 for USDT-TRC20 and TRX, 9 for SOL, 18 for ETH, BNB and USDT-BEP20. Do not round it, and do not type it from memory.
- Send the transfer from a wallet you control, or as an on-chain withdrawal from an exchange, on the network you selected.
- Submit the transaction hash (TXID). The hash is how the payment is matched to your record. Keep a copy of it yourself as well.
- Wait for confirmations. The screen shows progress against the required count for that network.
- Wait for review. A verified transaction is reviewed by an administrator before the balance is credited, and the credit is written once.
Nothing about step 8 is automatic. A transfer that has reached finality still sits in a review queue, so a top-up is not instant even after the chain has settled it.
Confirmations, in plain terms
A confirmation is a block mined on top of the block that included your transaction. More confirmations mean more work would be required to rewrite history. Each network is different, and the counts here reflect that:
- BTC: 3 confirmations
- ETH: 12 confirmations
- USDT (TRC20): 19 confirmations
- TRX: 19 confirmations
- USDT (BEP20): 15 confirmations
- BNB: 15 confirmations
- SOL: 1 confirmation, because the transfer must be finalised rather than merely included
Bitcoin's three confirmations take roughly half an hour on average; Ethereum's twelve take a few minutes; Tron's nineteen take about a minute. Solana finalises in seconds. The counts are not arbitrary — they are the point at which the risk of a reorg is low enough to credit a balance — but they do mean that the fastest-looking option is not always the one you can rely on for a deadline.
The amount is a quote, and quotes expire
Crypto prices move. The amount you are asked to send is calculated from a price read at the moment the payment is opened, with the conversion stored server-side so the screen, the review and the ledger all refer to the same figure.
Two clocks matter:
- The price is refreshed continuously. A rate older than the freshness window is re-read rather than reused, so the quoted amount reflects the market when you opened the payment, not an hour earlier.
- The payment request expires. The amount and the address are valid until the countdown on the screen reaches zero — 60 minutes by default on this deployment. After that, open a new top-up and use the new amount.
Sending the amount from an expired request is the second most common way to lose money: the transfer arrives, but it no longer matches an open payment, and matching it by hand is slow at best.
What happens with underpayment and overpayment
Send less than the quoted amount and the shortfall is yours: the payment is credited at what arrived, not at what was requested. Send more and you have created a surplus that has to be reconciled by a human.
The simplest defence is to send the exact amount once, from a wallet where you control the fee. Leaving the fee on the receiving side is not an option; network fees are paid by the sender, to the network, and never reach the provider.
Common mistakes, in order of frequency
- Wrong network. The single most expensive error on this list, and the reason the payment screen names the network in three places.
- Wrong asset on a shared address. Native TRX instead of USDT-TRC20, or the reverse. The address is right; the transfer is not the payment.
- Sending from a chain that is not supported. Arbitrum, Base, Polygon, Optimism and Lightning are all legitimate networks that are not part of this list. A USDT transfer on Polygon is not a USDT-TRC20 transfer, however similar the ticker.
- Rounding the amount. Trimming the last four decimals of an 18-decimal token turns an exact payment into a shortfall.
- Sending after expiry. The address is still valid; the request is not.
- Reusing a TXID. One transaction credits one payment. Submitting the same hash twice does not double the balance and slows the review down.
- Clipboard malware. Verify the first and last six characters of the address against what is on screen. Address-swapping malware is common and effective.
Records, tax and accounting
Keep, for every top-up: the transaction hash, the asset and network, the amount sent, the USD value at the time, and the date. The dashboard shows the credited amount; the chain shows the transfer; your own records should show both.
Paying in crypto does not change any tax obligation. In most jurisdictions a payment in crypto is a disposal of an asset at its market value on the day, which has its own reporting consequences. A ledger of amounts and dates is the minimum you need to reconstruct that later.
What this deployment does not offer
Only the seven rails above are accepted. There is no card checkout, no PayPal and no bank transfer, and the payment screen is the authoritative list — if an asset is not in the selector, it cannot be settled. The same applies to the hardware: the VPS catalogue shows the configurations that can be paid for from a credited balance, and every one of them is prepared manually after review.
If your reason for paying in crypto is privacy, the privacy guide is honest about what a public blockchain does and does not hide. If you are still deciding where the server should sit, the location guide covers latency and jurisdiction, and the offshore hosting primer explains the rest of the model — including why an order is provisioned by hand after the payment clears review.