Stripe Charge Request Incorrect

[darrensweb]

Hi,

I was previously using RoudiApp Stripe plugin and have done for years.

Due to the whole 3d secure and EU payments I decided to switch to the built in Stripe module.

Since doing this alot of my customers when trying to use an existing card are seeing the following error:

No such customer: cus_6wGlZpgCnjkYk2,card_198Q9G4YTT8T6YNYsBuu6vmm

I contacted stripe who are saying the built-in WHMCS plugin is sending the wrong charge request:

They gave me this:

  {
  "error": {
    "code": "resource_missing",
    "doc_url": "https://stripe.com/docs/error-codes/resource-missing",
    "message": "No such customer: cus_6wGlZpgCnjkYk2,card_198Q9G4YTT8T6YNYsBuu6vmm",
    "param": "id",
    "type": "invalid_request_error"
  }
}

Anyone else have this issue? I am using 7.8.1

[WHMCS John]

Hi @darrensweb,

The problem here lies with the way the third-party module was storing the data. Unfortunately it was in a format suitable for migration: https://docs.whmcs.com/Stripe#Migrating_from_a_3rd_Party_Stripe_Module

Clients will need to re-enter their card details now you've switched to the official module so data is stored in the expected format.

[darrensweb]

Hi,

 

According to the link you posted if the module is storing data with the cust prefix then it is migratable.

 

I have checked customers who have cards stored and they all have the cust prefix as an example: cus_EmvcvSs4IrJrmC,card_1EJLlh4YTT8T6YNYYjLijBLo

 

So what is it about the above storage that is incorrect?

 

Can it be modified, I have 1000s of customers with cards and could do with a fix.

[darrensweb]

Looking at a transaction that succeeded while I had the new stripe module active I can see the data is stored as follows:

 

{"customer":"cus_Fk4hvEFV4Amdnd","method":"pm_1FEaXw4YTT8T6YNYCLhjq6PH"}

 

The data for my previous plugin was stored like below:

cus_Fk6MxbSUxpORU9,card_1FEcA04YTT8T6YNYwE6IYKDQ

 

Can I alter these manually using some conditional logic and if so what table am I looking for these?

 

I assume if I was to alter the data of the current module for each token like below

["customer";"cus_Fk6MxbSUxpORU9","pm_1FEcA04YTT8T6YNYwE6IYKDQ"]

 

Would that work?

[tripsis]

16 hours ago, darrensweb said:

Hi,

 

According to the link you posted if the module is storing data with the cust prefix then it is migratable.

 

I have checked customers who have cards stored and they all have the cust prefix as an example: cus_EmvcvSs4IrJrmC,card_1EJLlh4YTT8T6YNYYjLijBLo

 

So what is it about the above storage that is incorrect?

 

Can it be modified, I have 1000s of customers with cards and could do with a fix.

My guess is the storage should ONLY contain "cus_EmvcvSs4IrJrmC". Having the ",card_xxx" breaks it because then it's no longer a valid Stripe customer ID number.

[WHMCS Marcus]

4 hours ago, tripsis said:

My guess is the storage should ONLY contain "cus_EmvcvSs4IrJrmC". Having the ",card_xxx" breaks it because then it's no longer a valid Stripe customer ID number.

This is correct. In the link provided by John above, prior to v7.8 only 1 card was supported - therefore the migration is expecting only the "cus_xxx" value to be present. If you are able to edit the `tblclients.gatewayid` to exclude the other unsupported data, cards should be able to charge without issue. Please do note that any already migrated cards would now be invalid and those customers would need to re-enter their cards. 

 

 

[darrensweb]

Hi Guys,

I managed to edit the data and remove the last 30 characters from the "gatewayid"

Worked a charm and all is working fine.

 

Thanks, guys.

[WHMCS John]

Hi @darrensweb,

I'm pleased to hear you were able to solve the problem.

For the benefit of others who may find themselves in this same position in future, could you share how you trimmed the last 30 characters from the gatewayid please?

[synalabs]

Hi,

For those that used RoudiApp Stripe gateway before upgrading to WHMCS v7.8's Stripe gateway:

0/ If you are not fluent with PHP and MySQL, do not attempt this yourself. Seek help from a professional. Make a database backup before attempting anything. I cannot be held responsible if theses scripts misbehave on your WHMCS installation.

1/ Best way forward: BEFORE upgrading to WHMCS 7.8, convert your gatewayid token to a format that the WHMCS 7.8 upgrade script understand:

Tested OK on MySQL 5.7.

update tblclients set gatewayid=SUBSTRING_INDEX(SUBSTRING_INDEX(gatewayid,',',1),',',-1);

and that's it. You don't need to execute Step 2.

2/ Salvaging your Stripe customer token if you upgraded already to WHMCS 7.8 without converting your gatewayid first:

Tested OK on PHP 5.6, MySQL 5.7.

<?php
require 'configuration.php';//WHMCS configuration file
mysql_connect($db_host, $db_username, $db_password);
mysql_select_db($db_name);
$query = "select userid,payment_id from tblpaymethods";
$pay_result = mysql_query($query);
while ($row = mysql_fetch_array($pay_result, MYSQL_ASSOC)) {
  $clientid = $row['userid'];
  $payid = $row['payment_id'];
  $hash = md5($cc_encryption_hash.$clientid);
  $query = "SET block_encryption_mode = 'aes-256-cbc';";
  $result = mysql_query($query);
  $query = "SELECT AES_DECRYPT(UNHEX(card_data),'{$hash}',unhex('00000000000000000000000000000000')) AS card_data FROM tblcreditcards WHERE id='{$payid}'";
  $result = mysql_query($query);
  $row = mysql_fetch_array($result, MYSQL_ASSOC);
  $card_data = json_decode($row['card_data'], true);
  echo "UserID: " . $clientid. " Data: ". var_export($card_data, true) . PHP_EOL;
  if ($card_data && array_key_exists('remoteToken', $card_data)) {
    if (strpos($card_data['remoteToken'], ',card')) {
      list($token_customer,$token_card) = explode(',', $card_data['remoteToken']);
      echo "UserID: " . $clientid . " Token Customer: " . $token_customer . PHP_EOL;
      $new_card_data = json_encode(array("remoteToken" => $token_customer));
      $query = "update tblcreditcards set card_data=hex(aes_encrypt('{$new_card_data}', '{$hash}', unhex('00000000000000000000000000000000'))) where id='{$payid}';";
      $result = mysql_query($query);
    }
  }
}
?>

 

[eugenevdm]

Any idea how to do this with MariaDB 10.3? 

So far problem encountered is 

SET block_encryption_mode = 'aes-256-cbc

doesn't exist and

AES_DECRYPT

can't take three parameters.

[Magicklug]

Terrific, the answer posted is correct. Thanks for helping out.