Jump to content

WHMCS Edward

WHMCS Technical Analyst
  • Posts

    168
  • Joined

  • Last visited

  • Days Won

    1

WHMCS Edward last won the day on June 28 2016

WHMCS Edward had the most liked content!

1 Follower

About WHMCS Edward

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

WHMCS Edward's Achievements

Senior Member

Senior Member (3/3)

4

Reputation

  1. The WHMCS UI will call your custom payment gateway module and pass in the details of the credit card/pay method that has been requested for deletion via the UI. If your payment module returns that the deletion was successful, WHMCS will automatically delete the appropriate payment method. You do not need to do this within your module. If you are doing something different and need to use the API then the following new API methods have been made available for working with Pay Methods: https://developers.whmcs.com/api-reference/getpaymethods/ https://developers.whmcs.com/api-reference/addpaymethod/ https://developers.whmcs.com/api-reference/updatepaymethod/ https://developers.whmcs.com/api-reference/deletepaymethod/ -Ed
  2. Hi Harry, Yes it's perfectly safe to re-upload and replace all the files in an existing WHMCS installation with those from a latest zip file download from our website. We recommend doing this from time to time in support to ensure that all files present for an installation are the latest versions. That is assuming that any customisations to templates have been made in a custom template directory (https://developers.whmcs.com/themes/getting-started/), or modifications to files such as language files or whois servers have been made using overrides (https://developers.whmcs.com/languages/overrides/). -Ed
  3. The code you're quoting is a sample of the API call you might would make to your payment gateway providers' tokenisation API. In reality it would need to be your payment gateway API endpoint that you would use in place of the https://www.example.com/api/delete URL - not something within the WHMCS API. -Ed
  4. Pleased to hear things are now working again for all of you. We always hope to catch issues like this during pre-production but unfortunately we did not this time. Sorry for any disruption it caused. For others reading this thread, there were 2 issues that affected the cron running that were resolved in 7.8.1 - one that affected users of tokenisation modules such as Stripe where charges were attempted for customers whose card details were stored using legacy storage methods, and one where the register_argc_argv php directive was disabled within the PHP environment (note that this is always enabled by default). If you have upgraded to 7.8.1 and continue to experience problems, please let us know. -Ed
  5. The error you're experiencing tells us a fatal error is occurring when attempting to load one of the custom or 3rd party modules that your products are configured to use. Enabling error display should have caused an error to be displayed, however, it could be getting hidden from view in the browser output due to broken HTML. Best thing to do is probably open a ticket so one of our support technicians can take a look. -Ed
  6. Hey Brian, Updated developer documentation has been made available on the developers site for tokenisation gateway modules, however the previous methods of returning tokens via the storeremote and capture functions should continue to function as before. https://developers.whmcs.com/payment-gateways/tokenised-remote-storage/ Let us know if something you need is missing from there. -Ed
  7. Glad you were able to find a workaround. Please let us know if you run into any further issues. -Ed
  8. For an issue such as this, it would be really helpful for us to be able to see exactly how the account information is being returned from your server control panel, and how the record is configured in WHMCS. Therefore could I ask you to please open a ticket and provide access to your installation, along with the server name and domain name in question, and one of our team will take a look. Please reference this thread also so the person who receives the ticket knows you've been referred from the community. Thanks -Ed
  9. Can you try running each of the SQL update statements individually in order to see which one specifically is triggering this error? -Ed
  10. There is discussion within the case and code change submission that it should be noted in the release notes, so it appears the lack of mention was an oversight. I will be sure to raise this with the team. Sorry for any inconvenience it caused. -Ed
  11. Firstly sorry to hear about what happened here but glad to hear you were able to restore the accounts. I think it's unusual for domain names within WHMCS to contain a mix of lower and uppercase but nonetheless ideally the tool should be able to handle that. I have opened CORE-13684 to have this investigated. -Ed
  12. The UI you are referring to is something we have absolutely no control over. This is simply how eWay's secure tokenisation platform has been designed by eWay themselves. -Ed
  13. It appears that the following changelog item is what you're seeing here: As part of this case, the overage billing feature was updated to support overage billing where the soft limit is 0. Essentially a soft limit of 0 means you want to bill the customer for all usage. If you have a product where you are enabling overage billing but do not want either disk space or bandwidth to be billed for, you should ensure you set a very high soft limit that will mean the customers usage never exceeds it, and therefore never gets billed. Hope this helps! -Ed
  14. Seeing an Oops error page like this indicates an error occurred during the generation of the page. The error can be anything, from a simple notice or warning to a fatal error that halts execution. It's the PHP error reporting level on your server that determines which types of errors will trigger it. In this case, it appears the error is just a low level warning and not something to be concerned about. It does however suggest your PHP error_reporting level on the server is a little high for a production environment and we would recommend reducing it in your servers php configuration to 0, or at least to exclude warnings and notices. -Ed
  15. How did you provision the SSL? For the automation to take effect, you need to add the SSL to the cPanel hosting account service as an add-on. When you do that and it is attached to the cPanel hosting, it should then be able to detect the account you want to provision it to and perform the automated steps upon the create action being triggered. -Ed
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated