Accept crypto payments as a web hosting provider: sixty seconds to deliver, four months to be billed back

Why a web hosting provider delivers in a minute and stays exposed for months

Every subscription business has some gap between delivering the product and being certain of the money. In hosting the gap is so extreme it stops being a finance problem and becomes an architectural one.

Consider what actually happens at signup. A customer somewhere on earth fills in an order form at 03:40 local time, pays, and the automation does the rest: the container or VM is created, the control-panel account is provisioned, the licence is allocated, DNS is written, an IPv4 address is assigned from a block you lease, a welcome email goes out with root credentials. Elapsed time from payment to a running server: under a minute, and your entire competitive positioning depends on that number staying under a minute.

Now consider the money. If the customer paid by card, that payment remains reversible for a long time. Card scheme dispute windows — documented in network materials such as the Visa Core Rules — give a cardholder months to raise a claim. So the provider's delivery window is sixty seconds and its exposure window is a third of a year.

That asymmetry alone would be manageable if the delivered thing could be taken back. It cannot. You can terminate the account, and you should, but the resources are already consumed: the CPU and RAM that were reserved, the terabytes of transit you paid an upstream for, the IPv4 address that was tied up and is now in a reputation grey zone, the third-party control-panel or operating-system licence that billed you per instance for the month. Reclaiming a server is not reclaiming its cost.

And this is precisely why hosting is such a well-known target. An instantly-delivered, remotely-controlled, digitally-consumed product bought with someone else's card is not merely a stolen sale — it is infrastructure. The same account gets used to send spam, run phishing pages, proxy traffic, scan the internet or mine something, which means the provider absorbs a second cost after the chargeback: IP ranges that end up on blocklists, upstream complaints, and deliverability damage that lands on legitimate customers who did nothing wrong.

Then there is the opposite problem, and it is the one hosts complain about most: the customers who genuinely want to pay and structurally cannot.

Hosting is one of the very few businesses whose addressable market is literally everyone with an internet connection. The ITU's ICT statistics track a connected population in the billions, spread across every economy on the planet. The card networks do not have that footprint. The World Bank's Global Findex has documented for years that well over a billion adults hold no financial account at all, and account ownership is only the first hurdle — a great many people with a bank account still have no card that works for an international, recurring, card-not-present charge to a foreign merchant.

So a developer in Lagos, Karachi, Caracas, Hanoi or Buenos Aires can write the application, register the domain through a local reseller, and then hit a wall at the one step that should be trivial. Hosting providers have been asked to take crypto for over a decade, earlier and more insistently than almost any other vertical, and the reason has never been ideology. It is that for a meaningful slice of the world's builders, it is the only rail that reaches.

Finally, look at the renewal, which is where the recurring model quietly leaks. A hosting plan is not a nice-to-have subscription that a customer notices lapsing. It is the thing their business runs on. But the card behind it expires, gets reissued after a breach at some unrelated retailer, or trips a 3-D Secure step-up that sends a one-time code to a phone number the customer changed two countries ago. The charge fails, the dunning emails go to an address on the domain that is about to be suspended, and the first anyone hears about it is a support ticket that begins "my site is down".

What the wrong rail costs a hosting company, month after month

The chargeback that arrives after the resources are spent. A fraudulent signup on a stolen card consumes a month of transit, a licence, an IP and a support seat, and then reverses. You lose the sale, you lose the delivered cost, and you pay a dispute fee on top. Multiply by whatever your fraud rate is on instant provisioning and you have the single largest uncontrolled line in a small host's P&L.

The ratio that changes your pricing tier. Card acquirers do not just charge you for each dispute. They watch the ratio, and once a merchant drifts toward the network's monitoring thresholds the response is a rate increase, a higher reserve, tighter ceilings, or a request to find another acquirer. It is the same dynamic every online merchant fighting chargebacks knows, except your product can be weaponised by the person disputing it.

The high-risk classification you did not ask for. Underwriting reads hosting as: digital goods, instant delivery, no shipping evidence to defend a dispute with, global card-not-present customers, recurring billing, anonymous-ish accounts, a reseller layer you do not directly control, and unknown third-party content sitting on your servers. That profile produces higher rates, delayed settlement and rolling reserves. And a rolling reserve on an infrastructure business is particularly cruel, because your own costs — colocation or cloud spend, upstream transit commits, hardware leases, IPv4 leases, control-panel and OS licences, on-call staff — fall due every single month regardless of what your processor is holding back.

The card-testing wave. Because a hosting order form is a cheap, fast, automated purchase, it makes an attractive validator for stolen card numbers. A burst of small authorisations costs you gateway fees, pollutes your fraud metrics, and occasionally gets your merchant account flagged for something you were the victim of rather than the cause.

Involuntary churn that reads as a service failure. When the renewal dies on a reissued card, the customer does not experience "a billing problem". They experience an outage. Then a suspension. Then a retention window ticking toward deletion. You will win most of those back, but you will win them back through a support queue, an apology, and often a credit — and some of them will simply move to a competitor who happened to have a working card on file. This is the exact failure mode described in crypto subscriptions without chargebacks, and hosting is where it hurts most because the product is load-bearing.

The refund clock on a money-back guarantee. Most hosts advertise one, typically thirty days. On a card rail, an unhappy customer has two ways to invoke it: your policy, or their issuer. Plenty choose the issuer, which turns a routine refund you would have granted anyway into a dispute on your record.

Cross-border fees on a business with no border. Interchange plus cross-border assessment plus FX margin, applied to a global customer base with a small average ticket, is a proportional tax on exactly the shape of business hosting is. On a $6 shared plan the percentage is brutal; on a $400 dedicated server it is a real number.

The affiliate and reseller payout run. Hosting has one of the largest affiliate ecosystems on the internet, and a reseller channel that spans dozens of countries. Paying two hundred affiliates by individual international transfer means two hundred fees, two hundred cut-off times, some payments arriving short after correspondent deductions, and a monthly admin block that grows linearly with the channel you spent years building.

Payee-detail fraud on that same run. Worth naming because it is expensive and rail-agnostic: the FBI's Internet Crime Complaint Center has documented for years that business email compromise — impersonating a payee to redirect a legitimate payment — is among the costliest categories of cyber-enabled crime. An affiliate who emails new payout details before the monthly batch is the classic vector. Out-of-band verification of payee details is the control that matters most, on any rail.

Why cards, PayPal and bank transfers all fail somewhere in hosting

None of these rails is poorly built. Each was designed around assumptions that hosting violates.

Cards assume a physical good and a protectable consumer. The entire dispute framework exists to protect a cardholder who paid and did not receive. Its evidence model is shipping — tracking numbers, delivery confirmation, signatures. A hosting provider has none of that. You have logs showing a login from an IP address, which is exactly what a fraudster's logs would also show. So you are structurally the weaker party in every dispute, and you are the weaker party while also being the one who already paid for the transit.

Cards assume a stored credential that stays valid. The recurring model works beautifully for a customer with a stable card in a stable country. Hosting customers are disproportionately developers, freelancers, agencies and startups — mobile, cross-border, and using whatever card they had when they signed up three years ago. Every reissue is an unannounced cancellation of a subscription neither party wanted to cancel.

PayPal and similar wallets add custody on top. They solve some of the reach problem and none of the reversibility problem, and they introduce a new one: a balance that belongs to you but sits in an account somebody else can limit, review or hold. For a business that must pay an upstream commit on the first of the month, "your money exists but is under review" is not a technicality.

Bank transfers work and nobody uses them. They are final, cheap at scale and universally understood — and they take one to five business days, only in banking hours, with a reference the customer will mistype, which is incompatible with a product whose selling point is that it exists sixty seconds after you decide to buy it. Wire is what your enterprise colocation client uses. It is not what an order form uses.

And under all of them sits custody. Whoever holds your money between the customer's payment and your account defines when you get it and under what conditions they will stop. Acquirer settlement cycles, rolling reserves and account reviews are all versions of the same structural fact. A hosting business with monthly infrastructure commitments is precisely the kind of business for which "held until Thursday, or until we finish looking at you" is a real operational risk.

How Payzum lets a web hosting provider accept crypto payments and pay the channel

Payzum is a non-custodial, crypto-only payment processor. The first word is the one that matters to a business with an upstream invoice due on the first: funds go directly to wallets you control. There is no Payzum balance, no settlement batch waiting on a cut-off, no reserve held against a merchant category code. The settlement is the payment. On-chain confirmation takes seconds — roughly two seconds on Base and Polygon, well under a second on Solana — and once confirmed it is final. Nobody reverses it four months later because a card number turned out to be stolen. The mechanics are covered in more depth in our guide to the non-custodial crypto payment processor model.

Optional auto-conversion to USDC or USDT means the amount you priced is the amount you keep. Hosting is priced in dollars almost everywhere on earth, including by providers who bank in a currency that is not the dollar, so settling in a dollar-denominated stablecoin removes a mismatch rather than creating one.

The instruments, mapped to how a hosting business actually bills

• Recurring subscriptions — flagship number one. Monthly, quarterly, annual and biennial plans billed on a rail with no stored card to expire, no reissue to break the chain and no 3-D Secure step-up to a phone the customer no longer owns. The renewal that used to fail silently and take a site offline stops being an operational category.
• REST API and signed webhooks — flagship number two. In hosting the webhook is the product. A signed webhook fires the moment a payment confirms, and your automation does what it already does: create the account, allocate the licence, write the DNS, send the credentials. Signed, so your provisioning endpoint can verify the call actually came from the processor. There is an integration playground to test it against before it touches live capacity. See the REST API crypto payment gateway walkthrough for the shape of it.
• Hosted checkout and the drop-in plugin. Redirect, modal or inline checkout behind your existing order form, or a drop-in on the e-commerce platform you already run. Your funnel, your branding, your upsells — a new payment method on the last step rather than a new billing system.
• Invoices with an expiry and overpayment detection. For annual plans, dedicated servers with a setup fee, IPv4 blocks, colocation and enterprise contracts. The invoice carries your reference — account ID, server hostname, contract number — and expires on a date you set, so quotes do not stay live at last quarter's price. Overpayment detection catches the customer who rounds up or pays two invoices in one go.
• Payment links and buttons, no code. For everything that is not a plan: a migration service, an SSL certificate, a control-panel licence, an extra IP, a DDoS mitigation add-on, an over-quota bandwidth bill, a one-off sysadmin hour. Send a link from a ticket, watch it fund, do the work.
• CSV mass payouts. One file settles the channel: affiliates, resellers, freelance sysadmins and remote support staff, bug-bounty rewards, referral partners. Stablecoin payouts run on Polygon, Arbitrum, Optimism, Base, BNB Chain and Avalanche; CSV payouts also cover BTC, LTC and DOGE. It is the same batch mechanism described in paying affiliates in crypto.
• POS with a QR per sale and PIN cashiers. Not every host is faceless. Regional ISPs and hosting companies across Latin America, Africa and South Asia run walk-in offices where small-business customers pay their monthly plan at a counter. Any phone becomes a terminal, each position gets its own PIN, and analytics are per cashier and per terminal.
• x402 for the metered side of your platform. If you also sell something priced per call — object storage, an image or transcoding endpoint, GPU inference, a serverless function — Payzum sits as middleware in front of your existing API. You configure your endpoint, your API key and a price in a dashboard; Payzum publishes an x402 URL, returns the 402, settles the payment through an external facilitator, and proxies the paid call to your real endpoint with your key. No protocol to implement and no code to write, and AI agents can pay per request in USDC on Base. The background is in x402 pay per API call.

The provisioning path, in detail

This is the part worth being concrete about, because it is where a hosting integration either works or does not.

Today, with cards: the customer submits the order form, the gateway authorises, your billing system marks the invoice paid, provisioning fires, the server is live. Two to three days later the money settles into an acquirer account. Somewhere between now and four months from now, a fraction of those payments come back.

With Payzum: the customer picks the crypto option at checkout and pays from their own wallet. The transaction confirms on-chain in seconds. Payzum fires a signed webhook to your endpoint. Your billing system verifies the signature, marks the invoice paid, and provisioning fires exactly as it does now. The server is live on the same timeline your customers already expect. The difference is on the other side: the funds are already in a wallet you control, and the confirmation is final. There is no settlement delay, no reserve, and no third-party decision pending for the next hundred and twenty days.

For most providers this is a change to one branch of an existing billing flow, not a migration. Your control panel, your automation, your dunning logic, your customer database and your price list all stay where they are.

Honest scope: finality removes chargebacks and it also removes your fraud signal

Read this section twice, because it is the part most content about crypto payments for hosting simply omits, and getting it wrong will cost you more than chargebacks did.

When you take a card, the network hands you a set of fraud signals for free: address verification, the issuing BIN and country, velocity data across the network, and above all the issuer's own decline. A meaningful share of your fraudulent signups today are stopped before you ever see them, by a bank you are not paying for the service.

A wallet payment carries none of that. It is final, which is exactly what you wanted, and it is largely unauthenticated as to identity, which is the trade you are making. The practical consequence for a hosting provider is direct: your own signup screening, acceptable-use enforcement and abuse response have to be stronger, not weaker. Identity checks proportional to the plan, sanctions and denied-party screening on your customers, rate limits on provisioning, and a functioning abuse desk are not optional extras on this rail — they are the thing that replaces the issuer's decline.

Payzum's own product includes KYC, 2FA, encrypted secrets, signed webhooks and a full audit log. Those secure and document your merchant account and the payment record. They are not, and are not offered as, a screening programme for your customers or a substitute for your abuse handling. That work stays with you, as it does on every rail.

Stated fairly, the trade is a good one for most hosts: you exchange an unbounded, third-party-adjudicated liability for a bounded, in-house control problem you already have staff for. But it is a trade, not a free win, and anyone who tells you otherwise has not run an abuse desk.

What else this rail does not do

• Not a domain registrar or reseller. ICANN's requirements on accredited registrars — registration data accuracy, transfer policy, dispute procedures — sit with your registrar relationship and are entirely unchanged by how you collect money.
• Not an intermediary-liability or takedown regime. Notice-and-takedown, copyright complaints, law-enforcement requests, data retention and lawful-process obligations, and the content rules that apply to a host in each country you serve all remain yours.
• Not a tax engine. Selling hosting across borders triggers place-of-supply and digital-services VAT or sales-tax obligations in a growing list of jurisdictions. Those apply to the sale, not to the rail, and they are unchanged.
• Not escrow. Finality cuts both ways. A refund under your money-back guarantee is instant, because you already hold the money — but nobody arbitrates a dispute for you. Your refund policy has to be published, clear, and actually honoured, and you have to keep enough liquidity to honour it.
• Not a payroll bureau or employer of record. Paying remote sysadmins and support staff in a batch is a payment; classification, contracts, withholding and statutory payroll obligations stay yours.
• No fiat settlement. Payzum is crypto-only. It settles crypto into your wallet, with optional auto-conversion to USDC or USDT. Converting to your local currency, if you need to, is a separate step with your own provider.

Volatility is a setting, not a risk

The reflexive objection is price movement, and for a business with monthly infrastructure commitments it deserves a straight answer. Auto-conversion to USDC or USDT means you can accept a payment and hold a dollar-denominated stablecoin, issued against reserves the issuer reports on — Circle publishes reserve composition and attestations for USDC. If a customer pays in something else, the conversion happens for you. You are not taking a market position; you are choosing a settlement currency, and for a hosting provider that currency was already the dollar, because that is what your price list, your transit commit and your hardware are quoted in.

How it works, step by step

1. Open the account and connect your wallets. You supply the addresses you want to be paid into — your own wallets, on the networks you choose. Payzum never holds the funds. Turn on auto-conversion to USDC or USDT if you want everything to land dollar-denominated.
2. Add the payment method to your order form. Hosted checkout as a redirect, modal or inline step, or the drop-in plugin on the platform you already use. This is a new option on the last screen of the funnel you already have.
3. Wire the provisioning webhook. Point a signed webhook at the endpoint your billing system already exposes, verify the signature, and let a confirmed payment mark the invoice paid and trigger provisioning. Test it in the integration playground before it touches live capacity.
4. Turn on subscriptions for renewals. Move monthly and annual plans onto recurring billing that has no stored card to expire. Start with the cohort whose renewals fail most — long-tenured customers and customers abroad.
5. Set up invoices and links for everything that is not a plan. An invoice template with an expiry and your account or hostname reference for dedicated servers, colocation and enterprise contracts; a few link presets for migrations, licences, extra IPs and over-quota bandwidth, so support can collect from inside a ticket.
6. Run the channel payout in one batch. Build the CSV for affiliates, resellers, freelance sysadmins and bug-bounty rewards, and settle the whole list in a single run on the networks that suit each payee.
7. If you sell anything metered, publish it for agents. Configure the endpoint and price in the dashboard, and your storage, transcoding or inference API starts accepting per-call USDC payments on Base the same day — without implementing the protocol yourself.

Use cases at a web hosting provider

Concrete situations, all of them ordinary weeks in this business:

• The 03:40 VPS signup from a market cards do not reach. A developer in a country where international card-not-present transactions routinely fail pays from a wallet, the webhook fires, and the instance is live before they have finished reading the welcome email. No manual review, no "please contact our billing department", no lost customer.
• The annual renewal that used to die on a reissued card. A four-year customer on a $180 annual plan. Previously the renewal failed on a card replaced after an unrelated breach, the account suspended, and the first contact was an angry ticket. Now it is a recurring subscription with nothing to expire.
• The reseller in another country buying wholesale capacity. A white-label partner paying monthly for a block of accounts. A recurring subscription in a dollar stablecoin, settling in seconds, instead of a cross-border transfer that arrives late, short, and with a reference nobody can match.
• The dedicated server with a setup fee. An invoice with an expiry set to the date you will stop holding the hardware, carrying the hostname as the reference, with overpayment detection on. It funds, and the build ticket goes to the data centre the same afternoon.
• The add-on collected from inside a support ticket. A customer needs an extra IP, a cPanel licence bump, DDoS mitigation for a campaign week, or an emergency migration on a Sunday. Support sends a payment link in the ticket; it funds in minutes; the work starts.
• The monthly affiliate and reseller batch. Two hundred and forty payees across thirty countries, each owed an exact amount. One CSV, one run, each paid in full on the network that suits them — instead of two hundred and forty transfers, most of them international and several arriving short.
• The regional ISP counter. A provider with a walk-in office collecting monthly plans from small businesses. A QR per sale on a phone, a PIN per position, and takings by cashier and by hour that are a report rather than an argument at close.
• The metered endpoint served to agents. The same platform sells object storage and a GPU inference endpoint. Configured behind Payzum's x402 middleware, both start accepting per-call USDC payments on Base from autonomous agents — a customer segment that has no card, no signup form and no patience — while the underlying API stays exactly as it is.

Payzum vs card acquirers and wallets for a hosting provider

Common objections, answered

"Won't accepting crypto attract exactly the abusers we are trying to keep off our network?"

This is the right question and it deserves a real answer rather than a reassurance. Removing chargebacks removes the fraudster's incentive to use a stolen instrument — there is nothing to reverse and nothing to monetise by disputing. What it does not do is tell you who the customer is. So the honest position is that your abuse controls have to do more work: identity checks proportional to plan size, provisioning rate limits, sanctions and denied-party screening, and an abuse desk that actually answers. Most hosts already run all of that, because card fraud never stopped abuse either — it just meant a bank told you afterwards. The change is that you find out at signup instead of at chargeback.

"Our billing runs on WHMCS / Blesta / something we wrote ourselves. Is this a rewrite?"

No. The integration surface is a checkout your customer is redirected to (or a modal, or an inline element, or the drop-in plugin) and a signed webhook your billing system consumes. Your provisioning automation does not change at all — it already fires on "invoice paid", and this is another thing that produces that event. Most providers add it as one payment option behind the existing order form and leave every other rail exactly where it is. There is a REST API and an integration playground for the parts you do want to wire up more deeply.

"Will our customers actually pay this way?"

Hosting is one of the few verticals where you do not have to guess, because the demand arrived before the supply. Providers have been fielding "do you take crypto?" from customers for over a decade, and the strongest demand comes from exactly the segments a card rail serves worst: developers in markets with thin card coverage or capital controls, agencies billing across borders, privacy-conscious buyers, and long-tenured customers tired of re-entering a card every time one gets reissued. Start by offering it beside your existing methods and look at who takes it. You are not migrating anyone.

"What happens to our thirty-day money-back guarantee?"

It works, and it works faster — you already hold the money, so a refund is a payment you send rather than a reversal you wait for. What changes is that there is no issuer to appeal to, in either direction. That makes the written policy the whole agreement: publish it clearly, apply it consistently, and keep the liquidity to honour it. In practice most hosts find refunds get easier, because the argument about whether the money comes back stops involving a third party who decides on evidence neither of you controls.

"We are a five-person host. Is this an infrastructure project?"

The checkout and the webhook are an afternoon for whoever maintains your billing system, and links, invoices and subscriptions are no-code from a dashboard. The realistic first step is narrower than a project: add the payment method to one product line — VPS plans, say — watch a month of signups and renewals, and compare the chargeback and failed-renewal numbers against the month before.