WHMCS.Community

Hi all, The domain checker code provided under Utilities > Integration Code doesn’t work when added to an external page. This has been the case for a few WHMCS versions now. Could someone from WHMCS look into this? If the code needs updating, please update it in the admin area too, as people will understandably expect the supplied code to work. Has anyone else run into this or found a fix? Thanks, Jack

Owned License ($30.00) - https://www.hardsoftcode.com/cart/link/stoat-notifications-for-whmcs/owned Source Code License ($200.00) - https://www.hardsoftcode.com/cart/link/stoat-notifications-for-whmcs/source

Hi all, Since moving from the legacy Stripe module to Stripe Dynamic Payments (WHMCS 9.1.x), we see payments recorded 0.01 short (or over) when the invoice currency differs from the Stripe account’s settlement currency. Short payments leave the invoice Unpaid with a 0.01 balance, even though Stripe charged the customer the full amount. Setup WHMCS default/client currency: USD Stripe account settlement currency: EUR Convert To For Processing: None, so Stripe charges the customer in USD What happens Stripe charges the exact invoice amount in USD and converts it to EUR for the balance. Stripe Dynamic Payments then seems to take the EUR balance amount and convert it back with Stripe’s exchange rate, instead of recording the amount that was actually charged. Illustrative example: Invoice: USD 19.99, and Stripe charges USD 19.99 ✔ Balance transaction: EUR 18.26 (rate 0.9137) WHMCS records 18.26 / 0.9137 = 19.9847 → USD 19.98 Invoice stays Unpaid, balance 0.01 The fee is converted back the same way, which is fine. The payment amount should not be. How often The EUR amount is rounded to cents and then converted back, so roughly 1 in 10 payments is off by a cent whenever the exchange rate is below 1 (e.g. USD → EUR). About half of those underpay, leaving the invoice Unpaid. The other half overpay, adding 0.01 credit to the client. When the rate is above 1 (e.g. GBP → EUR), the error can’t reach a full cent. Legacy module did not do this With the same Stripe account and the same setup, the legacy Stripe module recorded hundreds of USD/GBP payments to the exact cent. With Stripe Dynamic Payments, our very first USD payment was already off, so this looks like a regression in the new module. Workarounds considered Manually adding a 0.01 payment: works, but it’s manual and easy to miss. Unpaid invoices also trigger reminders and overdue processing. Convert To For Processing = settlement currency: not a real option for us. It charges USD customers in EUR, so their bank converts the amount and often adds fees. The amount on their statement then no longer matches the invoice. WHMCS would also still have to convert the EUR payment back to the invoice currency, so the rounding issue might simply move. Adding a USD settlement account in Stripe would avoid the conversion entirely, but not everyone can or wants to do that. I’ve opened a support ticket with WHMCS but don't expect a fix anytime soon. Has anyone else run into this with Stripe Dynamic Payments? Does anyone have a better workaround, or know whether a fix is planned? Thanks!

Hi everyone, I’m sharing the current lineup of WHMCS modules from HardSoftCode. They’re built for speed, security and easy day-to-day administration. Utilities Pages Manager ($65): build unlimited rich-content pages in the client area, including internal, PHP and standalone pages and reusable blocks. Advanced SEO Manager ($40): control meta tags, Open Graph, Twitter Cards, canonical URLs and schema.org data. Menu Manager ($40): manage the client area menus for both visitors and logged-in clients. Support Tools Support PIN Pro ($45): clients generate temporary numeric PINs so your team can verify identity by phone or chat. Staff Chat ($45): real-time chat inside the WHMCS admin area, with file sharing, mentions and search. Performance & Security Change User Password ($30): brings back the admin’s ability to change a user’s password in WHMCS 8, with every action logged. Delete/Close Account ($40): lets clients request account closure with password confirmation, optional captcha and email verification, and a grace period. Notifications Stoat Notifications ($30): connects the native WHMCS notification system to your Stoat workspace. Other Magic Login Link ($40): passwordless client login through a secure, time-limited link. Browse everything here: https://www.hardsoftcode.com/products I’d love your feedback. Which features are you missing in WHMCS? Reply with your ideas and I’ll consider them for future modules.

Stoat Notifications for WHMCS connects the native WHMCS notification system to your Stoat workspace. Once installed, Stoat appears as a notification provider next to the built-in options. You create a notification rule, select Stoat, and WHMCS posts each matching event into the Stoat channel of your choice through a webhook. Stoat renders Markdown on the client side, so messages arrive formatted, with bold titles, linked headings, tidy attribute lists and colour-coded embeds, instead of a block of plain text. The module is built for teams that live in Stoat and want billing, support and system events in front of them without watching email or refreshing the admin area. A paid invoice, a new order, a support ticket or a failed payment can each go to a different channel with its own format, colour and sender identity. You can send a full message with an embed, a compact Markdown-only message, or an embed-only card, and choose per rule whether attributes such as client, invoice, service and department are included, shown one per line, or collapsed into a single inline row. Silent messages let low-priority events appear in the channel without pinging anyone. Setup is deliberately simple. There are no database changes and no addon activation step. Copy the Stoat folder into modules/notifications/, paste the webhook URL from your Stoat channel settings, and save. WHMCS immediately posts a connection test, and the test is always strict, so a missing SendMessages, SendEmbeds or Masquerade permission shows up while you configure the provider rather than the first time a real invoice is paid. Provider settings and notification rules are stored by WHMCS, so upgrades are as easy as replacing the folder and saving the configuration once. Reliability and security are treated as core features. Every webhook URL is validated before each request: HTTPS only, no embedded credentials, no query string or fragment, a correct webhook path, and a host limited to stoat.chat or *.stoat.chat unless you enable self-hosted mode. TLS is verified, redirects are not followed, and the webhook token is redacted from module log entries. Content, embed titles, descriptions and sender names are checked against Stoat's limits before sending, with Markdown-aware truncation that closes unfinished code blocks. Mentions such as @everyone, @here and @online are neutralised, so notification text can never ping an entire server. When Stoat rejects an optional feature, you decide the behaviour: fail loudly with Strict Delivery, or retry once without the rejected embed or masquerade. Stoat error types are mapped to clear, actionable messages, covering missing permissions, invalid tokens, slowmode and more. If you are moving from the Guilded notification module, the transition is easy. Decimal embed colours are converted to hex automatically, and attributes that Stoat embeds can't hold as separate fields are folded into the embed description as Markdown. Self-hosted Stoat instances are supported, and a full eight-page documentation site covers installation, permissions, settings, message formats, worked examples, security and troubleshooting. The Problem It Solves WHMCS events like new orders, paid invoices, support tickets and failed payments are easy to miss when they only land in email or the admin area. Teams that already work in Stoat have to check a second place, and generic webhook workarounds usually send plain, unformatted text that is hard to scan, can't be routed per event, and often leaves webhook URLs exposed in logs. What the Module Provides Stoat Notifications for WHMCS adds Stoat as a native provider in the WHMCS notification system. Create a notification rule, choose Stoat, and WHMCS posts formatted messages straight into your Stoat channel through a webhook. Each rule can use its own channel, format and colour, so billing, support and system alerts can go where they belong. There are no database changes and no addon activation. Copy the folder, paste your webhook URL, and save. Features Message delivery Three formats: Message + Embed (default), Message only, or Embed only Markdown rendering for titles, messages, and attribute labels and values Rich embeds with title, description, link and custom colour Optional silent messages that don't ping the channel Attributes (client, invoice, service, department and so on) shown as separate lines or on one inline row Routing and appearance Per-rule webhook override to send each rule to a different channel Optional custom sender name and avatar through Stoat masquerade Per-rule embed colour, with Guilded-style decimal colours converted to hex automatically Reliability Strict Delivery toggle: fail on a rejected feature, or retry once without it Embed-only notifications never degrade to an empty message Connection test on save, so missing permissions show up during setup Markdown-aware truncation that closes unfinished code blocks Configurable request timeout (1-30 seconds) Actionable error messages for Stoat errors such as missing permissions, invalid tokens and slowmode Security HTTPS only, with TLS verification and no redirect following Strict webhook URL validation before every request Host restricted to stoat.chat unless self-hosted mode is enabled Webhook token redacted from module logs @everyone, @here and @online mentions neutralised in notification text

Update error Error: WHMCS\Installer\Update\Updater->performFileUpdate() at /home/user/domains/domain.com/public_html/domain/admin/update.php:0 WHMCS\Installer\Composer\ComposerUpdate->update() at /vendor/whmcs/whmcs-foundation/lib/Installer/Update/Updater.php:0 WHMCS\Installer\Composer\ComposerUpdate->doComposerCommand() at /home/user/domains/domain.com/public_html/domain.com/vendor/whmcs/whmcs-foundation/lib/Installer/Composer/ComposerUpdate.php:0 WHMCS\Installer\Composer\ComposerUpdate->{closure:WHMCS\Installer\Composer\ComposerUpdate::update():586}() at more......  

Hi Huzaifa, welcome to the WHMCS Community! Glad you joined us!

Thank you!  This absolutely helped me.  Had the exact same issue.  Also after the upgrade, and returning to php 8.4 I ran the WHMCS internal scan for php 8.4 compatibility and it came back all green, so maybe we're okay for the next update. Really appreciate you taking the time to post this.

Though I appreciate the response, I also could have asked AI and copy/pasted the entire thing. All all of your replies I checked appear to be 100% AI generated, please don't bother replying to my posts, if possible. 

Hi everyone, We're planning to offer S3-compatible object storage services using our own Ceph RGW backend, with WHMCS handling customer management, provisioning, and billing. We're looking for an existing WHMCS integration module (official or third-party) that supports: Automatic provisioning of Ceph RGW S3 accounts Access key and secret key management Bucket and storage quota management Storage usage metering and billing Service suspension and termination We've searched the WHMCS Marketplace and Community community but haven't found a module specifically supporting Ceph RGW. Does anyone know of an existing module, or have experience integrating WHMCS with Ceph RGW? We're hoping to avoid developing a custom module from scratch. Any recommendations would be greatly appreciated. Thanks!