Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


wintech2003 last won the day on October 2 2019

wintech2003 had the most liked content!

Community Reputation

4 Neutral

About wintech2003

  • Rank

Recent Profile Visitors

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

  1. 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
  2. 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
  3. 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.
  4. 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]
  5. 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.
  6. 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.
  7. Yeah, since it's working fine for cron payments, I don't get why the same can't be done for manual payments.
  8. 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.
  9. 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 {StripeStatem´╗┐entDescriptorP´╗┐refix´╗┐´╗┐}´╗┐ without SHOPPING CART next to it. Just like it does for transactions via the cron.
  10. Around mid-September they said they will release an update within the next 1-2 weeks. I contacted them again yesterday but still no reply. What's worse than not having automatic payments, is that for some customers, visiting their client summary page results in a 500 error and the error_log shows: "PHP Fatal error: Cannot redeclare cancel_billing_agreement() in on line 0" while for others, it shows a 404 error page.
  11. I upgraded to 7.8.3 which is supposed to fix #MODULE-7114 however, descriptors have not been fixed as far as I can see. This is how it should look like: And this is how it looks like now (the 7.8.3 update was applied on Sep 25th): Only payments charged via the daily cron at 9:00AM appear correct. Payments done by the customers themselves don't show the invoice number and the statement descriptor shows up twice:
  • 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