Do NOT use CentralNic Reseller as your domain provider. Here's why.

[lulzkiller]

Do NOT use CentralNic Reseller as your domain provider. Here's why.

Since CentralNic merged with Hexonet and absorbed all their customers, the service has gone completely downhill. First, they hit us with a 5x price increase during the migration — no notice, no warning, just 5x overnight. But the pricing is the least of the problems. What I'm about to describe is either gross incompetence or a deliberate *. After dealing with this for months, I'm leaning towards the latter.

The pattern: domains that "magically" don't get renewed

We manage a large portfolio of .PL and .DK domains through CentralNic Reseller. Over time, we've noticed a pattern: domains that should be renewed in time — where the client has paid, where the funds are there — somehow end up expiring and landing in "former domains." Not once. Not twice. Repeatedly, across multiple .PL domains.

And that's where CentralNic makes their real money. Because once a domain expires and needs to be "restored," they charge ~$50 USD — on a domain that costs a fraction of that at the registry. It's a hell of a business model: let domains slip through, then charge a premium to fix it.

The .PL restore * — how it actually works

.PL domains are operated by NASK, the Polish registry. At the registry level, a domain restore is a single atomic command: domain:renew with an <extdom:reactivate/> extension. One command. It restores the domain and renews it for 1 year. One operation, one fee at the registry. This is defined in NASK's EPP 2.1 specification — it's not my interpretation, it's how the protocol works.

But CentralNic Reseller treats it as two separate billable operations: a restore, then a renewal on top. According to their own support agent, "our system runs restore and renewal separately, one after another."

This means:

1. They charge you a $50 restore fee — which at the registry already includes the renewal.
2. They then charge you a separate renewal fee — for a renewal that the registry already performed in step 1.
3. If you don't have enough funds to cover both (because you rightfully only budgeted for the restore, which should be enough), they delete the domain again and ask you to pay the full $50 restore fee a second time.

Let me say that again: they charge you to restore a domain, the restore succeeds at the registry, their own system fails to process it, and then they ask you to pay the restore fee again. For their mistake.

Proof — here's the actual support chat:

We had a .PL domain — let's call it XXXXXX.pl — show up under "former domains" even though WHOIS showed it active with an expiry date of 2027.03.19. Here's what happened when I contacted support:

Me: XXXXXX.pl - It's under "former domains" but renewal date is 2027.03.19, so there is no reason for it to be under former domains.

Support: Sorry for the wait, I checked the logs and found the restore succeeded but there weren't enough funds to cover the renewal afterwards, which made the domain get deleted again. Please make sure there's sufficient funds available for both operations + VAT to restore the domain.

Me: But WHOIS says renewal date 2027.03.19 — so the domain is already renewed?

Support: WHOIS shows the dates from the registry, where a restore was completed, but it wasn't actually completed fully. Please try again.

Me: I already paid the restore fee. You want me to pay $50 again?

Support: VAT needs to be accounted for as well.

Me: VAT? I'm a VAT-enabled DK company. I shouldn't be charged VAT.

Support: My bad, double checked, no VAT should be charged on your account.

Me: I just checked the NASK documentation. A restore includes the renewal. There is no secondary renewal on top of a restore.

Support: The implementation of our system runs restore and renewal separately, one after another.

Me: Your implementation is wrong. The official NASK documentation states that a restore does both things in one go. If you auto-renew after the restore, the domain is paid twice and should be renewed for 2 years, not 1.

After that — silence. No escalation, no resolution, no refund. I warned them multiple times that I would go public with this. They didn't care to respond.

It's not just .PL

We suspect the same thing is happening with .DK domains. CentralNic charges a restore fee, but the client then has to go directly to Punktum.dk (the Danish registry) to actually get the domain restored. So what exactly is the restore fee paying for?

The bottom line

Let's break down what CentralNic Reseller is doing:

- Domains "magically" expire even when clients have paid for renewal on time
- They charge a ~$50 restore fee that is massively inflated compared to registry cost
- For .PL domains, the restore already includes the renewal at the registry — but they charge a separate renewal fee on top, double-dipping
- When their own system fails to process the restore they already charged you for, they delete the domain and ask you to pay the full restore fee again
- For .DK domains, they charge a restore fee but the client has to deal with the registry directly anyway
- When confronted with evidence from the official registry documentation, they go silent

This isn't one bad support experience. This is a pattern across multiple domains, multiple TLDs, over months. Whether it's incompetence or by design, the result is the same: you pay more, you lose domains, and when you push back with proof, they stop responding.

Stay far away from CentralNic Reseller.
 

[Humanbeing]

The pricing is simply unrealistic, unworkable and anti-partner/customer. And then there are additional costs and friction like monthly subscription. There's no way one can sell anything with their pricing.

Edited April 9 by Humanbeing

[lulzkiller]

Here is their latest reply, basicly telling me to * off, they dont care that 1: Domain is already paid and renewed properly as shown in WHOIS 2: that they are scamming people with double renewals

Dear Thomas,
 
Regarding the issue with the restore for XXXXX.pl I've confirmed with our technical team that our system is working within the rules of the .PL registry. Since your contact for domain management services for XXXXXXX.pl is with us and not with the registry directly, the service is provided as-is per the terms and conditions existing.

What a shitshow of a domain provider. But im gonna escalate this to icann and nask what is governing .PL domains

[RadWebHosting]

Yes, we miss hexonet.

[HamDerPedersen]

Can you recommend another domain provider then? i was actually in the process of setting centralnicreseller up. and already have 9 domains pending transfers

[sahostking]

openprovider any good?? We considering moving to them

[HamDerPedersen]

Yeah, I’ve been looking into the same thing.

Openprovider seems to come up a lot in WHMCS circles, and from what I can see they’re generally considered more “hosting-friendly” than CentralNic — especially when it comes to pricing and the overall reseller experience.

CentralNic is solid infrastructure-wise, but the platform feels a bit more enterprise/less streamlined for day-to-day reseller work. That’s actually why I started questioning the setup as well, even though I already have a few domains in the transfer pipeline.

Openprovider’s pricing definitely looks better at first glance, both for membership and domains, but I guess the real question is how they hold up long-term in terms of support, stability, and API reliability once you’re fully migrated.

Would also be interested if anyone here has real long-term experience with them before making the switch.

[DennisHermannsen]

We've migrated from CentralNic to OpenProvider, and it's been mostly without issues. We've had to contact OP support a few times but have almost always gotten a quick reply.

Their WHMCS module is fine. It needs work here and there but they're open to suggestions - and their entire module is open source so anyone can make PRs. I've submitted a few and got them approved.
Their API can be slow from time to time, but this was also an issue with CentralNic. Unfortunately, OpenProvider's API has a few more stability issues than CentralNic's.

Switching to OpenProvider won't necessarily release you entirely from the hands of CentralNic, though. OpenProvider use CentralNic for a lot of TLDs - but OpenProvider's pricing generally better, even for those TLDs.

[PapaKai]

Hi all,

I only stumbled over this thread a few days ago, so apologies for coming in late.

Short note on who is writing: I look after the WHMCS side of things at CentralNic Reseller, so the registrar module and our SDKs. Pricing and the internals of the reseller backend are not my area and I will not speculate about them here. But there is a bug in our module that explains a good part of what @lulzkiller ran into, and I think it belongs on the record in this thread, because there may be people reading along who still have domains sitting in their WHMCS that are going to drop.

The bug in short: in module versions older than 27.2.7 a TLD data lookup could fail. When it did, we handed WHMCS an invalid expiry date, usually something around 1970-01-01. WHMCS then did exactly what it is built to do with such a date. The domain goes to Expired, auto renew gets switched off, and if you run with Sync Next Due, a renewal invoice is created with a due date in the past and then cancelled again automatically.

We patched that with 27.2.7, released on 26 May 2025. Later on, with 30.6.6, the same lookup got additional hardening and some code improvements. That was precaution, not a second fix for this. Either way, please just upgrade to the latest release, that is the version we support anyway.

Now the part that I think matters most for anyone reading along. The wrong date only ever lived inside WHMCS. At the registry the expiry dates were untouched. So nothing dropped at the moment the data broke. The domain just sat there with auto renew off and no valid renewal invoice, until the real expiry date at the registry came around and nothing was in place to renew it. That is why a bug we fixed in May 2025 can still cause a domain drop today. And it also means that if such records are still in your database, those are domains that will drop later on. As long as it has not dropped yet, it is easy to fix. Afterwards it gets painful and expensive.

Maybe to explain why I take expiry dates that seriously. Years ago, still with HEXONET, we reviewed and improved the expiry date precision for a couple of TLDs, .eu among them. Nothing was broken there, the dates just became more accurate. The result was a wave of generated renewal invoice duplicates in our resellers' WHMCS instances and a lot of end customer communication that nobody had planned for. And that was with correct data. So when a module writes a wrong date instead, and one from 1970 on top of that, you can imagine the rest.

The other thing is that none of this shows up anywhere obvious. We could not find any entry in the WHMCS activity log, neither for the expiry date being overwritten nor for auto renew being switched off. So searching the log will not get you anywhere. And since WHMCS is self hosted, we have no view into anyone's installation or database at all, which is why I cannot run this check for you.

What to look for, and please do this across all of your domains, not just one TLD:

• expiry date at or near 1970-01-01
• auto renew switched off although nobody touched it
• renewal invoices with a due date in the past that got cancelled
• domains sitting on Expired that you are quite sure are still active

One thing to keep in mind: upgrading stops new wrong data from being written, it does not repair what is already in the database. Those records have to be corrected by hand, including setting the domain back to Active.

If you find something, please open a support ticket with the affected domain names and write in there that you are running WHMCS and that it is about the expiry date bug in module versions before 27.2.7. Sounds like a detail, but it helps, that way the ticket lands with my team a lot faster than with a general description.

I am sorry this hit you. We fixed the bug back then when the first ticket came in, and honestly, only within the last days did we understand that it can leave something behind that shows up a year later as a dropped domain. I am going through the whole thread now and will pick up whatever concerns the module.

Kai