All Activity

@pixelweb001 The original email where sent, if possible PM me your email you use with us so I can check if it was on the list

It works, but not with the app talking to WHMCS directly. Plan on a small backend in the middle, even if everything else is no-code. The WHMCS API authenticates with admin-level API credentials. Those can act on any client account, so they must never ship inside a mobile app, where anyone can extract them. A lot of no-code builders will happily let you paste credentials into an API connector, and that's the trap to avoid. Have the app call your own small service (a serverless function, or a little PHP or Node endpoint), keep the API credentials only there, and lock them to that server's IP with the API IP restriction setting. For login, WHMCS can act as an OpenID Connect provider (Configuration > System Settings > OpenID Connect). If the builder supports a generic OAuth2/OIDC login, clients sign in with their existing WHMCS account, and your backend maps the verified login to their client ID. That way a client can only ever see their own services and tickets, because the backend takes the client ID from the login, never from whatever the app sends. For the features you mentioned, the backend calls GetClientsProducts for account and service status, GetInvoices for billing, and OpenTicket / GetTickets for support. For payments I wouldn't build checkout into the app at all. Have the backend call CreateSsoToken and open the invoice or billing page of the WHMCS client area in a browser view. The tokens are single-use and valid for at most 60 seconds, so generate one when the user taps, not in advance. Your existing gateway, 3D Secure and fraud checks keep working, and you don't drag card handling into the app. Before committing to a builder, I'd check four things: Custom OAuth2/OIDC login, not only its own user system or social logins. Calling your own REST endpoints with a bearer token in the header. Opening a URL in an in-app or external browser. Whether you can host or export the backend logic yourself. If it fails the first two, it will fight you later. Honestly, for a new hosting business I'd start with a mobile-friendly client area theme and add a native app once clients actually ask for one. Most of what they need day to day (pay an invoice, open a ticket, check a service) already works in the client area on a phone.

@Nathan Davis The cancelled original stays out of the paid sequence entirely. With Sequential Paid Invoice Numbering on, an invoice only takes a number from that sequence at the moment it's paid. Until then it's a proforma, identified by its internal invoice ID. So the one you cancel never uses up a paid number, and the replacement picks up the next number when the client pays it. Nothing gets skipped. For reconciliation that leaves you with two different references: The invoice ID (the one in the URL). The cancelled original and the replacement each have their own, and the IDs will drift away from the paid numbers over time. That's normal. The paid invoice number. Only the replacement gets one, once it's paid. If your accountant works off the paid sequence, the cancelled original simply never appears there, and the "Replaces invoice #" note ties the two together for the client and for anyone searching later. One case behaves differently: if you cancel or refund an invoice that was already paid, it keeps the paid number it was given, so the sequence still has no gap. It's worth checking how your invoice template labels those, because some older custom templates print "Proforma" for anything that isn't marked Paid.

@HSc I'd lean toward product addons rather than configurable options for this, mainly because of your three requirements. Configurable options fold into the product's price as one line item and share its billing cycle. The types are Dropdown, Radio, Yes/No and Quantity. None of them is free text, so you can't store a mailbox address in one. That's likely why hiding them still felt wrong. You'd need a separate custom field on the product, and one option doesn't map well to "several mailboxes, each upgraded differently." Addons are billed as separate items, and they cover all three of your needs: 1. Create a Recurring addon. For sizes, either make one addon per tier (1GB, 2GB, 5GB), or one addon priced per 1GB with Allow Multiple Quantities turned on, so quantity equals GB. Separate tiers are easier for clients to read. The quantity route is simpler if your pricing is linear. 2. Turn on Prorata Billing for the addon. It syncs the addon's due date to the parent service, using the parent's prorata settings. That gives you the yearly anniversary alignment. 3. Add a required text Custom Field to the addon, something like "Mailbox address". Each purchase then names the mailbox it applies to. 4. Assign the addon to your email product. Clients can order it under Available Addons, or staff can add it. Do one addon instance per mailbox upgrade. One caveat, since you're not on cPanel: WHMCS won't resize anything on its own. Your module or manual process has to read the addon's custom field and apply the quota. If you have a provisioning module, check whether it handles addon events. Otherwise you'll need a small hook or a staff task. Test the prorata date on a dummy service before going live, so you can confirm the due dates land where you expect. What are you using on the mail side to set quotas?

With the release of WHMCS 9.1.0, we're pleased to announce that all our WHMCS themes, client area templates, admin themes, and order forms have been updated and are now compatible with the latest WHMCS version. Our latest releases also include PHP 8.4 and ionCube Loader 15 support, along with various improvements, bug fixes, and UI enhancements. Updated Themes & Templates HostX – v3.1.2 https://whmcsglobalservices.com/web-hosting-themes-templates/hostx/ CloudX – v1.1.2 https://whmcsglobalservices.com/web-hosting-themes-templates/cloudx/ ClientX – v3.3.3 https://whmcsglobalservices.com/clientarea-template/clientx/ TwentyX – v1.3.4 https://whmcsglobalservices.com/clientarea-template/twentyx/ AdminX – v1.1.3 https://whmcsglobalservices.com/web-hosting-admin-themes-templates/whmcs-adminx/ Updated Order Forms One Step Checkout (OPC) – v2.5.4 https://whmcsglobalservices.com/custom-template/one-step-checkout-whmcs-orderform-template/ VueJS WHMCS One Step Checkout – v2.4.1 https://whmcsglobalservices.com/custom-template/vue-one-step-checkout-orderform/ What's Included? Full compatibility with WHMCS 9.1.0. Support for PHP 8.4 and ionCube Loader 15. Updated language files following WHMCS 9.x naming conventions. Improved mobile responsiveness across themes and order forms. Various bug fixes, stability improvements, and compatibility enhancements. Demo: http://demo.whmcsglobalservices.com/ We recommend all existing customers update to the latest versions to ensure smooth operation with WHMCS 9.1.0. Have questions or need assistance with the updates? Feel free to reach out to our support team.

Yes I'm on 9.1.0. Happy to provide details here. Ask away. Recent tickets (over the past 12 months) result in copy/paate replies stating that yes we are aware and it will fixed but no timeline is available. Request to escalate have been met with, no that's not possible.

An update on this topic:

Hi everyone, We have listened to feedback from the community and from our customers, and we are extending the end of life for WHMCS 8.13 from December 31, 2026 to January 31, 2027. December is a busy month for most of you, with year-end closing, code freezes and the holidays. Moving from 8.13 to 9.x is a major upgrade, and it deserves proper time to plan and test. The extra month gives you that window in January. 8.13 continues to receive security fixes until January 31, 2027. After that date your installation keeps working, but we will not release any further patches for it. WHMCS 9.1 is available now and is the version to upgrade to. Before you upgrade, back up your files and database, check your PHP version and module compatibility, and test key workflows on a staging copy. PHP 8.2 reaches its own end of life on December 31, 2026. WHMCS 9.1 supports PHP 8.2, 8.3 and 8.4, so this is a good time to move to a newer PHP version too. Update to WHMCS 9.1 before you move to PHP 8.4. The docs are being updated with the new date, and all customers in 8.13.x will receive an email confirming it.

@Damo so you are on 9.1.0, the permission is enabled, and the option still doesn't show? That shouldn't happen. Please open a support ticket so the team can look at your setup

Access is enabled. As for timing, if it's a critical security related issue then it should be patched immediately. This auto update feature is seemingly becoming more an automated tool to roll out 'features' than critical updates.

@Damo The schedule is there because many admins need updates to land in a set window, for example outside business hours or after their backups run. Set it to weekly and the gap is at most a week. When a critical security release comes out, you don't have to wait for the schedule: you can apply it straight away from Utilities > Update WHMCS.

@Damo the option is there .. please check your admin user has the permissions set for it

https://docs.whmcs.com/releases/9-1/9-1-release-highlights/#unattended-automatic-updates If you can schedule these security updates then how does that avoid something exploitable? eg. You're updates are set to the 28th of each month but the exploit is published on the 3rd. FAIL!

Yes. 9.1.0. I'm also curious to know your thoughts on what constitutes 'minor improvements' that can be applied automatically.

Are you sure you're on 9.1? https://docs.whmcs.com/releases/9-1/9-1-release-highlights/#unattended-automatic-updates

@Damo if it's every device, every browser and every admin, I'd stop looking at browser settings and check whether the cookie is actually being set and kept. This is what I'd go through: 1. Watch the login in DevTools. Open the admin login page in Chrome, press F12, go to the Network tab, tick Remember Me and log in. Click the login request and look at the Set-Cookie lines in the response headers. If Chrome rejected one, there's a small warning icon next to it, and hovering over it tells you why (Secure flag on a non-HTTPS request, SameSite, domain mismatch and so on). Then open Application, Cookies for your WHMCS host and see whether the cookie is there and what expiry it has. A cookie that shows "Session" in the Expires column instead of a future date would explain the repeated logins exactly. 2. Compare the System URL with the address your admins actually type. Under Configuration, System Settings, General Settings, the WHMCS System URL should match the scheme and host exactly (https, and www or no www). A mismatch there is one of the most common reasons login and dismiss cookies don't stick. 3. Look at anything sitting between the browser and PHP. A Cloudflare cache rule or a caching proxy that caches admin responses can drop or reuse Set-Cookie headers, and server-side hardening (an Apache Header edit rule on Set-Cookie, nginx proxy_cookie_path or proxy_cookie_flags, a WAF rule) can rewrite them. Since your other app on the same domain is fine, check whether a rule like that only matches the WHMCS path, or was added around the time you upgraded. 4. If admins also get thrown out in the middle of working, check the PHP side too: session.gc_maxlifetime for the PHP version WHMCS actually runs on, and whether anything cleans the session save path more aggressively than that. On cPanel servers each ea-php version has its own php.ini, so the value you checked may not be the one WHMCS is using. If step 1 shows the cookie arriving with a sensible expiry and then vanishing, or not being sent at all on 9.1 when it was before, that's worth a ticket with WHMCS. Attach the response headers from the login request, with the cookie values blanked out.

This is still happening. Multiple devices, multiple admin users, multiple browsers. Are there any tools or suggestions on how to track down the cause? It only started with this release. Cookies and sessions for another app on the same domain as our WHMCS continue to work without issue.

@DennisHermannsen it is the small improvements that are of concern. The definition leaves it very open. e.g. a small improvement could be something that improves WHMCS tracking and data sharing or a change to the colour of a label so that it's easier to read.

I don't see any option to disable this feature.

I'm setting up a small hosting business and picked WHMCS as the billing side, mainly because I want client accounts and invoices handled in one place. Separately, I've been looking at no-code and AI mobile app builders for a customer-facing app, since I don't have a development background. The thing I keep going back and forth on is how the two would actually fit together. I understand WHMCS has an API, but I'm unsure whether a builder-generated app can call it reliably for things like checking account status or submitting a support ticket, or whether that requires custom work beyond what a no-code tool offers. I'm also wary of picking a builder now and finding it can't handle authentication or payments later. Has anyone connected a WHMCS install to an app built on one of these platforms, and what should I check before committing to one?

The distinction between the open-source code discount and the plan discounts is worth noting — the 50% tier only applies to source code, not to the hosted modules or themes, from what's described. Anyone comparing yearly costs should probably check whether the annual code beats the monthly plus FESTIVE20 route for their specific product. Also useful to confirm licensing terms per item before checkout, since the post mentions product pages vary. Curious whether the One Step Checkout and the Passkey module fall under the same coupon eligibility.

The note on the new invoice is the part I hadn't thought about — putting "Replaces invoice #1234" in the Notes field so it shows on the invoice itself seems like the simplest way to head off the tickets. On the numbering question, if Sequential Paid Invoice Numbering is on, does the cancelled original keep whatever ID it already had assigned, or does it stay out of the paid sequence entirely until it's paid? I'm trying to picture how that looks when reconciling later. Also good call on re-checking the draft line items are still tied to the service before publishing.

@WHMCS Carlos I am also wondering whether an official email announcement will be sent regarding the EOL of version 8.13. When I checked the documentation and saw the updated T.B.D. date, I initially thought it was a typo. Again, I would have really appreciated receiving at least 90 days' notice, especially with the upcoming holiday season.

https://marketplace.whmcs.com/product/9186-extended-invoice-manager I am using this addon

this issues already been sorted by updating WHMCS to verions 9.1.0 and with plesk updated to version 18.0.82 Update #2