WHMCS Dan

This indicates the account has already been created which is why you are getting an error - you're trying to create a duplicate cPanel account in WHM. To resolve this I'd suggest simply setting the service to 'Active' in WHMCS - you can do this by clicking 'Shared Hosting' from the order view > change status > save changes. Hope this helps 🙂

The due date is the start of the next period/cycle for the product, you can however adjust when the invoice is raised in your settings which may help here to raise the invoice earlier. We have further details on this in our docs here: https://docs.whmcs.com/Invoicing_Setup#Automatic_Invoice_Generation https://docs.whmcs.com/Billing_Logic

Usually the bank/payment processors do not provide a detailed reason for why a payment is rejected. The best place to check is your card issuer which should be able to provide details if it is your card, for a customer card you could try checking your payment gateway provider who may be able to provide further details - such as if the response code was "insufficient funds" or something else.

Hello, This sounds like an issue with the database schema, you can check and compare this with the .schema.sql files in /resources/sql/install If you'd like us to take a look, please feel free to raise a ticket with your WHMCS & cPanel login and we can check this further.

We have a guide on changing the default currency here: https://help.whmcs.com/m/payments/l/1122770-changing-the-default-currency HOWEVER, this is strong discouraged because it will break all existing transactions, invoices, credit balances etc because customers currently set to Peso will be changed to USD but the amounts won't be converted. You may be able to overcome this by changing the default currency, then using a database query to switch all customers over to the secondary peso currency ID in the database, this isn't however supported so you should test this in a development install first and throughly check that everything is set correctly and working before making any changes to your live install and ensure you have a backup in case you need to restore. I would also recommend ensuring maintenance mode is enabled prior to making changes to avoid any transactions during the process.

If the piping is working for some users but not others this may be something we need to debug further directly - if you're still stuck with this please feel free to raise a support ticket and one of the team can take a look and debug this further. 🙂

It sounds like what you're looking for here is a Third Party Gateway. We have details on how to create these modules in the developer docs here: https://developers.whmcs.com/payment-gateways/third-party-gateway/

Hello, Are you seeing a bounce back message when you reply? Do you see any log of the email in the ticket import log?

The only solution I'm aware of for this is the method you mention, setting them as hidden html fields in the template and pre-filled with a default value which should allow you to collect minimum information to create the account.

Hi @Kian I have been able to replicate this behaviour, and it does look like it would make sense for the ClientEdit hook to be fired when using the Tax Exempt shortcut link. I have now raised case #CORE-15138 for our developers to review this for future versions.

Thanks for raising this issue, I'm going to investigate this now and will update the thread shortly.

Hello, There are ways to adjust the settings to resolve these issues, I'm just trying to check the details to help debug this further. If this is only happening in Google Chrome and works fine on other browsers, it can usually be resolved by disabling "SameSite by default cookies" flag in Google Chrome. To disable, type "chrome://flags" (without quotes) in the address bar in chrome and then disable the flag "SameSite by default cookies". Can you try this option to see if it resolves the issue?

Hi @bluesteam This isn't something we control as the issue relates to the permissions for cross-site and x-frame settings between WHMCS and WHM so we don't have full control here when Chrome decides to change the way they handle these security settings by default or, how the administrator of the server chooses to intentionally restrict the ability to include WHM in Frames.

@bluesteam Different browsers implement things slightly differently, some taking a stricter stance on X-Frame options than others for example. Can you confirm if this issue persists after changing the settings in WHM?

WHMCS in a HA environment is possible, and many of our clients do this. We have a blog article on this which may help get you started: https://blog.whmcs.com/133514/demystifying-high-availability-for-whmcs

Hi, Admin login failures should be logged to the activity log (tblactivitylog) - could you perhaps query this for the failed login data you're looking for?

If you're finding the WHM frame does not load in. WHMCS connect, this indicates that a server side X-Frame-Option is preventing WHM from being loaded within an iFrame by WHMCS. The server configuration must be adjusted to allow this in order for WHMCS Connection to function. This can be adjusted per the cPanel Docs: https://documentation.cpanel.net/display/82Docs/Tweak+Settings+-+Security#TweakSettings-Security-UseX-Frame-OptionsandX-Content-Type-Optionsheaderswithcpsrvd in Server Configuration > Tweak Settings > Security > ‘Use X-Frame-Options and X-Content-Type-Options headers with cpsrvd’ Please try these adjustments to see if this resolves your issue?

Are you referring to transfers out, or transferring a .UK into your WHMCS? We have some further details on transfers here: https://docs.whmcs.com/Nominet

This would seem to be expected behaviour as the hook code would be executed before returning the results to the browser (to show the complete checkout page). Are you having a particular issue with this currently?

Hello, Are you seeing an error for sending the email in the Activity Log under Utilities > Logs? If you'd like us to take a look and advise please feel free to raise a support ticket. 🙂

Some great points have been raised on the issues around this, so I have gone ahead and raised case #CORE-15044 with our developers in order to have this reviewed for future releases. Whilst I cannot provide an estimated time for completion for this, once we resolve cases and push features they are available at our change log, here: http://changelog.whmcs.com/

So long as this is not indexed by search engines, what problem would you see with this as it would only affect the user who created the URL?

I must admit, not a meta tag I've come across personally - but that does indeed seem like a great way to handle this without require complex validation and would make an excellent Feature Request.

An interesting point, I would recommend raising a Feature Request for this so we can gather further community feedback -- https://requests.whmcs.com It may be we could introduce validating these URLs match the expected slug and returning a 404, or perhaps a permanent redirect to the expected URL to avoid SEO issues with duplicate content.

Hello, It sounds like the email is being sent as you mentioned an entry in the activity log to this effect. Password Reset emails are not logged in the email log for security reasons, we have this noted on our docs article here: https://docs.whmcs.com/Email_Sending_Issues I would suggest checking the docs article for sending issues, and of course don't forget to check spam/junk folders! If you're still stuck please raise a support ticket and one of the team can take a closer look and best advise.