Jump to content

Daily CRON failing - ProcessCreditCardPayments

niels

By niels
in Troubleshooting Issues

 Share

Recommended Posts

niels Senior Member

niels

Posted
Posted (edited)

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
0
Link to comment
Share on other sites
niels Senior Member

niels

Posted
  • Author
Posted (edited)

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
0
Link to comment
Share on other sites
  • WHMCS Staff
WHMCS Peter Senior Member

WHMCS Peter

Posted
  • WHMCS Staff
Posted

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.

0
Link to comment
Share on other sites
  • WHMCS Staff
WHMCS Peter Senior Member

WHMCS Peter

Posted
  • WHMCS Staff
Posted

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.

0
Link to comment
Share on other sites
Darthkatzs Member

Darthkatzs

Posted
Posted
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.

0
Link to comment
Share on other sites
Darthkatzs Member

Darthkatzs

Posted
Posted

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.

0
Link to comment
Share on other sites
twikamltd Member

twikamltd

Posted
Posted

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.

0
Link to comment
Share on other sites
twikamltd Member

twikamltd

Posted
Posted

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

 

0
Link to comment
Share on other sites
twikamltd Member

twikamltd

Posted
Posted

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.

0
Link to comment
Share on other sites
twikamltd Member

twikamltd

Posted
Posted

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.

0
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • 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

  I accept