How to accept crypto payments in WHMCS for hosting and VPS billing

To accept crypto payments in WHMCS you install a gateway module, paste in an API key, point it at a webhook URL on your server, and mark the invoice paid when a signed webhook arrives. That part is mechanical. The part worth reading is everything hosting-specific around it: your buyers are unusually crypto-native, your billing repeats every cycle, and chargebacks are a real business risk. Crypto changes all three — two in your favour, and one that costs you a manual process you should decide on before switching it on.

Hosting is not a normal shop

Most "accept crypto" advice is written for someone selling t-shirts, where crypto is a nice-to-have maybe 1% of buyers touch. Hosting is different. The people buying a VPS, a dedicated box or a domain are developers, sysadmins, offshore-minded businesses and buyers in countries where a card payment to a foreign hosting company gets declined by the issuer for no stated reason. For a meaningful slice of them, crypto is not a convenience — it's the difference between a sale and no sale.

You can see it in the support queue. Nobody emails a clothing store asking whether they take USDT; hosting companies get that email constantly, and every sender already decided to buy.

The honest part: there is no stored card

Here is where you need precision instead of marketing. Hosting is recurring billing: WHMCS exists to raise an invoice every month or year and collect on it without the customer thinking about it. A card gateway does that by storing a token and pulling funds on the due date.

A non-custodial crypto gateway cannot. There is no token to store and no standing authorisation to pull from someone's wallet — funds move only when the wallet holder signs a transaction. So "recurring crypto billing" is honestly described as an invoice plus a payment request the customer pays each cycle, not a silent auto-charge. The full model, including the smart-contract approaches and why they don't fit most billing, is in crypto subscriptions and recurring payments explained.

Making renewals painless anyway

The gap between "auto-charge" and "customer pays each cycle" is a UX problem, and it's solvable. What works:

• Invoice well ahead of the due date. WHMCS already generates invoices in advance. Give crypto payers a longer runway than a card customer — someone moving funds off an exchange needs days, not minutes.
• Use a generous invoice window. A crypto invoice is quoted at a rate that holds for a short window, so generate the payment request when the customer is ready to pay, not weeks early.
• Let people pay ahead. Crypto-native customers will happily prepay a year to stop thinking about it, and every prepaid year is a renewal you never chase.
• Reminders are your auto-charge. Overdue notices, a clear pay link, a visible suspension date — the same muscle you use for bank transfer customers.
• Don't suspend on the first missed day. A confirmation delay or a pending exchange withdrawal is not a deadbeat. Build in a grace period.

Chargebacks: hosting's most expensive problem

Hosting is a chargeback magnet and everyone in the industry knows why. A stolen card buys a server, the server is used for whatever it was bought for — spam, scanning, mining, worse — and then the real cardholder reverses the charge. You lose the money, the resources it burned and the fee, and your chargeback ratio creeps toward the threshold where your merchant account gets a conversation you don't want. The fraud isn't incidental to the product; the product is the fraud tool.

Crypto payments are final. Once a transaction has the confirmations you require there is no issuer, no dispute window and no reversal. Nobody charges back a server after using it for three weeks. For a hosting business that is often the single strongest argument in the column, and the economics are covered in accepting payments without a merchant account or chargebacks.

Fraud doesn't vanish, to be clear. Abusive customers still sign up — they just pay with their own money and can't claw it back. Your abuse handling stays where it was.

The trade-off, stated plainly

Finality cuts both ways. Because nobody can reverse a payment to you, you are the only one who can send money back — as an outbound payment, by hand. There is no "refund" button that unwinds a settled transaction. That means two decisions before launch:

1. Pro-rated cancellations. Decide the policy first and write it into your ToS. Many hosts issue account credit instead of an on-chain refund, which is cleaner and keeps the customer. If you do refund on-chain, the network fee comes off the top and the price will have moved — refund the fiat value you agreed or the exact amount received, but say which in writing.
2. Who signs the outgoing payment. In a non-custodial setup, receive addresses derive from public key material only and private keys never touch the server, so refunds and payouts are signed offline by a human. That's a feature — a compromised billing box cannot drain your takings — but refunds are a deliberate act, not an API call. Your internal balance is where you see what you've collected and move it out; pricing is 0% to accept, with fees only when money leaves: 1.5% on payouts, transfers and withdrawals on the Free plan, plus the coin’s network fee on a payout or a withdrawal (minimum withdrawal $50).

Provisioning: trust the webhook, never the redirect

This is the detail that separates a working setup from an exploitable one. When a customer finishes paying, their browser is redirected back to your WHMCS install. That redirect is not proof of payment. It's just a URL, and anyone can hit your return URL.

Provision on the signed webhook and nothing else. Payora signs every callback with HMAC-SHA256 over the payload, with a timestamp window and an idempotency key. Your endpoint verifies the signature, checks the timestamp is fresh, checks it hasn't already processed that key, and only then marks the invoice paid and lets automation fire. The docs cover the signature scheme and the one-file PHP SDK that handles it.

Idempotency matters more here than in a shop: a webhook processed twice on a hosting order doesn't just double-credit an invoice, it can trigger a second provisioning run. Key on the idempotency key, not on "have I seen this order id".

Which networks to enable for instant provisioning

If your product provisions instantly, confirmation time is the checkout experience. A customer clicking "order VPS" at 2am expects a root password in minutes, and Bitcoin's block time is a bad fit — waiting on confirmations for a $6 VPS is a support ticket in the making. Prefer fast, cheap networks by default and let Bitcoin be an option rather than the headline:

Stablecoins deserve a special mention here: USDT and USDC price your $6/month plan at $6, with no argument about which rate applied. How many confirmations each network actually needs, and why the answer depends on order value, is covered in how many confirmations make a crypto payment safe.

Set up the Payora module to accept crypto payments in WHMCS

The WHMCS gateway module is one of the free drop-in integrations we publish on modules, alongside 21 others. It's the fastest way to accept crypto payments in WHMCS without writing code. At a high level:

• Install the gateway module into your WHMCS install and activate it among your payment gateways.
• Create a free account at register and paste the API key into the module's settings.
• Set the webhook URL to the module's callback endpoint so signed notifications reach it.
• Enable the coins and networks you want to offer, and configure your receiving key material.
• Place one small real order on a cheap network and confirm the invoice goes to Paid off the webhook.

From there the flow is the standard one described on accept payments: the invoice carries your order id and amount, the customer picks a coin on the hosted checkout, Payora watches the chain to that coin's finality, and your server gets the signed callback. If you'd rather skip the module — plenty of hosts run a heavily customised WHMCS — the plain-JSON REST API does the same job.

Start with one fast network and one stablecoin, watch what customers actually pick, and add from there. Create an account, grab an API key, and put a real $5 order through your own checkout before you announce it.