Hosting billing is not ordinary e-commerce
A shop takes a payment once. A hosting company takes the same payment every month, from customers in countries it has never visited, in a business category that half of the payment industry files under elevated risk. Those three facts turn payments from a checkout feature into an operational dependency — and they are why hosting, VPN, domain and managed-service businesses outgrow a single provider earlier than almost anyone else.
Renewals fail quietly
A renewal is a merchant-initiated charge against a stored agreement, with nobody at the keyboard. Plenty of gateways take the first payment perfectly and cannot do the second one at all, so the invoice sits unpaid, dunning runs, and a happy customer is suspended for a reason neither of you chose. The diagnosis is in why WHMCS recurring payments fail.
Your customers are everywhere
Infrastructure sells across borders by default. A customer in Lagos, São Paulo or Jakarta who cannot pay with the method they actually use does not switch methods — they close the tab. One provider is strong in some of those markets and absent in the rest, which is the whole content of why cards alone lose sales abroad.
You are a risk category
Hosting, VPN and domain resale attract holds, reserves and account reviews that a clothing store never sees. It is not a reflection on your business; it is how the category is underwritten. With one provider, a review stops every payment you take until it clears. With several already connected, it stops one of them.
Fraud arrives at signup
Cheap plans and instant provisioning make a hosting signup form an ideal place to validate stolen cards, and the bill for that lands on you as declines, fees and eventually a merchant review. Attempt limits, distinct-card limits and rules that react to repeated rejections are the controls that matter — see card testing on signup forms.
One sale, then eleven silent ones
A retail checkout is a conversation. The customer is present, they are paying attention, and if the card fails they see the error and try another one. Almost all of the payment tooling written in the last decade assumes that person is there.
Infrastructure billing works the other way around. The customer is present exactly once — at signup — and absent for every charge after it. A monthly plan sold in January is one attended payment and eleven unattended ones, and the eleven are where the revenue actually lives. They are also the ones nobody is watching when they fail.
That inversion changes what a payment failure costs you. When a first payment fails, you have lost a sale you never had: unpleasant, but the customer walked in and walked out and you are no worse off than before they arrived. When a renewal fails, you have already delivered a month of service, you are still carrying the cost of the server it ran on, and the person whose card quietly expired has no idea anything is wrong. You do not lose a prospect. You lose a paying customer, after paying to serve them.
The second-order effect is worse than the first. Suspension is usually automated, so the customer discovers the problem when their site goes down — not when their card failed. The support ticket that follows is not about billing. It is an outage complaint from someone who believes they paid you, and by the time it is resolved you have spent support time, lost their trust, and often refunded something to keep them.
Involuntary churn hides inside your churn rate
Most hosting businesses track churn as a single figure. Inside it are two completely different events that happen to produce the same row in a report.
Voluntary churn is a customer deciding to leave. It is a product problem, a pricing problem or a competitor problem, and the fix is somewhere in your business.
Involuntary churn is a customer who still wants the service and whose payment did not go through. An expired card, a bank that declined a merchant-initiated charge it did not recognise, a provider outage during the renewal run, a rejected currency. The customer made no decision at all. The fix is entirely in your payment layer.
These two get averaged together and reported as one number, which is why the payment layer rarely gets blamed for a churn problem it is causing. If you cannot split them, the first useful thing you can do is start: tag every cancellation with whether a human requested it or a charge failed. The proportion is usually higher than expected, and unlike voluntary churn it responds to purely technical work.
It also compounds in a way voluntary churn does not. A customer who chose to leave is gone once. A renewal path that fails for a whole class of customers — one country, one card type, one provider having a bad week — fails again next month, and the month after, quietly, until somebody looks.
If you bill on WHMCS
The free PaymentHood module connects WHMCS to 30+ providers at once, with automatic renewals on the providers that support agreements. Install it once and add providers afterwards without touching WHMCS again.
Adding one specific provider? The WHMCS and Razorpay integration is written up step by step, and every other provider follows the same shape.
If you bill on something else
WHMCS is the most common answer in this industry and far from the only one.
WordPress & WooCommerce
Common for shared hosting and small managed-service shops selling plans as products. Free plugin, same provider list.
WooCommerce pluginJoomla carts
VirtueMart, Phoca Cart and J2Commerce each have a free plugin. If you are not sure which cart your site runs, the hub identifies it.
Joomla payment pluginsYour own panel
Plenty of hosts bill from a control panel they wrote themselves. One REST API call creates a payment and returns a checkout URL.
API documentation (opens in new tab)Why infrastructure businesses consolidate
Every provider you add the ordinary way is another module, another set of credentials, another webhook format and another thing that breaks on a billing-system upgrade. One integration removes all of it — and every provider account stays contracted in your own name, with funds settling directly to you. PaymentHood is not a processor and never holds your money.
The providers this industry actually asks for
Cards are the floor, not the answer. These are the additions that change conversion for an international customer base.
Crypto
OxaPay, BitPay, Binance Pay and Quidax. Preferred by a real share of hosting and VPN customers, settled without you holding crypto, and not chargeback-able. How crypto acceptance works.
Local methods
iDEAL in the Netherlands, Bizum in Spain, UPI in India, mobile money and USSD across Africa. Each one is the default way to pay somewhere your cards convert badly.
Agreement-capable cards
PayPal, Stripe and Authorize.net among others create a reusable agreement at first payment, which is what lets a renewal charge itself later without the customer present.
The full provider directory shows what is available in each market.
You are underwritten on what your customers can do with the service
Hosting companies are often surprised to be classified as elevated risk, because nothing about the business feels risky from the inside. You sell a real service, you deliver it reliably, and your customers are ordinary businesses. The classification is not a judgement about you. It is about what the product can be used for by somebody else.
Three properties drive it, and infrastructure has all three at once. The service is provisioned instantly, so a fraudulent order is fulfilled before any human review is possible. It is sold internationally, so a large share of transactions are cross-border and card-not-present. And it can be used to host anything — including content or activity that generates complaints, which arrive at the acquirer rather than at you.
A domain or VPN business adds a fourth: the product is frequently bought by people who specifically want to be difficult to identify. That is a legitimate demand and a large market, and it is also exactly the profile a risk model is built to flag.
What that means practically is not that you will be declined — plenty of providers serve this category happily — but that reviews are a normal event rather than a crisis. A rolling reserve, a request for documentation, a temporary hold while a spike is investigated: these happen to healthy hosting businesses, and they usually happen without much warning.
The question worth asking is therefore not "how do I avoid a review" but "what happens to my revenue during one". With a single provider the answer is that everything stops: new signups, renewals, upgrades, all of it, for as long as the review takes. With a second provider already connected and tested, a hold is an inconvenience in a dashboard rather than a business interruption.
A second provider is only useful if it is already live
The instinct when a provider fails is to integrate another one immediately. This is the worst possible moment to do it. Integration work under outage pressure is where credentials get pasted into the wrong environment, webhooks go unverified, and a test transaction is skipped because the queue of unpaid invoices is growing.
A backup provider that exists only as an account you opened is not a backup. It has never taken a live payment, its webhook has never reached your billing system, and nobody has confirmed that a renewal actually charges through it. The first time you find out is the day you need it.
The version that works is unglamorous: a second provider connected, verified with real transactions, and carrying a small share of live traffic continuously so that its failures surface on an ordinary Tuesday instead of during an incident. That is also the only way to know its approval rate on your actual customer mix, which is information you cannot get from a pricing page.
The architecture behind doing that safely — how a retry keeps its identity when it moves between providers, and why that is harder than it looks — is covered in how payment failover is actually built.
Billing in one currency is a decision, not a default
Almost every hosting company starts by pricing in one currency, usually USD or EUR, because the costs are denominated there and one price list is simpler than twelve. That is a reasonable decision and it stays reasonable for a long time. It is worth knowing what it costs, because the cost is invisible.
A cross-border, cross-currency card charge is a different transaction from a domestic one, even when the card number looks identical. It is routed differently, it is scored differently by the issuer, and it carries a conversion the customer sees on their statement but not on your checkout. Issuers decline cross-border charges more readily than domestic ones — particularly unattended, merchant-initiated ones, which is precisely what every renewal is.
So the same customer who paid successfully at signup, while present and able to approve a step-up challenge, can fail silently at renewal three months later, on the same card, for no reason that appears anywhere in your billing system. Nothing changed except that nobody was there to answer the bank.
The practical response is not necessarily to price in every local currency, which brings its own accounting problem. It is to make sure that in your largest non-domestic markets the payment can be taken by a provider that settles locally, and to offer the method those customers already use rather than only the card that has to travel furthest. That is the argument in why cards alone cost you sales abroad, and it applies with extra force to a business whose revenue depends on the tenth charge as much as the first.
Four numbers worth separating
Payment problems in this industry are rarely dramatic. They are a percentage that drifts, spread across enough customers that no single ticket reveals it. Four splits make them visible, and none of them require new tooling — only that the figure stops being reported as one number.
First payment versus renewal. These have different approval rates and different failure modes, and averaging them hides the one that costs you existing revenue. If you measure only one thing from this list, measure this.
Approval rate by country. A global average is a blend of markets where you convert fine and markets where you barely convert at all. The second group is invisible until it is separated, and it is where adding one local method changes the number most.
Decline reason, over time. Not the total, the mix. A rising share of one reason code is a signal well before the aggregate moves — and it distinguishes a problem you can fix from customers who genuinely have no funds. The taxonomy is in why payments fail.
Suspensions caused by payment failure. The bridge between the payment layer and the business. If nobody has counted how many suspensions began as a declined renewal rather than a customer decision, that number is doing damage nobody has attributed yet.
Adding providers without a migration
The reason most hosting companies stay on one provider longer than they should is that the second one has historically cost as much as the first. Another module to install, another set of credentials in the billing system, another webhook format to handle, another thing that breaks when the billing software updates. Multiply that by the number of markets you sell into and the project never reaches the top of anyone's list.
Consolidating that work into one integration changes the sequence. The billing system talks to a single layer; providers are switched on behind it. The first provider is the only integration you perform. The fifth is a toggle.
It also changes who can do it. Adding a local method for a new market stops being an engineering ticket scheduled against a release and becomes an operational decision someone can make the week they need it — which matters in a business where entering a new country is a sales decision, not a product one.
One property is worth being explicit about, because it is the usual objection: every provider account stays contracted in your own name. You keep your own rates, your own relationship and your own settlement, and funds move from the provider directly to you. PaymentHood is not a processor, is not a merchant of record, and never sits in the flow of funds.
None of this is specific to hosting in its mechanics — routing, failover, idempotency and reconciliation are the same jobs in any business that outgrows one provider. What is specific to this industry is how early they arrive, and how much a failed unattended charge costs. The general version is in what payment infrastructure has to do.
Add a second provider before you need one
Create a free account, install the module for your billing system, and switch on the providers your customers already use. Adding another later never touches your billing system again.