The most common WHMCS mistakes to avoid
When creating a WHMCS site to start an hosting business, everyone make mistakes. Each mistake is a learning opportunity but don't fail too much. WHMCS is not CMS like Joomla. It's platform connected to servers, payment gateways, domains and thousands of customers' services.
There's little room for mistakes when providing services is your job. That's why in our beginners guide to WHMCS we stressed the importance of finding a WHMCS expert. If your budget doesn't cover the costs of consulting, keep reading this article. We're going to teach you the basics.
Further Security Steps
You have finished installing WHMCS. Before playing with its settings, you must perform so called Further Security Steps. There's a detailed article that explains everything in the official documentation of WHMCS.
There's no need for us to repeat what the article already says. Here we explain the reasons why such steps are important. While it's true that some are optional, some others are crucial. Never underestimate their importance.
You have to keep in mind that WHMCS is more than a website but the tool that runs your hosting business. It's connected to servers, registrars and payment gateways. That said, cracking WHMCS is more attractive than cracking say WordPress.
Secure writable directories
Move the following directories "above www" so that they're not accessible from browsers:
If you don't move them, a cracker could magage to upload backdoor in WHMCS. The backdoor is a file that grants access to files and database of your system. It is used for data breach, to inject scripts or even worse infect all your servers and steal domains.
The cracker attaches the backdoor in a support ticket. For various reasons, WHMCS renames attachments by adding a prefix. For example uploading hello.txt results into 107046_hello.txt. With that in mind, the cracker only needs to guess the prefix using a directory scanner. As soon as he finds it, the disaster is served. The backdoor is fully accessible from browser.
This was one of the many ways a cracker can benefit from writable directories. Making them secure is fundamental.
Secure configuration file
Still in WHMCS root there's a file named configuration.php. It contains sensitive data that you can't recover without a backup. If you accidentally edit or delete this file, you won't be able to recover passwords stored in WHMCS.
To avoid accidentally overwriting the file, you could make it read-only with CHMOD 400. Other than that, there's no particular reason to do that. This step doesn't increase security but protects you from human errors.
Move crons directory
Another key directory of WHMCS, is crons. It contains scripts that runs automatically via cron job. As we previously said for writeable directories, it is recommended to move it "above www". This way no one can't trigger automated tasks by visiting the directory from browsers.
Restrict access by IP
I'm not a big fan of restricting access to a specific set of IPs for access to WHMCS administration. What if I need to login from mobile phone, via dynamic IP, from abroad or from the computer of a friend of mine?
In such cases seeing "Forbidden" page is annoying. Protection can't be at the expense of my ease of use. Why should I block myself from my own CRM? Anyway feel free to block IPs if you think that it's worth it.
Change admin folder name
For WordPress it's wp-admin, for Joomla administrator, for PrestaShop admin. WHMCS is no different and uses admin. Everyone knows default admin directories to conduct brute force attacks. Exploiting zero-day vulnerabilities still unknown to or unaddressed by publishers is also possible.
All you need to do is to change admin with something else but wait. Don't use things like crm, adminpanel, backend, staff, manage. Also avoid your brand name or common dictionary words. Do you think that crackers are this stupid? If you decide to go for one of these options, you're not increasing protection.
For obvious reasons I can't share with you the exact percentage of people that use easy to guess. They're too many. This step alone offers an high level of protection with almost no efforts. I don't get people find so hard to come up with something like 0D86Y4NG4. You don't need to remember it since you will surely add your WHMCS to favorites.
Restrict database privileges
WHMCS suggests to disable specific database privileges but I'd rather ignore this step. As I previously said, I'm not a fan of security at the expense of usability. If someone compromises your WHMCS, who cares about permissions to alter tables. You have something more serious to worry about.
Many third-party modules and WHMCS itself expressly need such privileges. Why should you waste time turning privileges on and off intermittently? Why should you give up on the possibility to make a backup or truncate a logging table? Skip this step.
Clicking on links
A few paragraphs earlier, we told you the importance of renaming admin directory. Using an unique and unguessable name can make a significant difference. This tactic alone however is useless if you don't lear to keep the name a secret. Let us show how easily you can reveal your admin directory to anyone without even realizing it.
Every time you click a link, your browser includes the referer field which indicates the last page you where when you clicked the link. Simply put, when you click a link from ticket view, you're revealing admin directory.
For example many of our customers click on links that are included in our modules to read documentation, changelogs, download updates... Our Google Analytics detects referrers allowing us to discover admin login pages.
Let's get to the point. We're not saying that you shoud not click any link but be careful with the ones included in support tickets. Get used to copy/paste them in address bar. Keep in mind that opening links in new tab or window still sends referrers.
Beginners have the strange habit to make things complicated for no actual reason. WHMCS is already difficult to learn. Don't make things worse. The table below can help you avoid making bad decisions.
|Don't do this||Do this|
|Creating customer-based products||Use billable items|
|Adding unnecessary configurable options||Keep the purchasing process quick and simple|
|Replicating hosting plans for every CMS||An hosting package can suffice to any CMS|
|Having hundreds of products that never sell||Stick to products that actually sell|
|Using product addons, upgrades and downgrades||Leave them there. Most of the times they are not needed|
|Creating too many support departments||Unless you employ tens of people, all you need is pre-sales and technical support|
|Translating language files||Learn language overrides|
|Faking invoice numbers||There's nothing wrong in starting with invoice #1|
|Hosting fake reviews||Stay away from scandals and fines|
|Branding anything and everything||Don't waste time putting your label everywhere. There's no need to hide that you use Plesk or cPanel|
|Thinking of WHMCS as a multi-tenant software||That's how you manage reseller in WHMCS|
|Offering many choices||
You lose sales. 3 options are fine, 5 are too many:
|Allowing the registration of any TLD||
The day you manage to sell that exotic TLD, you'll waste hours trying to understand why it doesn't work. Stick to popular TLDs
|Wasting client groups||
Customers can't be assigned to more than one group. Don't waste this opportunity with pointless groupings
|Disabling automation to avoid fraudulent orders||
Learn how fraud protection works in WHMCS
|Clicking without reading||
Read docs and ask for help. There's no undo in WHMCS
|Coding action hooks|
SEO and WHMCS are incompatible
|Customizing six template||
Create and work on a copy of six template otherwise all changes will be lost during upgrades
|WHMCS and customers on the same server||
Some hosting control panels can't setup hosting accounts on the same server where WHMCS is hosted (create function times-out). Use a separate servers
Using a CMS
WHMCS lacks tools for content creators and is bad at search engine optimization. Many try to overcome the issue by installing a CMS like WordPress, Joomla or Drupal. This is a terrible idea. You could directly use WHMCS CMS that already includes all SEO enhancements.
If you still want to rely on a third-party CMS, read the following instructions carefully. WHMCS and your chosen CMS must be installed on separated hosting plans. To avoid misunderstanding of any sort, look at the the image below.
This is what we mean by saying "separated hosting plans". We are not talking about alias, subdomains, addon domains, domain or parking. That's not even about separated FTP accounts. You have to treat them as two distinct websites.
It doesn't matter how your CMS will be accessible from the web. It can be example.com/blog, blog.example.com or example.com but keep them on separate hosting plans.
If you don't follow this rule, a cracker can breach into your WHMCS by exploiting a vulnerability of your CMS. Don't put all your eggs in one basket. There's no point in securing your WHMCS while you allow potential attacks to occur from the CMS.
When you spot a mistake in an invoice that was automatically issued by WHMCS, don't try to delete it. Automatically generated invoices have in fact the peculiarity of storing a "reference ID". This value is not visible from interface and cannot be edited.
If you delete an invoice with such IDs, WHMCS won't be able to perform automatic tasks (eg. create, renew, unsuspend products and domains) when needed. Fix the mistake on the same invoice. Do not delete any invoice item otherwise you will be forced to perform all tasks manually.
WHMCS is great at notifying things to customers and administrators. The customization of this feature requires knowledge. The problem is that beginners tend to overestimate their ability. They proceed with confidence making changes to emails unwillingly causing customer confusion.
You start editing email templates with the best of intentions. Probably you want to translate email in other languages but end up adding complexity.
Let's face it, you still don't know how to use WHMCS so you can't really change anything. Take your time to learn this software before making changes. If you don't do that, you risk to confuse customers with emails that make no sense.
With Email Piping, emails sent from customers automatically become support tickets. As a result clients can open and reply to tickets via email without the need to login to the client area first.
You're probably best to stay away from email piping. This is particularly true if you're starting an hosting business from scratch. The misconfiguration of email piping could cause never-ending loops and lost emails.
Let's see it from a different perspective. You started your website with WHMCS. What you need the most are visitors to increase rankings on search engines. Having customers submitting tickets from clientarea surely help.
There's nothing wrong in being a little opportunistic. We put lot of efforts to drive traffic to our site with marketing campaigns. Having customers on your site to open, read and reply to tickets basically is free traffic. Use Email Piping at a later stage.
GDPR establish that email marketing is not allowed without consent. Starting from version 7.5, WHMCS introduced opt-in/opt-out functionality for marketing emails. The problem is that many forget that the rights of customers must be respected.
Every time you use Mass Mail Tool ask yourself if you're sending a marketing email. If so, tick the relative checkbox and to include the unsubscribe URL the body of your message.
WHMCS holds your business together connecting domains, services, payments and customers with automation. The best approach is to embrace this structure as a whole tuning it to match your needs.
The problem is that many want to use third-party solutions to issue invoices. Generally the reasons behind these decisions are a bit silly. Some says they already have a billing software and want to use it for the sake of it.
Stop complicating things and enjoy the fully integrated experience of WHMCS. Billing Extension extends functionalities offering solutions like:
- Monthly invoicing
- Electronic invoicing
- Credit notes
- Invoice to FTP
- Conversion tracking with Facebook Pixel and LinkedIn
If you still want to use an exernal software, prepare to spend time to send invoices manually. Alternatively hire a developer to integrate your software with WHMCS.
It's common for WHMCS owners to rely on external developers and companies. It could be for dedicated WHMCS support, modules or templates. In this scenario sharing your FTP and admin credentials is crucial.
We understand that beginners don't like the idea of granting access to their systems. That's how they end up creating accounts with limited privileges. They also hide customers, invoices and revenues. It's time to debunk the myth that this offers some kind of protection.
FTP access is enough to browse all files, database and WHMCS administration. We're not telling you this to scare you. Simply put, permissions provide no protection from bad behavious. Focus on trusting the right people. That's all you need.