BENELUX

Here is the procedure we followed to replace the `vendor` folder. 1. Renamed the Existing Folder We renamed the current messy `vendor` directory to separate it from the live site without deleting data. mv vendor vendor_old 2. Deployed the Fresh Folder We extracted the clean `vendor` directory from the **WHMCS v9.0 Full Release** zip file and placed it in the root directory. unzip -q whmcs_v901_full.zip "whmcs/vendor/*" mv whmcs/vendor ./ rm -rf whmcs *(If you did this via FTP, you simply uploaded the fresh `vendor` folder to `public_html/`)* 3. Safety Retention Do not delete `vendor_old` yet. Keep this folder on the server for several weeks. If any custom modules or hidden dependencies break in the new environment, we can reference or restore files from this backup. Once the system is confirmed stable after a few billing cycles, you can remove it.

As long‑time WHMCS users running production hosting environments, we are increasingly concerned that WHMCS is drifting away from the real‑world needs of modern providers. Recent changes in 9.0 have exposed serious weaknesses not only in the financial engine, but also in the underlying technical architecture. The points below are not “nice to have” feature requests, they are fundamental requirements for any billing and automation platform that claims to be suitable for professional hosting companies in 2026. This is not about squeezing more revenue out of the existing user base to please investors, it is about delivering a product that is technically and financially solid enough to justify its price. 1. Financial & Reporting Integrity in 9.0 The new credit/debit note system in WHMCS 9.0 has introduced critical issues that make the financial data untrustworthy for real‑world operations: - Late fees are being treated as “Amount Out” (expense) in reports, even though they are actually additional income. - Cancelled invoices can appear as income for the day, despite no payment being made. - When a client adds credit and then uses that credit to pay an invoice, WHMCS counts both the credit addition and the invoice payment as income, even though it is the same money. For any company that needs reliable cash‑flow and revenue reporting for accountants, auditors, or tax authorities, this is a show‑stopper. A billing system where income/expense classification and basic cashflow are wrong cannot be considered production‑ready, regardless of how many UI tweaks or new themes are shipped on top. 2. Missing Modern Infrastructure Support (Technical Must‑Haves) In 2026, a hosting/billing platform that wants to be taken seriously must natively support modern web stacks and performance patterns. WHMCS is still heavily tied to an old‑fashioned Apache/mod_php‑style deployment model and largely ignores how providers actually scale PHP apps today: - No first‑class Nginx support: no official, up‑to‑date Nginx configurations, rewrites, security hardening, or best‑practice deployment guides. - No built‑in awareness of PHP OPcache: no guidance around optimal configuration, cache warmup, or avoiding stale‑code issues during updates and cron execution. - No native support for Redis/Memcached for sessions and application caching: WHMCS still assumes legacy PHP session storage and database‑driven patterns instead of modern, distributed caches. - No support for full‑page caching layers (such as Varnish or Nginx fastcgi_cache): no cache‑invalidation hooks, no official cache‑header strategy, and no clear statement of what can safely be cached and where it must be bypassed. For a billing/control application that often sits at the center of a hosting provider’s stack, this is a major architectural gap. Providers are forced to run WHMCS as a “special snowflake” on outdated PHP hosting patterns, while the rest of their infrastructure is containerized, horizontally scalable, cache‑aware, and built around Nginx and Redis by default. 3. Pricing, Investors and Misaligned Priorities Over the last years, WHMCS has significantly increased prices and tightened client‑based tiers. For many small and mid‑sized providers, license costs now consume a noticeable percentage of monthly revenue, especially when factoring in required third‑party modules to fill functional gaps. The problem is not just the higher price. The problem is what we are (not) getting in return: - Core billing logic that fails to represent real cashflow correctly. - Lack of native support for modern infrastructure (Nginx, Redis, full‑page caching). - Ongoing dependence on paid third‑party modules for things that should be core in a product at this price level. From the outside, it feels like the priority has shifted towards making investors and the holding company happier by pushing ARPU up, instead of investing deeply in stability, compliance, and technical modernization. Hosting providers are being asked to pay more for a platform that, in several critical areas, is standing still or even regressing. If WHMCS is going to charge premium pricing, it must deliver a premium‑grade product: technically modern, financially robust, and compliant in real‑world scenarios. 4. What Hosting Providers Need From WHMCS If WHMCS wants to remain relevant for professional hosting companies, the following should be treated as non‑negotiable priorities: 1. A fully audited, correct financial engine - Credit and debit notes that do not break basic accounting logic. - Accurate cash‑flow and revenue reporting that can be trusted by accountants and tax authorities. - Clear separation and correct handling of invoices, credit notes, cancellations, add‑funds and overpayments. 2. Native support for modern infrastructure - First‑class, documented support for Nginx, including recommended configurations and security best practices. - Built‑in support for Redis/Memcached for sessions and caching. - Official guidance and hooks for PHP OPcache management and safe deployment. - A clear, supported pattern for full‑page caching (Varnish / Nginx cache), including proper cache‑invalidation and headers. 3. Roadmap and communication aligned with operators, not just investors - Focus on fixing structural problems in billing, reporting and architecture before adding cosmetic features. - Transparent communication about critical bugs and security issues, not silent updates. - A pricing model that reflects the actual value delivered and acknowledges that many customers are small and mid‑sized providers, not just large enterprises.

Stepping back from this specific issue, it does feel like a broader pattern within WHMCS rather than an isolated problem with NexusCart. I do not have insight into WHMCS internal development processes, and this is not intended as criticism of individual contributors, but from a customer and integrator perspective the overall direction can be difficult to follow. Over recent releases, we have seen recurring regressions, incomplete fixes, and features that appear to ship without being fully validated across real world installations. When combined with limited transparency around known issues or roadmaps, it creates the impression of fragmented development and weak internal communication. WHMCS is a mission critical platform for many businesses, so stability, predictable releases, and timely fixes are just as important as new features. At times it feels like significant bugs or long requested improvements are either delayed for extended periods or quietly deprioritized, which makes long term planning and confidence in upgrades challenging.

We have identified that this behavior was introduced by a recent update from the theme builder. We are currently investigating it further, but at this point it does not appear to be a WHMCS core issue. The Refresh header seems to be injected at the theme level rather than by WHMCS itself.

Hi everyone, We recently ran into an SEO / Google Search Console issue on a WHMCS installation and wanted to share our findings and ask how others are handling this. What we observed WHMCS CMS/content pages (for example custom CMS slugs and the default /contact page) consistently return the following headers: HTTP/2 200 OK Refresh: 0 This happens on CMS and content routes, while transactional routes such as login.php or cart.php correctly return 301/302 responses with a Location header. Why this is a problem Modern search engines (Google in particular) treat a 200 OK response combined with a Refresh header as a soft redirect. In Google Search Console this results in: “Redirect error” during URL inspection Pages not being crawled or indexed Canonical URL not being determined From the browser’s point of view everything works fine, but for crawlers these pages effectively never get indexed. What we verified To rule out common causes: The issue occurs inside the WHMCS request flow, not at the webserver level. No custom hooks or addons are setting this header. The theme does not inject HTTP headers. A plain PHP test file outside WHMCS does not return a Refresh header. Removing the Refresh header at the webserver level immediately resolves indexing issues. This strongly suggests the header is part of WHMCS core behavior for CMS/content pages, likely as a legacy fallback mechanism. Current workaround The only reliable workaround we found is stripping the header at the webserver level, for example in NGINX: fastcgi_hide_header Refresh; This: Restores proper Google crawling and indexing Does not appear to cause functional side effects Does not require modifying WHMCS core files Questions for the community Is this Refresh: 0 behavior on CMS/content pages expected? Are others seeing the same Google indexing issues? Is there an official or supported way within WHMCS to disable this behavior? Has anyone found a cleaner solution than stripping the header at the webserver level? It would be great to hear how others are dealing with this, especially on sites where WHMCS CMS pages are used for marketing content. Thanks in advance for any insights 🙂

Thanks for the update @WHMCS John. It is reassuring to hear that a fix for the critical reporting and late fee bugs (WHMCS-24931, 24949, 24950) is arriving this week with v9.0.1. The shift to accrual accounting is clearly a massive undertaking, but accurate cash flow reporting is non-negotiable for us to operate. While we are discussing high-priority fixes for this release window, could you please confirm if WHMCS-24661 (M365 Shared Mailbox import issues) is also slated for resolution in 9.0.1 or 9.1? This issue is currently preventing us from properly importing/finding shared mailboxes via the Microsoft 365 integration, which is a critical part of our support workflow. Like the financial reporting bugs, this is hindering daily operations. We appreciate the transparency on the roadmap for 9.1, but getting these functional defects resolved in the immediate hotfix would be a huge relief. Looking forward to the release notes 🙂

Hi all, WHMCS 9.0 is now in General Availability (Jan 20, 2026), but the planned Peppol BIS Billing 3.0 e-invoicing add-on remains "coming soon" with no ETA. For those of us operating in Belgium, this is now a critical compliance blocker. The Issue: Belgium mandated B2B structured e-invoicing via the Peppol network effective 1 January 2026. Invoices can no longer be issued in traditional formats, they must be exchanged through Peppol. We cannot delay invoicing any further while waiting for WHMCS native support. Previous Guidance: WHMCS Technical Analyst stated in mid-December: "The e-invoicing functionality will be released as an addon that will be available shortly after v9.0 GA (in January)." Now that v9.0 GA has shipped, this guidance appears to have shifted to "coming soon" with no timeline??? Questions for the WHMCS Team: 1. Is the January add-on still planned, and will it include Peppol BIS Billing 3.0? 2. If not, what interim WHMCS-recommended solution should we use to issue compliant invoices immediately? For others in the same situation: If you have found a working interim solution or Marketplace module that handles Peppol BIS Billing 3.0 invoicing within WHMCS, please share your experience below. Thanks

Hi @SVCode I received a follow-up from WHMCS Support regarding this issue. They have confirmed that the `prompt=consent` parameter is the culprit preventing connections. They provided me with a modified `MicrosoftAuthProvider.php` file that removes this parameter, and I can confirm this fixes the issue for us permanently on WHMCS 8.13.1. Just to clarify on the workaround mentioned earlier: we did not copy the URL to a new tab (which likely breaks the session/state); we simply edited the URL directly in the current browser tab to remove `&prompt=consent` and hit enter. However, for a permanent fix without manual URL editing, you will need the patched file. Since the file is IonCube encoded, you cannot easily edit it yourself. The Solution:
I recommend opening a ticket with WHMCS support and referencing case WHMCS-24661. They should be able to provide you with the same 'MicrosoftAuthProvider.php' patch for version 8.13.1 that they sent me. Once you have the file: 1. Backup your original /vendor/whmcs/whmcs-foundation/lib/Mail/Incoming/Provider/MicrosoftAuthProvider.php 2. Upload the patched file to the same location. 3. Re-authenticate your department using the Microsoft 365 licensed user. Hope this helps you get yours connected! MicrosoftAuthProvider.php

Could you please let us know if there is an estimated timeline for the WHMCS 9.0 stable release?

UPDATE: We got it working! For anyone else hitting the “Approval Required” wall when trying to connect a standard (licensed) Exchange user, we found the culprit. We managed to solve this, but it required two specific changes due to how WHMCS is hardcoded. 1. The "Shared Mailbox" had to become a "Licensed User" Because WHMCS hardcodes the Graph API call, it is technically impossible to access a Shared Mailbox via a delegate admin account. * The Fix: We converted the Shared Mailbox to a regular User Mailbox and added an Exchange Online license. This ensures that when we authenticate as that user, correctly refers to the support mailbox. 2. We had to strip `prompt=consent` manually Once we switched to a standard licensed user (non-admin), we hit the "Approval Required" wall during OAuth. * The Cause: WHMCS appends `&prompt=consent` to the auth URL, which forces a new consent prompt that standard users cannot accept (due to our Azure security policies). * The Workaround: By manually removing this parameter from the URL in the browser, Microsoft respected the Tenant-Wide Admin Consent we had already granted, and the connection went through immediately. Summary: If you are struggling with this, you cannot use a true Shared Mailbox with WHMCS right now. You must license it as a user and clean up the Auth URL to get it connected. Hope this saves someone else the debug time! ☕️

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.

For the BETA

Do you have an exact ETA?

Is there any update on when a beta or release candidate for version 9.0 will be available? Should we expect it within the next few days or rather in the coming weeks?

Could you share when we can expect a beta or any early build of 9.0? Having access to a test version would help us prepare and ensure everything is ready once Peppol support is officially released. Any update on the planned release timeline would be appreciated. Thanks!

We’re going to go ahead and grab an Exchange Online license ourselves to get it working for now. Hopefully, WHMCS will notice shared mailboxes exist in the universe and improve native support ASAP.

Hey WHMCS Community So here’s the thing… I love WHMCS. It’s great. But right now, it has a little “quirk” when it comes to shared mailboxes. Imagine this: I’ve got my main mailbox doing its thing, happily bringing in emails. But then there’s the shared mailbox, the one that all the support team emails go to. WHMCS? It sees it… but then pretends it doesn’t exist. 😅 Here’s the geeky version: WHMCS currently uses /me/messages from Microsoft Graph API. This only fetches emails from the authenticated user’s mailbox. Shared mailbox? Nope, invisible. Even if Full Access is granted in Exchange and you’ve got all the delegated permissions like Mail.Read.Shared, WHMCS is like, “I don’t see anything here. Must be Monday.” The right way (according to Microsoft Graph) is: GET https://graph.microsoft.com/v1.0/users/{shared-mailbox}/mailFolders/inbox/messages Yes, WHMCS, that mailbox does exist, and yes, I do have permission to read it. What I’m asking: Can WHMCS please natively support shared mailbox imports? Guidance on exactly which delegated permissions are needed (so I don’t go on a wild goose chase for nothing). Support for the correct Graph API endpoint. Bonus points: documentation for optional PHP session settings for cross-site OAuth flows (because apparently, cookies are shy and need proper settings to stick around). Expected outcome: Fetch emails from shared mailboxes without needing a license for it. Less headache, more sanity. WHMCS behaving like the email superhero it’s meant to be. Anyone else banging their head on the “shared mailbox wall”? Let’s commiserate, share workarounds, and maybe get WHMCS to notice that shared mailboxes exist in the universe. Thanks!