MUST Read Before Launching a WHMCS Site: Bugs & Issues

I started using WHMCS in 2008. As I look back and look at the situation today, I know that something isn't quite right. I recall WHMCS as an old-school piece of software. It wasn't particularly beautiful but it was reliable.

What we have now is a software where form becomed a higher priority than substance. WHMCS staff is spending large amounts of time delivering features no one asked for. In the meantime no one is addressing the real issues we have.

Be advised this post contains a little bit of rant. Working as a developer on this software for so long, I discovered bugs and poor design choices that made me question if WHMCS still deserves my time and efforts.

I don't want to be misunderstood. There are no better options to this software when it comes to start a hosting business. The alternatives to WHMCS are still mediocre but things can change. Especially if WHMCS keeps shooting itself in the foot with every release.

The Miserable Life of WHMCS Developers

The success of a software like this heavily depends on whether it is able to attract developers willing to contribute and add more value.

Even though WHMCS is not open source, it managed to attract many of them. All thanks to API and action hooks that are an integral part of the system.

I recall many software companies working on WHMCS. Today the situation barely resembles what we had just a couple of years ago. We are left with less than 10 companies that are gradually moving to other platforms. At this rate, within the next few years there will be almost no one left.

As a developer who spent 14 years coding on WHMCS, I can say a few words on the matter and also explain why end-users blame us always for the same reasons like:

• Not answering to support tickets and pre-sales questions
• Not updating modules or abandoning them
• Not creating wide-ranging and exhausive modules
• Not writing documentation and changelogs
• Not refreshing modules' pages
• Not reporting bugs to WHMCS
• Not participating in BETA tests
• Not reacting to new releases of WHMCS
• Not caring about backward compatibility

The thing is a release of WHMCS goes from beta to end of life at the speed of light. How can third-party developers like me keep up with so many changes in such a short timeframe?

All while WHMCS is still hardcoding variables and scripts. Not to mention critical bugs and missing features that could fill a book.

On this platform developers have to go through so many bugs, imposed decisions and changes with a frequency that few people can stand.

Obviously not all developers are affected in the same way. If you happen to be the creator of a module that almost matches the complexity of WHMCS, every new release is unbearable.

But there's more. WHMCS has the bad habit to wake up and decide that a feature we are using from years must be removed in favor of a new one that is worse. No documentation and dates are provided. It's all in their head.

I don't think is normal that even companies with tens of developers need to invest months to make their modules compatible with the latest silly release of WHMCS. I'd like to move forward and stop reinventing the wheel on every major update.

I promise I still want to work with WHMCS but they are making it very difficult.

The main issue is that WHMCS release process looks like a forced march. They pump out updates full of bugs that sum to old ones to the point where it's even hard to say if they still exist.

Things got worse few years after cPanel acquisition of WHMCS when they adopted a software development philosophy that emphasized the importance of early and frequent releases. This philosophy aims to increase quality because frequent releases:

• Help to conform the software to the users' requirements
• Allow feedback between developers and users
• Help to provide bug-free releases

This doesn't happen in WHMCS since we are living in the era of «Please, submit a feature request». It's their nicer way to say they don't care about your feedback. Feature requests is in fact the place where good ideas go to die.

Nowdays WHMCS bases its job more on partners' needs than on our expectations. They've stop listening to customers a long time ago and quickly cassify most of reported bugs as "feature" or something that is working as expected.

It feels like they care about anything that is not relevant to their user-base. I have a pile of notes about bugs, hints, hacks, workarounds and secrets. I bet every developer has one but I've stopped to report them since WHMCS staff doesn't seem to care.

All they do is insisting with their frenzy of releasing bugs and barely tested features. Even worse, it looks like they don't do research before launching new features leaving us to weeks, months or years of troubles.

Next time you blame a developer for not answering to support tickets, remember this post and how exasperating is coding on this system. I think part of the problem is that in the current scenario we are a sort of relief valve.

WHMCS staff doesn't listen therefore many providers kind of redirect the frustration on third-party developers. But there isn't much a developer can do when this software continuously annihilates all efforts.

As for me, my disaffection towards WHMCS reached a peak. I'm working hard to compensate the lacks of this software but things are far from being rewarding. Taking the blame from end-users because something we can't control doesn't work is a routine. Frankly it is getting boring.

Because of all these reasons, I'm slowing down with coding new stuff. WHMCS bugs already keep me busy. I even stopped working on custom solutions and integrations.

Lastly I am no longer in the mood to share my findings with WHMCS staff. They are filling their software with bugs and skip "fixing days". They don't care. Why should I?

In the following chapters I'll list some of these bugs and problems.

WHMCS at its Finest

Let me make one thing perfectly clear. It's alright to improve the software but WHMCS has a strange way of doing it:

• In 2020 they celebrate the introduction of image uploads
• In 2021 the implementation of Bootstrap 4 with 6 years of delay
• They don't know anything about SEO and keep following SEO myths
• The world evolved to Structured Data but we still lack sitemap generator
• Announcements and KB seem to come from the 90's
• People are still integrating WordPress with WHMCS

Better late then never I guess but you can't improve anything at this speed. It's like trying to carry water in a sieve. WHMCS always fall behind in tech and they lack expertise in critical topics like billing and SEO.

From time to time I question myself how is it possible that I manage to deliver more features in my modules working alone than the entire staff of WHMCS combined. Let me give you an idea of what I am talking about:

• Turn WHMCS into a CMS with blog, news, docs, feature requests, comments...
• SEO for WHMCS including SEO URLs, sitemap, GeoIP, OG Tags...
• Track sales with Facebook Pixel and LinkedIn Insight Tag
• Reduce invoices by 80% and transactions fees by 18% with monthly invoicing
• Provide support based on Service Level Agreement
• Cash flow for tracking inflow and outflow of money
• Customer Retention and Churn Rate
• Advanced Invoice Data Snapshot that includes currency rates
• Perfect integration with VIES, Australian GST, Tax Stamp
• Issue Credit notes
• Stop issuing unnecessary invoices thanks to invoice suppression
• Automatic Batch Invoice Export. PDF files are sent via FTP and/or and email as attachments
• Affiliation Network with multiple Attribution Models

The list goes on but I think you've got the idea. And I even maintain a documentation (in two languages) this is bigger than WHMCS one. Going further, I actually try to solve real issues.

While WHMCS still tells us to use phpMyAdmin to retreive certain data, I created SorTable to let people easily view, filter and export anything they want. It took me a couple of weeks but it was well worth the effort.

HereLang was my response to multi-language and SEO. Translating contents in a side-by-side view safe from duplicate content is something that WHMCS has never heard of.

With MagicInput I notably improved user-experience with tens of new-generation inputs all in once. In the meantime WHMCS gave us just the calendar... 5 years after me... What a speed!

No one forced me to create all these features or put a gun to my head when I decided to solve such problems and to write an extensive documentation. I did it because it is my job.

My only concern is what the heck WHMCS is doing. The average update of WHMCS contains (not counting bugs) microscopic features that I wouldn't even put in a changelog.

I mean they presented us the CALENDAR picker as if it was something like going to Mars. It's a free jQuery library. Any decent developer can implement it in a couple of hours in any system.

I can't believe how slow and non-impactful is their commitment. We have bugs from years that would take minutes to fix. Similarly we are waiting for missing features that any skilled developer could complete in a couple of days.

I don't want to sound presumptuous but I must say it. I find incredible that a company of the size of WHMCS still doesn't manage solve certain issues we have. Including things I managed to fix myself without even seeing the source code.

I also continue supporting customers that run WHMCS v5 as well as modules and templates created by competitors. On the contrary WHMCS with all resources they have put everything in "End of life" deprecating core features like nothing happened.

I sometimes wonder myself what would they do to integrate electronic invoicing. I know this article is written in italian but it still gives an idea the complexity of this project. Imagine the amount of code behind it. Let me make a quick comparison.

I completed such a huge project in about 3 months working alone. In the same amount of time and with God knows how many employees, WHMCS is still trying to fix GDPR they broke in v8.

WHMCS v11: Exclusive Preview

Joke apart, every software nowadays is turning into Instagram including WHMCS. Although we need to process more data, WHMCS design relies heavily on minimalism with unfortunate side effects.

Let's take a look at the new and shiny twenty-one template of WHMCS v8.1. I have a 34 inch monitor with 21:9 aspect ratio (3440x1440 pixels). Everything looks like a recepit: narrow and too small.

What's the point of having bigger screens when designers add margins that extend from New York to Rome? It's like if they create pages to host margins instead of contents in an ocean of white. Let's move to domain page.

Here we have the opposite situation. 34 inch are not enough to have search bar and buttons veritically aligned. In the meantime a gigantic space is occupied by an useless padlock and I can't open rows on a new tab.

Moreover WHMCS fits two values in the same column (domain name and auto renew on/off). The very point of using tables is to have a column for each parameter but WHMCS is full of columns that host mixed values.

I could go on for days with examples. In my opinion this is not minimalism but a shortcut to bad design. I bet one day WHMCS will replace domain names with an icon just for the sake of minimalism. Or remove Registration to think out of the box.

WHMCS Order Data Snapshot

Let me present you one of the most sneaky issues that very few people know.

WHMCS doesn't preserve customer details upon order creation. It may not seem a big deal but it is, especially for domain registrations.

Let's suppose a customer transfers 100 domains using the following registrant details:

Fiorenza Panicucci
TIM S.P.A.
tim@example.com
Via Callicratide 24
Ussel
AO
11024
IT - Italy
+39.03102578690

As you know, it may take some hours/days before all transfers complete. In the meantime the customer is free to update his details in any moment from client area. Let's pretend he changes the email as follows:

Fiorenza Panicucci
TIM S.P.A.
fiorenza@example.com
Via Callicratide 24
Ussel
AO
11024
IT - Italy
+39.03102578690

Soon after, he proceeds to transfer 100 more domains in a new order. This is pretty normal since the customer in question clearly needs to use different registrant details for this last purchase.

At this point we have two orders each one with 100 domain transfers. They're both linked to the same customer but they have two different registrant details:

• First order has tim@example.com
• Second order has fiorenza@example.com

We would all expect WHMCS to process each order with its respective registrant details but this is not going to happen. It will process both order with the latter email. That's because it doesn't store customer details when the order is placed.

The consequences are distruptive because you are transfering domains using wrong details violating ICANN regulations. Moreover customers can sue you or force you to fix all errors which costs money and precious time.

This was an extreme example but image what happens on a daily basis on your system while you don't suspect anything. Before you think of using sub-accounts, this still doesn't solve the issue. As if it wasn't enough, the problem also extends to API functions.

Only WHMCS staff can implement a solution. They need to preserve client details upon order creation to prevent profile changes for existing orders. They also need to change DomainTransfer and DomainRegister API command so that they accept full registrant details.

It's not that difficult but they have other priorities. For sure there's something more important than preventing legal troubles and extra-costs to their customers.

Password Reset in WHMCS v8

Before we dive into more complex issues, let's spend a few words about poor design choices. Before v8 resetting customers' passwords was a one-click operation. Now I have to go through a confusing process that looks like I'm hacking my own system:

• Replace user's email with mine
• Perform Login as Client
• Initiate password reset to receive the reset link on my email
• Restore user's email and manually send him the link

It is ridiculous that an administrator can't change customers password but it is what it is. Imposing how we should run our businesses is the new trend in WHMCS. Don't like it? They surely don't care but will tell you to submit a feature request.

WHMCS Billing

It's understandable that WHMCS doesn't want to deal with things like Brexit, electronic invoicing, Tenerife and regulations constantly changing every year. This explains why this software lacks many billing concepts.

WHMCS prefers to place such a burden upon us so that they can focus on releasing new bugs and pointless features. I built a career on billing lacks of this software creating Billing Extension where I address all the issues.

Even though it's clear that WHMCS is not interested in finding a way through this billing jungle, from time to time they ruin everything taking nonsensical decisions based on nothing but superficiality.

They think they are in the position to change anything they want even if they've done no research. They don't need need to double check anything or contact an accountant for clarifications. They prefer to use us as lab rats.

I remember one day when they unilaterally decided to calculate VAT individually per line item. Let's suppose we had 5 items that costed 12.98 euro each plus 22% VAT. Let's do the math: 12.98 x 5 = 64.9 euro. 22% of 64.9 is 14.28 euro VAT.

According to WHMCS it was 2.86 euro (22% of 12.98) multiplied by 5 for a total of 14.30 euro. For a couple of weeks we all issued invoices with wrong amounts. I still remembr I had to correct thousands of them.

Automated Upgrades and Downgrades

I'm talking about Upgrades/Downgrades functionality. As the name suggests, it is used by customers for configurable options changes. Sadly the way it works causes billing errors. But first, a little background.

WHMCS doesn't handle Add Funds invoices correctly. What it does is considered illegal in most countries. When a customer decides to upload funds, WHMCS issues an invoice with no tax causing more than one problem.

Step	Description
Add Funds	It's 2020, VAT rate is 22% and WHMCS issues and invoice that looks as follows: Subtotal: 100 € VAT: 0 € Credit: 0 € Total Due: 100 €
Payment	The customer pays 100 € and receives a credit balance of 100 €. This causes the first problem. I most of the countries VAT must be charged every time you receive a payment. An invoice with no VAT applied is not okay unless there was a specific reason (eg. VIES, special tax regimes)
Credit Usage	Part of this credit is used to renew a service that costs 10 € / year. Here is the resulting invoice: Subtotal: 10 € 22% VAT: 2.20 € Credit: 12.20 € Total Due: 0 € Here we have the second problem. Invoice amount is zero. No payment is required. In some countries this kind of invoice not only is unnecessary but can't be registered
Renewals	We use the remaining balance is 87.80 € for subsequent renewals: In 2021 WHMCS deducts 12.20 € including 22% VAT In 2022 VAT rate changes from 22% to 23% and WHMCS deducts 12.30 € In 2023 WHMCS deducts 12.30 € including 23% VAT This is wrong on many levels. First. You need to wait 2028 before the VAT charging takes place for a payment that was sent 8 years earlier. Second. The customer is subjected to different VAT rates, rules and fiscal years for a payment sent in 2020

To overcome this whole craziness, I created a feature that charges VAT on Add Funds Invoices. Basically I issue an "Add Funds" invoice that includes VAT as follows:

• Subtotal: 100 €
• VAT: 22 €
• Credit: 0 €
• Total Due: 122 €

When it comes to renewals using credit balance, WHMCS would issue a zero-value document that's why I created another feature to suppress zero-value invoices.

Now that you know the basics, let's go back to Upgrades/Downgrades. This feature is based on refunding unused resources for the current billing cycle. I know that it sounds complicated so let me make an example.

Today I order a hosting account with backup that costs 50 euro per year. Few minutes later I change my mind. I want to get rid of Backup and activate Antispam that has the same exact price.

Even a child understands that no amount is due. I mean the price for both options is the same but WHMCS has a different opinion. Here is the resulting invoice:

• Subtotal: 50 €
• 22% VAT: 11 €
• Credit: 50 €
• Total Due: 11 €

Total Due and VAT are both inexplicably wrong. To put things into perspective, it should have been like this:

• Subtotal: 0 €
• 22% VAT: 0 €
• Credit: 50 €
• Total Due: 0 €

No amount is due hence issuing an invoice shouldn't even be an option. Now let make another example that will blow your mind.

This time we replace an option that costs 10 euro with one that costs 50 euro. In essence it's -10 +50 not counting VAT but here is what WHMCS does:

• Subtotal: 50 €
• 22% VAT: 11 €
• Credit: 10 €
• Total Due: 51 €

While it should have been this:

• Subtotal: 40 €
• 22% VAT: 8.8 €
• Credit: 10 €
• Total Due: 38.8 €

As if it wasn't enough, calculations are also inconsistent. This is what WHMCS shows me when I upgrade my service.

It wants me to pay 68.93 euro. It's wrong but leave it aside for the moment and click continue to get to the invoice.

What the heck is going on here? Total due is now 92.40 euro. There's a difference of 23.47 €. Where does it come from? How is it possible? Hold on tight. WHMCS uses different formuals to calculate the same number.

Upgrade Formula	Invoice Formula
Total Due = (Total Debited - Total Credited) + 22%	Total Due = (Total Debited + 22%) - Total Credited
(163.2 - 106.7) + 22% = 68.93	(163.2 + 22%) - 106.7 = 92.40

No script in this world can fix this bug since it is rooted in WHMCS core. I reported the issue and they told me it will be fixed someday in the future. It was 3 years ago. The only solution we have right now is to disable this feature and pray Zeus.

Subscription-Based Overpayments

The problem with recurring payments causing overpayments is one of the most frustrating things we face in WHMCS. Here is another table to describe our enemy.

Step	Description
Order	It's 2020, VAT rate is 22% and I register a domain for 12.20 € (10 € + 2.20 € VAT)
Payment	I pay the resulting invoice creating a subscription payment. Invoice number is #2020-500
Renewals	Now it's 2021. I can't remember what I ate yesterday. After 12 months I will surely forgot about the automatic renew. As soon as I start receiving expiration noties, I will send the payment manually because I don't want to risk losing my domain name
Overpayment	PayPal (or any other payment gateway) doesn't know anything about my manual payment. The subscription payment arrives as normal few days later. Since the invoice is already paid, the subscription payment is an overpayment, and so is credited to my account

This is a billing horror.

First off WHMCS adds the overpayment on the invoice of the previous year meaning that invoice #2020-500 moves from 2020 to 2021. If this leaves you speechless, there's more. It also changes the amount and messes with VAT.

Invoice balance is now 20 euro. WHMCS assumes that every year VAT rate is the same and also that customers never change their entity type. In essence it will charge 2021 VAT rate on a transaction from 2020.

Things get worse in case the customer doesn't use all his credit balance (the overpayment) before next renewal. WHMCS in fact applies it to pay subsequent invoices.

This doesn't stop PayPal from sending the subscription payment that every year will result in a another overpayment. Let me say this again: EVERY YEAR.

I've seen systems where the same invoice moved from 2012 to 2013, 2014, 2015 etc. It's an infinite loop that never stops till someone removes the credit or cancels the subscription.

The good news is that I managed to fix the problem by issuing invoice for overpayments. This way WHMCS doesn't change and move invoices from previous years.

The bad news is that there's a type of overpayment you can't stop and correct. Read next chapter to learn more.

Invoice Items Disappearing

This is some serious stuff. If you are using WHMCS from a couple of years and you're allowing domain registration, there's a chance you faced this problem before.

I'm talking about items that disappear from existing invoices leaving you with empty invoices or with ones that look like follows (look at the negative balance).

Originally this proforma had two invoice items:

• Silver - example.com
• Domain Renewal - example.com

Where did Domain Renewal go? WHMCS silently removed it because the customer renewed the domain in question from another proforma. Let's see what happened here.

In past it was possible for customers to accidentally renew domains tiwice. On one hand there was WHMCS issuing the proforma for renewal a certain number of days before domain expiration. On the other customer was free to renew it anytime from client area.

Today it is still possible to have two proforma for the same domain. The difference is that once one of the two is paid, WHMCS removes the "duplicate" from the other proforma. This way customers can't renew the same domain twice but this is a very stupid solution that opens up to a bigger problem.

How can we explain and register the resulting invoice? Amounts are wrong. It's plain math. And by the way if the invoice in question had no other items, you end up having an empty invoice.

According to WHMCS, this is not a problem nor a bug but (I quote a thread on the argument) "An elegant way" to solve the problem of double-renewals. Frankly I don't see how creating a billing error can be defined an "elegant solution".

There are several threads where people ask how to disable this feature but the answer is that we can't. Don't forget WHMCS loves imposing how we should manage our companies. What's sad is that double-renewals can still occur due to automatic payments.

Weird Calculations

WHMCS failed in math exam and the following screenshot is the proof. What you're seeing is an invoice that contains two transaction. One positive and the other negative.

Believe it or not in WHMCS 12.20 plus -12.20 equals 24.40. This scenario is reproducible by adding a negative transaction and occurs because the minus sign is ignored and so the invoice is overdue while in reality it's not.

VIES is Inconsistent

WHMCS staff thinks that billing is all a joke in fact it is no secret that their VIES has some serious drawbacks. It ignores concepts like entity type and split payment. Let me give you an example involving Tax Exempt.

Tax Exempt depends on a wide variety of checks that WHMCS ignores. With coding I managed to "teach" WHMCS what to do when multiple events occur (eg. cron, client edit, client registration) but this little button doesn't respect any rule.

Altering Tax Exempt from here doesn't trigger ClientEdit hook point meaning that no check can be performed. Good luck fixing billing mistakes. The good news is that I reported this bug and it has been fixed in v8. What a rarity!

Navbar and Sidebar

I'm not the best developer in the world but certain things in WHMCS are tortuous. If you want a taste of it, take a look at the flowchart below that I have to follow in order to fix certain issues. It's a little ironic but this is what I'm subjected to on a daily basis.

Navbar and sidebars make no exception. It's not acceptable that changing a button requires you to learn PHP or to hire a developer. This should be easy and made possible via interface.

Welcome, Wrong Name

Let's say you have an account with the following sub-accounts.

Now try to log in to clientarea with Mark White sub-account and this is how WHMCS welcomes you.

No matter what sub-account you use. For WHMCS you are always "Anna", the first sub-account from the list.