Leaderboard

A system should be designed to be functional for its paying customers, rather than being dictated by external regulations that may or may not be applicable to all users. Implementing such a feature without a proper disable option is impractical and appears to be an oversight. The current suggested workarounds are ineffective for the majority of standard web design and hosting businesses. Remember, most projects start off with two 50% (published) invoices (deposit and final) from the quote when converted and the final invoice typically gets tweaked for various reasons. This change would prevent that quick 10 second update to it. WHMCS should focus on developing efficient software that delivers value to its users, allowing us to manage legal compliance independently, rather than introducing features that hinder usability.

Yes, I agree they should be an option

This new "feature" is terrible and is a fundamental change. This feature does not conform to most businesses and should be an option if there are other regulatory purposes in other countries. It severely limits the flexibility of the system and limits its function. I highly recommend a switch to disable this new "feature".

Request WHMCS to make it a confugurable option instead of removing it?

The one question I have is "why"? Clearly there's a need and demand for it, why is it not even considered being made optional, with warnings about not doing it or what have you. Why is it simply removed, with no options and so on.

Are there still issues after the 9.0.3 release?

This is what one WHMCS Staff tell me You have the option to make the change to your WHMCS configuration.php file and add the line $allow_adminarea_invoice_mutation = true;, but it is your decision whether to do so. When this line is present in your configuration.php file, the system will permit most of the changes to invoices that existed before WHMCS version 9.0, notably: Line items can be changed for invoices in any status (when in the "Manage" mode and with the correct admin user permissions set). All attributes are available in the Options tab regardless of the invoice status (when in the "Manage" mode and with the correct admin user permissions set). Payments can be applied in the Add Payment tab regardless of the invoice status (with correct admin user permissions set). Please note that using this configuration line ($allow_adminarea_invoice_mutation = true;) in your WHMCS configuration.php The file is highly discouraged, as it may permit changes that are not compliant with regional/country business regulations and complicate accounting. To bring awareness of this, a Warning health check will appear in the System Health Check summary when the value is present in your WHMCS configuration.php file. Additionally, all “full administrators” will see an Admin Warning banner (which can be dismissed up to every fortnight). You may want to add it temporarily if you do need to make the changes listed above, which were changed in WHMCS version 9.0 to improve invoice management and ensure tax compliance by keeping invoice records consistent. If you do not see any warnings or have issues with editing invoices or changing their status when this line is added, please let us know. Starting with WHMCS version 9.0, non-Draft invoices are immutable. This means you cannot edit transactions (now listed under the Ledger section on the invoice), add or remove items, or modify descriptions on an invoice once it’s no longer in the "Draft" status. This change is intended to improve invoice management and ensure tax compliance by keeping invoice records consistent. For more information on invoice management in WHMCS version 9.0, please refer to the following documentation: https://docs.whmcs.com/9-0/billing-and-invoicing/invoice-management/

Does anyone now how to remove "Search for a domain with AI-powered suggestions"? Thanks

@Justin ROCKET LAUNCHER Your WHMCS already looks quite close to your main website. I'd probably just rework things like the sidebar panels and hero section, but honestly, it's not as bad as you might think. That said, there's more than one way to approach this. WHMCS doesn't have to be 100% identical to your main website. Keeping the same branding (colors, tone, general feel) is important, but at the end of the day it's still a separate system with a different structure. Trying to make it feel completely seamless usually hits a limit. In our case, we ended up taking a slightly different approach, keeping most of the experience on the main site and only relying on WHMCS where it makes sense. I'm inviting you to see how we made ours looks like for both guests and logged-in clients.

This is fully achievable. You can either redesign WHMCS to match your website, or go fully API-driven and handle everything directly on your main site without exposing WHMCS. We’ve implemented similar solutions before that are still in production today, including domain registration, support centers, and custom domain search integrations. The main issue is likely the developers you’re hiring. Lower-end developers usually lack the experience required for this level of integration. What you are asking is NOT a simple “WHMCS tweak” It is: → a custom frontend application → with WHMCS acting as a backend API Most developers fail because: - They only know WHMCS templating - They don’t understand UX flow - They don’t build proper API orchestration A proper implementation would typically cost: $5.000 – $20,000+ for full api-driven (true seamless experience)

Glad to see more customers speaking up about this… it’s a simple, fixable issue. All they need to do is keep allowing the switch: Add ($allow_adminarea_invoice_mutation = true;) in your WHMCS configuration.php . WHMCS choosing a one-size-fits-all strict model is what’s really causing the pain… let us decide if we need to deal with regional compliance and added accounting complexity, not force it on everyone.

Not everyone wants SAAS solutions, or keeping data with a third party due to concerns about client data. I'm one of those businesses.

It totally broke the adding late fees option. I have invoices that are many days old and none of the late fees have been added like they were supposed to be. This is a real mess.

Yes, I'm hoping they're making an option

If I had to guess, it's not an arbitrary decision, but based on some legal requirement they must follow or get into trouble. I'd have hoped a "change this at your own risk" choice would suffice, but maybe they don't want to chance someone claiming they missed it. Just a guess.

Thanks for the confirmation @WHMCS Ricardo. I really hope WHMcs team reconsiders this, hopefully making it optional.

I would say this issue qualifies needing a last resort technique since they are removing it. What else can I do?

Whats stupid is as a developer this is as simple as adding a checkbox to the config to allow us to choose ourselves. I've never in my life understood why software companies lock you in, instead of giving you the option. You keep increasing prices year after year and you want us to stay with you, but if you keep doing this crap most of your base is not gonna find value in your ever increasing prices.

Welcome to the common sense reasons why were frustrated about WHMCS enforcement of preventing us from editing our OWN invoices we created in the first place. Credit / debit is useless in real world standard practice. If they want to provide a switch to disable editing published invoices or changing status fine, but dont force it on the customer base. That's dumb.

Check the domain at NEO, as @RadWebHosting suggests the payment of the invoice will trigger a renewal with the registry. If NEO support domain syncing then the expiry update will be updated in due course. I can't find the article but the way to do this without getting a renewal processed is to edit the invoice. Then on a new line copy and paste the details of the domain and dates, add the price and then delete the original line. WHMCS links the line item to the action of renewal. By deleting the original line the renewal action is not done.

While invoice editing can currently be re-enabled via $allow_adminarea_invoice_mutation = true; in configuration.php, this option is reportedly being removed in a future release. This raises a practical concern: how are administrators expected to handle routine tasks such as removing late fees or splitting system-generated invoices that are linked to products and services?

Hello everyone, I wanted to share a simple but effective security approach I implemented in WHMCS to reduce spam registrations and fake account abuse. The idea is straightforward: users must verify their email before they can access any part of the client area or place orders. Overview If a user has not verified their email address, they are completely restricted from using the client area. This includes blocking access to: $blockedPages = [ "clientarea", "services", "invoices", "domains", "tickets", "productdetails", "upgrade", "addons", "downloads", "supporttickets", "serverstatus" ]; Access control behavior When a user is not verified: They cannot access the dashboard They cannot view services They cannot access billing or invoices They cannot open or view support tickets They cannot use upgrades or addons The only allowed access is the email verification flow. Allowed page for unverified users Unverified users are only allowed to access: /user/profile From this page they can: Resend the verification email Update their email address if needed Complete the verification process User flow User registers an account Verification email is sent automatically User logs in System checks verification status If not verified, all client area access is blocked User is redirected to the profile page After verification, full access is restored automatically Purpose The main goal of this system is to reduce spam accounts, fake registrations, and abuse of hosting resources. It ensures that only verified users can interact with services, which significantly improves account quality and reduces unwanted usage. Result This approach helps: Reduce bot registrations Prevent disposable email abuse Improve security of client accounts Keep hosting resources clean Ensure only real users access services EXAMPLE BELOW THIS IS HOW IT LOOKS, If anyone is interested, I can share the hook code for this implementation.

Nice. Thanks for sharing!

AI wont kill WHMCS right now and any near future. The logic behind a system like WHMCS its too huge to replicate easily, domain renewals is one thing, but making it all work together with invoices, dns, hosting, etc etc etc. You need to spend alooooooot of tokens for doing that. So no, right now AI wont kill WHMCS, but give it 2-3 years surely yes WHMCS will be replaced by other systems.

Try this: @media (max-width: 768px) { .sidebar { display: none; } }

I did find that I can manually change the status to Draft in the database and then I can edit the invoice and then publish it again.

Since editing invoices will be removed in the future I cannot do any more updates.

can you try something like, put this in a file includes/hooks/hide_cart_sidebar.php <?php if (!defined("WHMCS")) { die("This file cannot be accessed directly"); } /** * Remove Categories, Actions, and Currency panels from the cart sidebar. */ add_hook("ClientAreaSecondarySidebar", 1, function ($vars) { $filename = \App::getCurrentFilename(); if ($filename !== "cart") { return; } $sidebar = \Menu::secondarySidebar(); $sidebar->removeChild("Categories"); $sidebar->removeChild("Actions"); $sidebar->removeChild("Choose Currency"); });

I have reported the following on 19th Feb 2026 : == Affected Version == WHMCS 9.0.1 == Description == When a client attempts to upgrade an existing yearly/recurring service to a one-time (lifetime) service, WHMCS throws a fatal DivisionByZeroError in includes/upgradefunctions.php inside SumUpPackageUpgradeOrder(). This happens on the latest WHMCS version running on PHP 8.3 and occurs even with all custom hooks/modules disabled, indicating a core issue. This was working fine with PHP 7.4 ex : Error: DivisionByZeroError: Division by zero in public_html/includes/upgradefunctions.php:0 Stack trace: #0 public_html/upgrade.php(0): SumUpPackageUpgradeOrder('9043', 10, 'monthly', '') #1 {main} == Steps to Reproduce == Use the latest WHMCS version on PHP 8.3. Create a recurring product (e.g., yearly billing cycle). Create a second product with pay type “One Time”. Set up an upgrade path from the yearly product to the one-time product. Log in as a client with the yearly service. Go to Client Area ? Upgrade/Downgrade and attempt to upgrade to the one-time product. The upgrade page fails with a fatal error. == Expected Result == The upgrade page should load normally == PHP Version == 8.3 == Severity == High This was confirmed to be a bug [ case WHMCS-25204 ]. Since then, two minor versions (WHMCS v9.0.2 & v9.0.3) were released, and this is not fixed yet!

Thank you for the reply @WHMCS John and for getting back to me about the credit note issue. Just a bit of feedback, for me personally ( our accounts dept are happy to do the add payment) if would be a lot easier if you could tick a set of invoices and mark them paid - it would then show them paid with the method stated on them (eg bank, cheque etc) rather than having to go into say 80 invoices individually to add a payment to each one

Rad web hosting announces release of client-facing whmcs whois addon module! Rad Web Hosting is pleased to announce the release of client-facing WHMCS WHOIS addon module. Rad Web Hosting Announces Release of Client-Facing WHMCS WHOIS Addon Module Rad Web Hosting is pleased to announce the release of its new client-facing WHMCS WHOIS Addon Module, a powerful and flexible extension designed to provide a secure, public-facing WHOIS lookup interface for WHMCS installations. This module enables hosting providers, domain registrars, and infrastructure operators to offer fast and reliable domain WHOIS queries directly from their WHMCS platform. The module was developed to address a common need among hosting providers: offering a public WHOIS lookup tool that integrates seamlessly with WHMCS while maintaining performance, security, and administrative control. With built-in caching, CAPTCHA protection, customizable WHOIS servers, and strict domain validation, the WHMCS WHOIS Addon Module delivers a modern and abuse-resistant solution for domain lookup services. A Modern WHOIS Lookup Tool for WHMCS The new addon introduces a clean and efficient WHOIS lookup interface that can be accessed by both clients and public visitors. Hosting providers can easily add a WHOIS lookup page to their WHMCS deployment, allowing users to query domain registration information without requiring login access. Visitors can simply enter a domain in the standard format: example.com The module then performs a WHOIS query and returns the registry response directly within the WHMCS interface. The public lookup page is accessible via: https://yourdomain.com/index.php?m=client_whois This makes it easy for providers to link the tool from their homepage, domain search pages, knowledge base, or marketing landing pages. Designed for Security and Abuse Prevention Public WHOIS services can easily become targets for automated abuse. To prevent this, the Rad Web Hosting WHOIS Addon Module includes several built-in safeguards. Anonymous users are required to complete a CAPTCHA verification using WHMCS’s built-in CAPTCHA framework before performing a lookup. This allows the module to automatically support whichever CAPTCHA provider is configured within WHMCS, including: Google reCAPTCHA hCaptcha Cloudflare Turnstile WHMCS built-in CAPTCHA Logged-in clients are exempt from CAPTCHA, allowing for a smooth user experience while maintaining protection against automated queries. In addition, the module enforces strict domain validation rules, ensuring that only properly formatted domain names can be submitted. Intelligent WHOIS Server Resolution Different domain extensions use different WHOIS servers, and managing these differences can be complex. The Rad Web Hosting module solves this by implementing a flexible multi-layer WHOIS resolution system. When a lookup is performed, the module resolves the correct WHOIS server using the following priority: Administrator-defined WHOIS server overrides Built-in WHOIS server mappings Automatic IANA referral lookup This approach ensures compatibility across a wide range of domain registries while allowing administrators to customize WHOIS servers for specific TLDs when necessary. Through the module’s admin interface, operators can easily add, edit, or disable WHOIS servers for individual domain extensions. Built-In WHOIS Caching for Performance To ensure fast response times and reduce unnecessary network requests, the module includes a built-in filesystem caching system. When a WHOIS query is performed, the response is stored locally and reused for subsequent requests during the configured cache lifetime. This significantly reduces outbound WHOIS traffic while improving lookup speeds for frequently queried domains. Typical performance improvements include: Scenario Response Time Cached lookup Under 10 milliseconds Fresh WHOIS query 200–900 milliseconds By caching responses, the module also helps protect upstream WHOIS servers from excessive requests. Flexible TLD Validation The addon allows administrators to define which domain extensions are accepted by the lookup tool. This configuration is maintained in a separate file, making it easy to update without modifying the core module code. Administrators can also choose to allow any TLD if they prefer not to enforce a strict validation list. This flexibility makes the module suitable for environments ranging from small hosting providers to large-scale domain marketplaces. Seamless WHMCS Integration One of the key goals of the project was to ensure that the module integrates naturally with WHMCS. The addon follows WHMCS development best practices and relies on native platform functionality wherever possible. See also How to Install WHMCS Domain Reseller API Registrar Module Key integration features include: Native WHMCS CAPTCHA support WHMCS addon module architecture WHMCS database integration for server management Smarty-based client area templates Compatibility with WHMCS security and configuration settings This ensures that the module behaves like a natural extension of the WHMCS platform rather than a standalone add-on. Easy Installation and Deployment Deploying the module takes only a few minutes. Administrators simply upload the module directory to the WHMCS addons folder and activate it through the WHMCS admin panel. Once activated, the module automatically creates its required database tables and becomes immediately available. The lookup page can then be accessed through the WHMCS routing system and linked anywhere on the provider’s website. Ideal for Hosting Providers and Domain Services The WHMCS WHOIS Addon Module is especially useful for: Web hosting providers Domain registrars Domain marketplaces Infrastructure platforms SaaS providers managing domain portfolios By offering a built-in WHOIS lookup tool, providers can give visitors quick access to domain registration data while keeping the entire experience within their own platform. Continuing Innovation from Rad Web Hosting The release of the WHMCS WHOIS Addon Module reflects Rad Web Hosting’s ongoing commitment to building practical tools for the hosting and infrastructure community. Rad Web Hosting has long focused on delivering solutions that combine performance, security, and operational simplicity, and this module continues that tradition by providing a production-ready WHOIS lookup system designed specifically for WHMCS environments. Future enhancements may include additional performance improvements, advanced caching options, and expanded domain intelligence features. Availability The Rad Web Hosting client-facing WHMCS WHOIS Addon Module is available now. Github: https://github.com/Rad-Web-Hosting/client_whois WHMCS Marketplace: https://marketplace.whmcs.com/product/8495-client-whois-lookup For more information about Rad Web Hosting services and tools, visit: https://radwebhosting.com Find us on whmcs marketplace

Love to see it, but we've heard that so many times it's a bit hard to believe.

Yeah, 6 months minimum

We always upgrade a year later for good reason. 😉 Anyways we will probably stop with WHMCS in general and we are in the process of coding our own perfect suited solution instead. Much better. Only the things you really need, no errors, easy code and much faster as well. But. It will take time. In the meantime we will still be using WHMCS.

We waited for V 9.0.2 in the hope that it will have no issues, and had the misfortune of upgrading. And since then spent an entire day trying to get it to work and it does not work. Issue 1: When you add a product to the Cart", the Nexus Cart shows empty with this warning: "error has occured" (screenshot below) Issue 2: I renamed nexus_cart to nexuscart, and then the Cart showed the product added to it, but several warning appeared on screen: "Internal Error. Try again later". (screenshot below) Issue 3: When you try to increase the number being ordered (1 to 2), you get another error: "invalid product/item ID". (screenshot below) Issue 4: When you try to remove the product by clicking the Trash icon, the product doesn't get removed. Issue 5: When you click Checkout, you encounter the same "internal error. try again". warning. Issue(s) 6: There are so many CSS issues and white spaces problems on the Nexus template and Nexus cart, which require endless customisations to fix. And, now cron has run, and we can't revert the backup and have to figure out another way to revert to previous version. Seriously, how can we rely on whmcs to bill our customers? More issues below: (8) When you activate Nexus Template and Nexus Cart, on Small screens (mobile and tablets), the Navbar becomes Hamburger menu (which is the correct behaviour), but it leaves massive White Space in the Navbar's place. That destroys the look of the product and other pages on whmcs. (9) I activated "Standard Cart" due to the previous issues, but when you add a domain and another product to Standard Cart, the Cart only shows Product and not the domain name. I think the same issue occurs on Nexus Cart too.

This also doesn't work for us. In our country (Thailand) you are only not allowed to change/edit paid invoices. Any other type is no problem. We use the "Edit invoice" option a lot. It would be better if there is a configuration option where we can choose which types of invoice could be edited. Or just make some check boxes in the "admin role" page, so that we can choose which type of invoices can be edited.

Hi, Thanks for reaching out. AI-powered domain suggestions are part of the WHMCS Namespinning lookup providers functionality now: https://docs.whmcs.com/releases/9-0/9-0-release-highlights/ You can switch to another lookup provider if you don't wish to leverage the functionality of the WHMCS Namespinning lookup provider. Please see: https://docs.whmcs.com/8-13/domains/lookup-providers/

Yeah this is a nightmare

@WHMCS John @WHMCS @WHMCS Aimee @WHMCS Alex @WHMCS Andrew @WHMCS Anwar @WHMCS Areeb @WHMCS Arty @WHMCS Carlos @WHMCS Chance Are you guys listening, or is it time for us to migrate to another billing software? Is this how it’s going to be going forward? Please review all the complaints, it’s becoming too complicated to manage our business with WHMCS now. Are you reconsordring restore the previous features.

I think you guys may be dramatically underestimating what AI is capable of, but I suppose we shall see. As for the post being suitable or not, Webpros has done everything in their power to alienate their client base - this type of post is the inevitable consequence of that.

"Luck" isn't really a component here. If you haven't played around with agentic coding I can see why this would seem like a stretch for you, but it's quite trivial to get a fairly simple billing system up and running quite rapidly. And like I said this is with current-level tools, in a year or two, replicating the entirety of WHMCS would likely be very doable.

Also using custom.css for the theme's variables defeats the purpose of custom.css, it's now going to be replaced for every update. v9 screams minimal effort, rushed with no regard for users. If they don't care why should we?

We're pleased to advise that the issue has now been resolved:

I was reading the documentation about the "Order Days Grace" that is located under General Settings > Ordering with the description "The number of days to allow for payment of an order before being overdue." I was wondering if this could be used to, in effect, create Net 30 or Net 15 billing, where the due date is set 30 or 15 days after the order is placed. Based on the documentation, I believe this achieves that. And it appears that the domain grace and redemption period is managed separately under General Settings > Domains. I would like to confirm that: The "Order Days Grace" only applies to product and service invoices, and not domains. That domain grace / redemption periods are managed separately from this setting. All future invoices for renewals also have the same grace period. Also, is there any way to do the following? Only allow approved customers to have a grace period on invoices. My goal is to allow approved vetted customers Net 30 billing for products and services (but NOT domains), while everyone else must pay in advance. Is there any way to set it up like this?

While I understand that bugs are part of any Release Candidate cycle, it's concerning that we are still discussing basic optimization issues like proper OPcache support. And let's not even get started on the fact that we still don't have 100% native Nginx support. This becomes particularly ironic with the introduction of the new WHMCS Cloud Solution. With cloud hosting, the resource costs are on their side, so you'd think they'd be rushing to support Nginx to reduce their own infrastructure expenses. It's like being sold a high-performance engine but being told you have to power it with hamster wheels. Maybe once their bills start rolling in, Nginx support will suddenly become a priority. This all points to the bigger issue: the development velocity. Core development feels like it's just about "keeping the lights on" (PHP/ionCube updates) rather than actual innovation. This stagnation has allowed third-party developers like ModulesGarden to build entire businesses by selling us functionality that should have been in the core a decade ago. When you look at the "Total Cost of Ownership" license fees + necessary third-party modules, the value proposition is slipping. Newer platforms like Upmind are entering the market with an API-first architecture and modern features built-in from day one. If WHMCS continues to outsource innovation to the community while raising prices for maintenance updates, that competitive threat is going to become an exodus very quickly. We need core features that match the modern hosting landscape, not just compatibility patches.

I have already done that. I'm not an idiot.

My screenshot and your first screen shot both state that 8.13.2 are the latest and recommended. Stop trying to boost your post count. You are not adding any value to this topic.