wintech2003

The hook works fine, so for me it doesn't make any difference - the issue with fake registrations has been solved. I'm just saying that since you can see that so many people solved the issue not with reCAPTCHA v3, but with Turnstile, and since you're doing hCAPTCHA anyway (hCAPTHCA vs Turnstile should also be a matter of a couple code changes), you could deliver both. Which feature request came first / second, has more votes etc doesn't make any difference to us users - we're looking for solutions, and the current solution is a hook. Do you want people keep using the hook, or integrate the solution into WHMCS and have everyone happy.

The original hook from Hybula does not work with Lagom2 out of the box, but I found this fork that works fine: https://github.com/themikeambrose/whmcs-turnstile-lagom2

Hi John, Implementing Cloudflare's Turnstile should also be fairly easy, it's just a matter of replacing the siteverify URL and adding the Turnstile script snippet: https://developers.cloudflare.com/turnstile/migration/migrating-from-recaptcha/

+1 We use this hook and the fake signups stopped immediately.

You don't need to be on Cloudflare to use Turnstile, you just need a Cloudflare account. Cloudflare Turnstile can be used with domains that are not behind Cloudflare without an issue. We used the hook you suggested and the fake orders stopped.

Thanks for confirming, that's great news. I didn't upgrade to v8 all this time because their site/WHMCS marketplace says it's compatible up to v7.10

We're seeing this error in our error_log as well [28-Oct-2019 11:01:44 UTC] [WHMCS Application] ERROR: Error: Call to undefined function WHMCS\Payment\PayMethod\run_hook() in /home/username/public_html/vendor/whmcs/whmcs-foundation/lib/Payment/PayMethod/MigrationProcessor.php:0 Stack trace: #0 /home/username/public_html/vendor/whmcs/whmcs-foundation/lib/User/Client.php(0): WHMCS\Payment\PayMethod\MigrationProcessor->migrateForClient(Object(WHMCS\User\Client)) #1 /home/username/public_html/vendor/whmcs/whmcs-foundation/lib/Auth.php(0): WHMCS\User\Client->migratePaymentDetailsIfRequired() #2 /home/username/public_html/vendor/whmcs/whmcs-foundation/lib/Utility/Bootstrap/Application.php(0): WHMCS\Auth::persistClientSession() #3 /home/username/public_html/init.php(0): WHMCS\Utility\Bootstrap\Application::persistSession() #4 /home/username/public_html/clientarea.php(0): unknown() #5 {main} {"exception":"[object] (Error(code: 0): Call to undefined function WHMCS\\Payment\\PayMethod\\run_hook() at /home/username/public_html/vendor/whmcs/whmcs-foundation/lib/Payment/PayMethod/MigrationProcessor.php:0)"} [] Like @Chris74 we too use Stripe & MyWorks PayPal module. The error shows up when the MyWorks cron runs: /modules/addons/paypal_billing_center/cron/paypalbilling.php

Yes, that did the trick 😉 Thank you!

I actually asked @cyberhostpro since he fixed this 🙂 I know they're not going to reply here. I've already asked them about this via ticket a few days ago but haven't heard back. I'll let you know if I do. Thanks @cyberhostpro yeah I'm sure I did remove the correct IDs based on userid, not id. I thought maybe the cron needs to run or something like that. Anyway, I'll check it out again.

Did you have to run anything else after deleting the entries? I've taken a backup of the tblpaymethods table and tried your suggestion, but it didn't help. I found certain specific client IDs that are throwing the "Oops! Something went wrong and we couldn't process your request." error, found the respective entries (based on userid) on that table and deleted them. However, visiting the client profiles will still throw the same error. In the admin folder's error_log I see this: [ICODE]PHP Fatal error: Cannot redeclare cancel_billing_agreement() in on line 0[/ICODE]

Hello, I'm not sure this is limited to initial signups (we haven't had any signups recently so I can not confirm), for us, it's happening for manual payments from existing customers. Customers that used to have a correct statement descriptor before 7.8 when they paid manually. If an existing customer pays his (monthly/recurring) invoice (for an already active service, not a new order) before the due date, manually, through the Client Area by clicking the "Pay Now" button on the invoice, then his statement descriptor will be wrong. If the same customer chose to leave the invoice to auto-pay via cron on the due date, the statement descriptor would be correct.

I don't get what the amount of users that tested beta releases has to do with making their addon compatible with a new release? This is what we did with all previous updates in the past. We first waited until all addon providers issued updates for their code and would then perform the WHMCS update. This time, however, we were forced to upgrade for SCA compatibility in Stripe. With 2/3s of payments going through Stripe and 1/3 via PayPal, common sense said we should upgrade. Again, I'm not even complaining about the lack of functionality due to the update; we're dealing with this manually and contacting every affected customer one way or another. The thing here is that the addon is breaking something within WHMCS which causes great inconvenience to our everyday work. I believe a hotfix for that issue alone, should have been provided much earlier. I could then wait for a few weeks for a proper update.

Yeah, since it's working fine for cron payments, I don't get why the same can't be done for manual payments.

I'm sure they're aware of it since when I contacted them on September 13th they mentioned they're "expecting to release a gateway update within the next 1-2 weeks if all testing goes well" However, no update yet & no replies to tickets either. Again, the most important issue here is not the fact that automatic PayPal payments aren't processed, it's that the Client Summary page for several customers (for which a billing agreement is setup) throws a 500 error. Fixing the functionality, OK, I understand it can take a few weeks to fix that (even though they had plenty of time to do it since WHMCS was providing betas), but such a critical issue as not being able to view your customers' summary should have been fixed as soon as possible. Imagine not being able to see this screen for a third of your customers, and what an inconvenience that is.

Thanks for clarifying. I don't consider this "fixed". It was working fine before the update, and it is working fine for captures done by the cron, so manual transactions should also show up properly with the invoice number and only {StripeStatementDescriptorPrefix} without SHOPPING CART next to it. Just like it does for transactions via the cron.