How Hosting Providers Accept Crypto Payments: Costs, Statuses, and Refund Rules

Several international card payments failed on you last month. The bank declined, the customers did not come back, and then someone wrote to support asking whether they can just pay in USDT. The parts you cannot price are the operational ones: what the processing costs, what you tell a customer who wants an unused balance back, and when it is safe to start a server while a payment is still confirming.

The short version: the integration is a payment method inside your billing panel, next to cards. What decides whether this helps you or fills your support queue is three decisions you make yourself — when a service goes on and when the balance is credited, who absorbs the difference between the invoiced amount and the amount that lands, and what a refund means when there is no chargeback. Two of them belong in your terms of service before the first payment arrives.

Is your company allowed to accept it?

Start here, because one possible answer ends the project.

If you settle inside Russia, the answer is no. Since 1 September 2026 the ban sits in part 6 of article 1 of federal law 282-FZ of 4 August 2026: digital currency may not be accepted as a means of payment or as consideration for goods, works or services on Russian territory.

What changed matters more than the new number. Until 1 September the rule lived in article 14 of law 259-FZ and listed exactly whom it bound — Russian legal entities, Russian subdivisions of foreign organisations, and individuals present in the country for 183 days or more over 12 months. Law 283-FZ repealed that article, and the ban moved across without the list: the new wording is territorial and does not narrow the circle of persons it covers.

The same article separately prohibits disseminating information about accepting digital currency as payment, which reaches the "we accept USDT" line on a pricing page as well as the wallet behind it. So the first question is no longer how many days a year the owner spends in Russia; it is where the settlement and the offer land. Registering the company abroad does not answer that by itself, and it remains a question for a lawyer. The law carries one exception: settlements under a foreign-trade contract between a resident and a non-resident (part 7, item 1). This describes Russian rules as of 7 September 2026 and is not legal advice.

For any other jurisdiction, no web page can give you a verdict — but you can walk into a lawyer's office with three questions instead of "is crypto legal here":

1. Where does the settlement actually take place? The Russian ban turns on territory, so this is the first question rather than the last; if another country's rules turn on where your servers or customers sit, your lawyer will say so.
2. Under which country's law does the entity that will receive the money exist? Your company and your customers can sit under different rules.
3. Where is the offer published, and does accepting require a licence — and if so, does it sit with you or with the processing service?

This article is not legal advice. The law, the article and the revision date above are what a lawyer checks your case against, and the answer should come back in writing before you switch anything on.

A button on the site, or a payment method in billing?

Into billing. Not a button.

This is where hosting parts company with a shop. A shop sells one order and closes it. You sell a renewable service with a balance, a term, an hourly or monthly deduction and a suspension rule. Your panel already owns invoices, renewals and suspension, and a crypto method has to live inside that, so that "paid" means the same thing whether the money came by card or on-chain.

For a billing panel, a crypto method is an ordinary gateway. The one whose documentation states that plainly is BILLmanager: ISPsystem's own documentation has a Provider settings section with a Payment gateways branch, where crypto modules sit in the same list as card acquirers. If you run WHMCS, open your own gateway list and look — whether you get a ready module, a third-party one or an integration your developer writes depends on what is in that list, and that is the first thing to establish.

What you are avoiding is a separate "pay with crypto" page next to checkout. Money arrives at an address and the system has no idea which account it belongs to, so someone matches it by hand, at night, while a customer with a stopped VPS opens a second ticket. Every exception — a late payment, a wrong amount, a duplicate — becomes somebody's manual decision.

What accepting it costs

Processing: 1% of each successful payment, from 0.5% at high volume. That is CryptumPay's rate, and the fee can be passed to the customer.

Whether you pass it on is a question of invoice size. On a large prepaid top-up a percent disappears. On, say, a nine-dollar monthly VPS plan, a surcharge line is more visible than the money in it.

The network fee is separate. It is what the chain charges to move coins, it sits outside the processing percentage, and it is paid by whoever sends the transaction — on the way in, that is your customer, out of their own wallet.

Which networks you accept is therefore a money decision, and it runs on your own numbers: take the network your customers already hold USDT on, then weigh its transfer fee against your smallest invoice. If sending a day's top-up costs a noticeable slice of the top-up itself, that network cannot carry your hourly-billed customers, whatever it does for a nine-hundred-dollar GPU order. Start with one or two networks and add more when customers ask; what each network choice costs is worth reading before you commit.

Two more lines belong in the same spreadsheet, and their numbers come out of your contract: what a withdrawal costs, and what the conversion of an incoming asset into USDT costs you, if anything. Ask both before signing.

The rail this actually competes with is the international bank transfer you offer the customer whose card just failed — where arrival depends on correspondent banks nobody in the conversation controls, and neither of you has a status to watch while it travels. For a developer who needs a GPU instance back today, that uncertainty is the whole problem, and the rest of the trade-offs between crypto and a bank transfer follow from it.

The three decisions your billing panel will not make

No module ships a default for the next three, and each is cheaper to decide now than in front of a customer.

When the service goes on, and when the balance is credited

A crypto payment arrives in stages, and the shape is the same at any processing service: the order is created, the transaction is seen on-chain, confirmations pile up, the payment goes final. The names differ from service to service; these are CryptumPay's, and so is the detail that the after-fees figure arrives only with the last of them. created — the customer picked a currency and got an address, nothing has moved. pending — an incoming transaction is visible on-chain but has not gathered enough confirmations. crediting — confirmations are in and the funds are being credited to your merchant balance. finished — the payment is complete, and the income field, the amount credited after all fees, appears only in this last webhook.

That last detail decides the design. One rule cannot cover both switching a service on and crediting a balance, because at crediting the after-fees figure has not been sent to you yet. So split the decision:

• Service continuity is decided at crediting. A running service keeps running: you do not suspend, you do not stop the GPU job, you do not expire the disk.
• The balance figure is settled at finished, the moment you know what actually landed after fees.

For a renewal of a service already running: keep it alive at crediting, credit the balance at finished. The exposure is one billing period from a customer you know, and the alternative is downtime for somebody who has paid. For a first order from a customer you do not know: wait for finished for both. Nothing is running yet, so the wait costs him nothing, and this is where an unfinalised payment costs you a real machine. The same split answers the GPU case, where a returning customer topping up mid-run cannot sit out a confirmation wait.

Whether you can express that depends on your module. If the crypto method in your panel credits on its own status logic and exposes no hook, you either live with its behaviour or take the callbacks yourself — and the second option is where "add a payment method" turns into development. Establish which one you are in before you promise a date.

If you do wire it yourself, subscribe to both webhook types: customerOrder fires on every status change of a customer's order, so it carries the ladder above, and merchantOrder fires when a merchant order is created. Make the handler idempotent, so processing the same event twice never credits a balance twice. And put the payment on the customer's page for support — hash, expected amount, received amount, status. The details are in the guide to payment statuses and webhooks and the lifecycle and webhook reference.

Who absorbs the exchange difference

Two different events get filed under this heading, and they need different answers.

The first is price drift: you invoice in dollars, the customer pays in an asset that moves, and by the time it lands it is worth something else. The fix takes volatility out of the window — invoice in USDT and fix the amount. A 100 USDT invoice is 100 USDT when it arrives. People can still pay in what they hold, including BTC, ETH, TRX, BNB, SOL, TON or XRP, because CryptumPay converts incoming funds to USDT as soon as they arrive, so your billing keeps one unit of account and needs no price feed. How long each of those takes to settle depends on the chain: when a TON payment counts as received walks through one of the quicker ones.

The second event happens on a plain USDT invoice too: the amount that lands is short. A wallet deducted its fee from the transfer, the customer typed a round number, the funds took an unexpected route. Services differ in whether they reconcile a short payment for you or drop it on your desk — ask before you sign; CryptumPay handles under- and overpayments automatically. Either way, your rule for what counts as paid in full is yours to write, and until you write it every shortfall lands on you.

That rule is easier to derive than to look up. A shortfall on the order of a network fee is a wallet that did the arithmetic differently — waving it through costs cents and saves a ticket, and the threshold should scale with the invoice, since the same gap is noise on a GPU order and a real discrepancy on a day of VPS. A shortfall materially larger than that is a customer paying less than you invoiced: credit what arrived, leave the invoice open, tell him what is missing. The dial lives in your own billing rules, where an invoice gets marked paid. The anatomy of short and failed payments is worth reading while you pick the number.

What a refund means when there is no chargeback

"No chargebacks" is sold to you as a benefit, and half of it is. A customer cannot reverse a settled on-chain payment by calling their bank, so the pattern where somebody runs a proxy farm for a month and then disputes the charge does not exist here. But it is a symmetry, not a gift: the same finality means you cannot make a refund automatic. A refund is a new outgoing payment that you decide to send.

That matters most for the prepaid balance most VPS and GPU customers sit on. An unused remainder is an obligation of yours, and its terms are whatever you wrote — so write them.

Three clauses that can sit in your terms verbatim:

1. An unused balance is returned within a stated number of days of a written request from the account holder, less the network fee for the transfer.
2. Service already rendered is not refunded — hours consumed, traffic used, a GPU job that ran.
3. The refund is sent to the address the payment came from. If the customer asks for a different address, it goes only after your own verification that the request comes from the account holder.

The third clause is the one doing real work. Refunds to an arbitrary address are a laundering route through your own console: pay in from one wallet, ask for the "refund" to another, and your company has performed the transfer. Sending money back where it came from closes that by default, while the exception keeps a path open for the customer who genuinely lost a wallet. Read how crypto refunds actually work before you draft the clause, and check it against a merchant's AML duties.

How the money gets out to you

Funds sit on a merchant balance until you move them, and withdrawal terms are where services differ most: some set a minimum amount, some hold funds for a period after crediting, some charge a fee of their own on top of the network fee. Get all three in writing before you sign. In CryptumPay there are two paths, with different conditions.

By hand, from the console. Available at any time: no waiting period, no IP allowlist, no minimum amount. You name the recipient address, and it can be any address you like — the path for irregular movements, a monthly sweep or a one-off payout.

Through the API, POST /v1/withdraw. The same operation without a human, and here an IP allowlist tied to the API key is required. One call sends one transfer to one address, so scheduled sweeps are a loop in your own code.

Launch also needs a merchant account, a Project ID from the console and your domain added to the project, because the payment widget will only work on authorised domains. That squares with the billing-first rule: the widget is the payment page your panel opens once an invoice exists, so the domain you authorise is the one your panel serves from.

One more thing for support: in CryptumPay, funds flagged as suspicious are held before they reach your balance. A payment can sit in review, and the customer should hear that as a status, with a time when you will come back to him.

When not to do this yet

Three signs the integration should wait:

• Your billing cannot hold a balance. If every payment must land against one invoice for one fixed plan, you lose the top-up model that makes this worth having for hourly VPS and GPU customers. Fix that first; the balance model is the prerequisite.
• Nobody can say who signs off a refund, and out of which wallet. With cards a dispute process answers that by default. Here the answer is a named person and a written procedure, and the first request will arrive before you have appointed either.
• You plan to announce it before the legal question is settled. The offer page is itself part of what the law regulates, so "launch quietly and sort the paperwork later" gets the order backwards.

FAQ

Do I have to accept anything besides USDT?

No, and starting narrow is reasonable. More assets — BTC, ETH, TRX, BNB, SOL, TON, XRP among others — cost you nothing in accounting complexity if incoming funds convert to USDT on arrival, so the question is whether customers ask. Adding assets is cheap; adding networks is what support pays for, since each one is another route an agent has to recognise.

Can I test it before customers see it?

Yes, and plan for it: the widget works only on domains authorised in the project, so add your staging host alongside the production billing domain when you set the project up.

A payment is held for review. What do I tell the customer?

That it is in review rather than rejected, and when you will come back to him. In CryptumPay, funds flagged as suspicious are held before they reach your balance, so a hold is a state, not an outcome. If the service is already running, the continuity rule applies: a hold on a renewal is not grounds to suspend a paying customer mid-cycle.

Which figure do I book against the invoice?

In CryptumPay's API, the income field from the finished webhook — the amount credited after all fees, the only figure that reflects what you actually received. Store it with the transaction hash and your invoice reference in one record; that triple makes month-end reconciliation a query instead of an investigation.

Do I still have to care where the money came from?

Yes. There is no acquiring bank in the chain doing it for you, so the practical part stays on your side: who you refund, which addresses you send to, what you keep on record. The requirements themselves depend on your jurisdiction, a question for the same lawyer as article 14 — but the address rule in your refund clause is the cheapest control you can put in place while you wait for that answer.