Jump to content
niels

Daily CRON failing - ProcessCreditCardPayments

Recommended Posts

Since updating to 7.8.0 and 7.8.1 the daily CRON crashes due to a failure while processing credit card payments.

Credit card payments do work normally on the website. Also, some recurring payments do get processed before the CRON crashes. 

[WHMCS Application] ERROR: Error: Call to undefined method InvalidArgumentException::getJsonBody() in /home/www/x/modules/gateways/stripe.php:0 Stack trace: 
#0 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Module/AbstractModule.php(0): stripe_capture(Array) 
#1 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Module/Gateway.php(0): WHMCS\Module\AbstractModule->call('capture', Array) 
#2 /home/www/x/includes/ccfunctions.php(0): WHMCS\Module\Gateway->call('capture', Array) 
#3 /home/www/x/includes/ccfunctions.php(0): captureCCPayment(122085) 
#4 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Cron/Task/ProcessCreditCardPayments.php(0): ccProcessing(Object(WHMCS\Cron\Task\ProcessCreditCardPayments)) 
#5 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Scheduling/Task/AbstractTask.php(0): WHMCS\Cron\Task\ProcessCreditCardPayments->__invoke() 
#6 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Scheduling/Task/AbstractTask.php(0): WHMCS\Scheduling\Ta
 sk\AbstractTask->execute() 
#7 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Cron/Console/Command/AbstractCronCommand.php(0): WHMCS\Scheduling\Task\AbstractTask->run() 
#8 /home/www/x/vendor/whmcs/whmcs-foundation/lib/Cron/Console/Command/AbstractCronCommand.php(0): WHMCS\Cron\Console\Command\AbstractCronCommand->executeCollection(Object(WHMCS\Scheduling\Task\Collection)) 
#9 /home/www/x/vendor/symfony/console/Command/Command.php(259): WHMCS\Cron\Console\Command\AbstractCronCommand->execute(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) 
#10 /home/www/x/vendor/symfony/console/Application.php(844): Symfony\Component\Console\Command\Command->run(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) 
#11 /home/www/x/vendor/symfony/console/Application.php(192): Symfony\Component\Console\Application->doRunCommand(Object(WHMCS\Cron\Console\Command\AllCommand), Obj
 ect(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) 
#12 /home/www/x/vendor/symfony/console/Application.php(123): Symfony\Component\Console\Application->doRun(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) 
#13 /home/www/x/crons/cron.php(0): Symfony\Component\Console\Application->run(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) 
#14 {main} {"exception":"[object] (Error(code: 0): Call to undefined method InvalidArgumentException::getJsonBody() at /home/www/x/modules/gateways/stripe.php:0)"} []
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1">
    <title>Oops!</title>
    
<style>
        body {
            margin: 30px 40px;
            background-color: #f6f6f6;
        }
        .error-container {
            padding: 50px 40px;
            font-family: "Helvetica Neue",Helvetica,Arial,sans-serif;
            font-size: 14px;
        }
        h1 {
            margin: 0;
            font-size: 48px;
            font-weight: 400;
        }
        h2 {
            margin: 0;
            font-size: 26px;
            font-weight: 300;
        }
        a {
            color: #336699;
        }
        p.back-to-home {
            margin-top: 30px;
        }
        p.debug{
            padding: 20px 0;
            font-family: "Courier New", Courier, monospace, serif;
            font-size: 14px;
        }
        .info {
            border: solid 1px #999;
            padding: 5px;
            background-color: #d9edf7;
        }
    </style>

  </head>
  <body>
    <div class="error-container">
<h1>Oops!</h1>
<h2>Something went wrong and we couldn't process your request.</h2>
<p>Please go back to the previous page and try again.</p>
</div>
  </body>
</html>

This particular issue aside, I don't think the entire CRON should crash just because a single sub-task fails.

 

Edited by niels

Share this post


Link to post
Share on other sites

Update:

Assuming captureCCPayment(122085) points to an invoice number, I had a look at the relevant client:

  • This client had no credit card stored. (My idea was to delete any cards, if present.)
  • This client did have an additional contact.
  • Deleting this additional contact fixed the issue.
Edited by niels

Share this post


Link to post
Share on other sites

Hi there!

I have just dealt with a Bug Report for this issue and can confirm that I am unable to reproduce this issue.

So that we can get to the bottom of this, could you please open a support ticket, providing access to WHMCS, FTP and your Web Hosting Control Panel (For MySQL Database access)?

This way, we can attempt to identify the underlying cause.

Share this post


Link to post
Share on other sites

Hi everyone!

Looking through our recent ticket history surrounding this, we have identified that this issue can occur when a PayMethod migration has not completed as expected. WHMCS expects a JSON format being returned.

If you view a customers PayMethod for Stripe and see a single string similar to "cus_123456" under "Gateway Token", this is likely the issue. WHMCS expects to see JSON similar to the following in this field:

{"customer":"cus_FkAzmnNeng3h0Y","method":"pm_1FGQoTJhfjL6Y9T60u0lstUr"}

We expect to see this resolved in WHMCS 7.8.2. Please ensure you have updated. If the issue persists, remove the PayMethod and add the client card details again, ensuring the token is shown as above.

It's also possible this issue has occurred if a single cus_ token was migrated from a third-party module and then switched to the original, stock Stripe module.

Share this post


Link to post
Share on other sites
1 hour ago, WHMCS Peter said:

Hi everyone!

Looking through our recent ticket history surrounding this, we have identified that this issue can occur when a PayMethod migration has not completed as expected. WHMCS expects a JSON format being returned.

If you view a customers PayMethod for Stripe and see a single string similar to "cus_123456" under "Gateway Token", this is likely the issue. WHMCS expects to see JSON similar to the following in this field:


{"customer":"cus_FkAzmnNeng3h0Y","method":"pm_1FGQoTJhfjL6Y9T60u0lstUr"}

We expect to see this resolved in WHMCS 7.8.2. Please ensure you have updated. If the issue persists, remove the PayMethod and add the client card details again, ensuring the token is shown as above.

It's also possible this issue has occurred if a single cus_ token was migrated from a third-party module and then switched to the original, stock Stripe module.

Rather disappointing that this suddenly stopped working when it was no issue before. Now I have to force a bunch of customers to re-enter their details. WHMCS is not really helping me consumer minded here...

It has been a while since I migrated from the non-built-in stripe module, so it would be great if you provided us with a way or a query to be able to track all the bad ones down and delete them from the database so they get an e-mail to update their details.

Share this post


Link to post
Share on other sites

Could we at least get a way to see which credit card the script fails at? (example: having another verbose level in the command line to show which card it is trying to process). That way we know where to look, as it is really hard for me to track this down, as all the ones i've tried, which in our database look "wrong", seem to work fine.

Share this post


Link to post
Share on other sites

Same issue here.

What I'm seeing is the cus_ token gets converted to the JSON version with a method added after a successful manual capture from the admin area. If the card is declined that doesn't happen though, which is to be expected.

What I can't see is which it's tripping up on. I've verified the tblpaymethods, tblcreditcards and tblbankaccts tables are all clean and look ok, and also removed any paymethods which had no cus_ tokens.

Share this post


Link to post
Share on other sites

If you just want to dump all your tokens to see if there's any weird ones. Can't find any in ours.

<?php

// Include WHMCS for API functions
include('init.php');

$table = "tblpaymethods";
$fields = "id,userid";

$result = select_query($table,$fields);
while ($data = mysql_fetch_array($result)) {
    
  // Get pay methods if client exists
  $command = 'GetPayMethods';
  $postData = array(
        'clientid' => $data['userid'],
        'paymethodid' => $data['id']
  );
  $pm_results = localAPI($command, $postData);
  //print_r($pm_results);
  
  echo "PMID: ".$data['id']." token: ".$pm_results['paymethods'][0]['remote_token']. "\n";
    
}

 

Share this post


Link to post
Share on other sites

So one thing I've been able to see is:

If an invoice is set to Stripe, but the client only has a different pay method saved, with a token ID for Worldpay Futurepay in our case (and yes the pay method is set to Worldpay Futurepay), then the cron still tries to use that Worldpay FP pay method with the Stripe gateway and that is causing the failure.

I'm now loathed to remove all Worldpay pay methods as I've spent a couple of days making sure everything looks perfect in the database.

Share this post


Link to post
Share on other sites

So it's definitely Worldpay pay methods being sent to the Stripe gateway in our case, I modified the Stripe gateway (don't ask how) to check for Worldpay Futurepay IDs and return as declines instead, and now the payment cron is fine.

In other words, there's a logic bug somewhere else in the WHMCS code allowing this to happen.

Share this post


Link to post
Share on other sites

Is this an issue with all payment gateways? We haven't upgraded yet and use authorize.net. Not sure whether to hold off a bit longer before the upgrade. 7.8.2 doesn't bring many features to us that are a necessity so there's no real pressure to upgrade.

Share this post


Link to post
Share on other sites

Hey everyone,

If anyone is still experiencing this issue and hasn't opened a ticket, could you please do so and provide temporary login details so we can investigate this further. Thanks!

Share this post


Link to post
Share on other sites

wow that was a quick reply.  I had a patch sent to me within seconds.

worth the $30 for 1 minute response time 😄

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Similar Content

    • By Luthersites
      When I try to do the update I get the following error:
      Unable to complete incremental updates: Unable to import the 7.8.0 Alpha1 database file. Unable to import /home/lutherh/public_html/resources/sql/upgrade780alpha1.sql: SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs
      I can't find anything on your site that talks about this error, and I find it odd that the database has incorrectly set column types.  Please advise as to what I need to do.
    • By noahesbjerg
      Hi,
       
      So, I just got a stripe account. And updated to the newest WHMCS version. But it seems that the new version completely broke the stripe module. For an example, if I try to delete a payment method I get this: https://i.imgur.com/xjtQkPn.png . And trying to add a new payment method results in this " Payment method failed to create successfully. Please try again.". I am using a custom theme, but it's also broken with the default one.
    • By loopmail
      Looking around and some clients have enabled 2fa for the primary user, but there seem to be no details for it on the contacts page. is this not a feature on offer to contacts or a way for administrators to see the status/clear the status for contacts?

       
    • By zarvis
      Hi,
       
      From today morning the Invoices are not being updated, and the API callback is getting failed for the Coingate and perfect money modules.
      Anyone else facing similar issue?
       
      Regards
      Chandrakant
    • By pushpendra
      After upgrading to WHMCS 7.8, the domain search is not working.
      When we search for domain, Its not showing search result. Its just showing suggestions. And Suggested Domains are also showing taken.
      https://hosting.india.to/clients/cart.php?a=add&domain=register
  • Recently Browsing   0 members

    No registered users viewing this page.

×

Important Information

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