steven99

If you are able to do manual capture via the invoice page, then you do not need the client to do anything. And if you are able to capture, then it should be automatically doing so. Check the billing menu -> gatway log for any errors during the daily batch. If it doesn't work, check your automation settings, including crons.

IIRC ICANN only requires the real data to be stored and available upon their request as well as the email address to be working. So the example above would maintain that holding of info as it would be required for the forwarding. However, it has been a while since I looked at those rules and so could require other items.

Well, that may be allowed under whois privacy rules at that is basically what those services are suppose to do.

Would have to agree with @brian! as that could be against ICANN rules and thus get you in trouble with the upstream provider if complaints happened for example.

That issue is only when provisioning accounts and not while replying to a ticket or sending an email to the client. Also, while having graceful restarts you mainly need to have the apache restart interval set from 0 (instant) to something else. That setting is under the apache settings in tools and settings in plesk admin.

Well, on the flip side of that ioncube prevents malware scanners from finding their targets. So one can say removing it actually improves security as well. Though really the host in question should provide options to continue to use it on their systems.

Have seen other places, like wpengine, losing support for ioncube. Having ioncube and opcache enabled at same time wont be an issue, have that setup currently, but as mentioned they just wont cache. As you're on a shared server and the provider is tossing ioncube, your options are limited to moving to a different host or different platform with them that has ioncube.

Are you using Comodo mod security rules? If so, check site's apache error_log for a mod security hit. The last time I had this behavior it was false positive for a SQL injection by a generic rule in comodo WAF rule set. It also affected other scripts, like Wordpress.

As far as I am aware, Stripe does not have an interface where clients enter their card information as that is suppose to be done within the same interface of the billing app, in this case WHMCS or your other client area. As such, you need an interface within WHMCS or the other client area you mention.

Those would be the correct hooks, but they don't support any returns and thus wont help here. What you could do is use those hooks and redirect back to the server page when your tests fail and set a session variable of "server_error". Then use an AdminAreaHeaderOutput hook and check for that session variable and display error.

So to clarify, it redirects to /clientarea.php instead of /creditcard.php ? Which functions do you have setup?

What is the transaction flow here? Does the client leave WHMCS, like with PayPal, or do they stay on the payment page? Also, is $_SESSION['return_url'] actually set?

Check the marketplace for a module. If there is none there, then you would need to develop your own payment gateway module or hire someone to do so via the requests community.

A few though to consider when changing: Cron job needs to be updated to the new location WHMCS license needs to be reissued Any licensed modules need to be reissued Paypal IPN needs to be updated if used Redirect from /hosting to sub domain should be setup Any custom items that give absolute paths like the custom folders Templates that have hard coded URLs need to be updated That should cover most items. The major thing is the cron job path as without that automation will stop. The change should not affect payment tokens and email templates will use the system url setting once you update that.

How are you marking them paid? Are you doing an "Add payment" via the invoice page or using the "Mark paid" button in the invoice list? From what you have described, I would say you are using the Marked paid button . If you use the add payment and enter the transaction ID from paypal, WHMCS should not then record that transaction when they send the confirmation to WHMCS as it will see there is already a transaction with that ID. Also, the delay could be if they are using echeck as WHMCS wont record the payment until that clears.