Hosting and VPN
Crypto payments for WHMCS hosting and VPN invoices
Your clients pay WHMCS invoices with BTC, ETH or USDT through PayKrypt hosted checkout. Signed webhooks apply the payment back to the invoice automatically, so provisioning follows the WHMCS automation you already run.
The problem this solves
Most small hosting and VPN operators can already accept crypto: the invoice says send USDT to this address, the client sends it, someone checks the wallet, and someone marks the invoice paid.
That works for the first few payments and stops working shortly after. The failure is not the payment, it is the reconciliation around it.
- A client pays without a reference, and matching the transaction to an invoice becomes manual work.
- A client pays on the wrong chain, or short of the amount after network fees, and there is no defined state for what just happened.
- The invoice stays unpaid in WHMCS until a human updates it, so provisioning waits on that human.
- Your client bought hosting because they wanted it now, and is opening a ticket asking why the server is not up.
How the module works
The module creates or reuses one PayKrypt payment intent per WHMCS invoice and redirects the client to hosted checkout. When the payment settles, PayKrypt sends a signed webhook to your WHMCS callback URL.
WHMCS then retrieves the payment intent and validates its ID, amount, currency and final status before applying payment. The browser return from checkout is never treated as proof of payment, which is the failure mode that lets an invoice be marked paid by anyone who can load a URL.
If webhook delivery fails, the standard WHMCS cron polls pending intents and applies the same validation and the same duplicate-payment protection. Webhooks are the primary path; polling is the safety net, not the design.
What happens on underpayment and overpayment
Every payment state maps to a defined WHMCS action, so there is no case where the module has to guess. This is the whole mapping:
- Underpayment never marks the invoice paid. It logs the transaction and shows the client a notice telling them to contact support before sending another payment.
- Overpayment applies the invoice payment and logs the overpaid status, so you can settle the difference under your own policy.
- Because the invoice only moves on a fully paid intent, WHMCS provisioning stays tied to a payment that actually cleared.
PayKrypt status -> WHMCS action
------------------------------------------------------------
confirmed (fully paid) -> Add invoice payment
overpaid (fully paid) -> Add invoice payment, log overpaid
underpaid -> Log transaction, invoice stays unpaid
awaiting_payment / detected /
confirming / partial -> Log pending status
expired / canceled / failed -> Log terminal status, invoice stays unpaidBuilt-in mode safety
The module refuses to produce a checkout when your PayKrypt API key and the WHMCS Test Mode switch disagree. That guard runs in both directions, and both of them are real ways to lose money.
- A test key with Test Mode off means the install believes it is billing for real while invoices settle for free.
- A live key with Test Mode on means the install believes it is testing while a real client pays real cryptocurrency.
Key Test Mode Result
---------------------------------------------------------
pk_test_ off Refused: invoices would settle for free
pk_ live on Refused: a real client would pay for real
pk_test_ on Sandbox. Simulated payments, no money moves
pk_ live off Live. Real paymentsTest it before a client ever sees it
Paste a pk_test_ key into the module, turn Test Mode on, and the whole flow runs against your sandbox merchant. Invoices settle from simulated payments, no money moves, and the module, the callback and the reconciliation sweep behave exactly as they do in production.
Do not leave a test key on a production install. The payment simulation endpoint is unauthenticated by design, because the payment intent ID is the credential exactly as it is for hosted checkout, and your client already has that ID from the checkout URL. The guard above is what stops that state existing by accident.
Requirements
The module targets WHMCS 7.x and 8.x. PHP compatibility depends on your exact WHMCS release: 7.x runs PHP 5.6 to 7.3 depending on the minor version, 8.x runs PHP 7.2 and newer, and WHMCS does not support PHP 8.0 on any release.
You also need the PHP cURL extension with TLS 1.2, and the standard WHMCS system cron running at least every five minutes for the polling fallback.
WHMCS 7.x and 8.x are legacy releases. The module supports them for existing installations, but upgrading WHMCS is still the right move.
What this does not change
PayKrypt is added as another WHMCS payment method. You keep your card processor and your other payment methods, and offer crypto to the clients who prefer it.
On-chain payments are final, so card-style chargebacks do not apply. Customer disputes still do, and they remain yours to handle under your own refund policy. Crypto changes the rail, not your support obligations.
FAQ
Will invoices be marked paid automatically?
Yes. Once PayKrypt confirms the payment and the signed webhook is processed, the module applies payment back to the WHMCS invoice. The browser return from hosted checkout is never treated as proof of payment.
What happens if the webhook fails?
The WHMCS cron polls pending payment intents as a fallback and applies the same validation and duplicate-payment protection as the webhook path. You need the standard WHMCS system cron running at least every five minutes.
What if the client underpays?
The invoice stays unpaid. The module logs the transaction and shows the client a notice asking them to contact support before submitting another payment, so a shortfall never silently provisions a service.
Do you support WHMCS 8 and my PHP version?
The module supports WHMCS 7.x and 8.x on PHP 5.6 through 8.3. The usable range is the intersection with your exact WHMCS release: 7.x runs PHP 5.6 to 7.3 and 8.x runs PHP 7.2 and newer, and WHMCS does not support PHP 8.0 on any release.
Do you support TRC-20 USDT?
Hosted checkout supports USDT on the chains enabled for your merchant account, including TRON. Check the current asset and chain list in the developer documentation before go-live rather than assuming a specific pair.
Do I have to replace my existing card processor?
No. PayKrypt is added as an additional WHMCS payment method alongside whatever you already use.
Can I try it without risking a live invoice?
Yes. Configure the module with a test key and Test Mode on, and the full flow runs against your sandbox merchant with simulated payments. You can also drive the underlying payment states from the public live demo without installing anything.
Next steps
Start with the public Quickstart, then contact PayKrypt if you need help evaluating your integration path.