Daily CRON failing - ProcessCreditCardPayments

[niels]

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 September 4, 2019 by niels

[niels]

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 September 4, 2019 by niels

[Darthkatzs]

Having the same issue and it is quite annoying, hoping to see a fix for this soon.

[WHMCS Peter]

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.

[pjs32]

Same issue here

[WHMCS Peter]

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.

[Darthkatzs]

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.

[Darthkatzs]

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.

[twikamltd]

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.

[twikamltd]

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";
    
}

 

[twikamltd]

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.

[twikamltd]

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.

[Evolve Web Hosting]

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.

[pjs32]

any more progress on getting this sorted?

[WHMCS Lawrence]

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!

[TheHostingHeroes]

I have this issue

Opened a $30 fast response  ticket with support (#RMC-273719)

[TheHostingHeroes]

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

worth the $30 for 1 minute response time 😄