Credit Card Payment Removed from WHMCS for No Reason.

[davet]

I have a CDG Commerce Merchant account using Quantum Gateway.

Recently I've had a few customers contact me about their card on file is missing and they had to re-add it.

I thought that maybe their cards expired but checked my merchant account.

I checked their recent payments and their cards did NOT expire.

I also checked the Secure Vault within Quantum Gateway and I do see a profile for each customers.

Any ideas why their cards were removed from WHMCS?

Is there a way to re-add it to WHMCS, or re-link it to the card in Secure Vault without requiring my customers to re-add the card themselves?

[WHMCS John]

Hi @davet,

Which version of WHMCS are you using?

Please review the client's Email and Log tab. Do you see any entries or email notifications related to card removal or expiry at around the time this occurred?

[davet]

 

I was using version 7.9.1 at the time but just upgraded yesterday to 7.9.2

Nothing is showing in the Email nor Log tab about their card being removed.

 

[DougK94]

I have had the exact same problem.  Also nothing in the email and logs. with 7.9.1 and I am now running 7.9.2.

[davet]

Is there a way to re-attach the card to WHMCS? 

The card details are within the SECURE VAULT within my Merchant account but I do knot know the full card details.

[davet]

I had another customer contact me about their payment on file is no longer there but it is in the SECURE VAULT in my Quantum Gateway.

Is there a way of re-connecting/re-adding their card from the Secure Vault without knowing the full card number?

I checked the emails and log within WHMCS and don't see any emails about a card being removed nor expiring.

[WHMCS ChrisD]

@davet Although not recommended, you could pop the token back into the database, but I would suggest having the client re-enter the credit card details to re-create the whole new token ID

[ElMorgan]

This exact same thing happened to us.  Any idea what happened, and can we be reassured it won't happen again?   Most customers are cool with us calling them about this, but some are cranky that  they have to re-enter their info.

[DougK94]

I had another one removed today after looking at the customer profile from admin.

The activity log shows the following:

Quote

03/05/2020 08:58    
Automatically Removed Payment Method without Encrypted Data. PayMethod ID: 391 User ID: 13
    Xxxxx    xxx.xxx.xxx.xxx
03/05/2020 08:58    
Automatically Removed Payment Method without Encrypted Data. PayMethod ID: 391 User ID: 13
    Xxxxx    xxx.xxx.xxx.xxx
03/05/2020 08:58    
Pay Method migration failed. Card number must be at least 13 chars - User ID: 13
    Xxxxx    xxx.xxx.xxx.xxx

Nothing is in any other logs

[davet]

On 2/20/2020 at 5:32 PM, WHMCS John said:

Although not recommended, you could pop the token back into the database, but I would suggest having the client re-enter the credit card details to re-create the whole new token ID

You wouldn't happen to have a tutorial on how to do this?

Although it doesn't seem all clients have had their cards removed I keep coming across more and more that have had their cards removed.

If you don't have a tutorials, what table and field is the data stored in?

Edited March 6, 2020 by davet

[WHMCS John]

Please do open a support ticket with an impacted client.  We can examine a database backup prior to the migration and compare it to the current database to determine the cause of this behaviour.

For tokenised gateways, the fields in question are typically tblclients.gatewayid, tblclients.cardlastfour and tblclients.cardtype. There should be nothing in the other card* or bank* fields.

As always; direct database manipulation is not recommended or supported. Before making changes to the database, please backup.

[chrissie-penguin]

Don't suppose anyone managed to get to the bottom of this? We have also had it with at least one client.  No reason for the deletion, nothing in logs or emails, card not due to expire until July 21 and nothing in the activity log.  Anyone get anywhere in finding the cause? TIA.

[mkern]

Hi All, 

I just ran into this issue yesterday and wanted to share what I did to resolve it.  I was running a little behind on WHMCS versions because I had some integration I needed to split up and once I completed that I updated to 7.9.2 on 4/2.  I was super worried that this was going to completely break Quantum Vault because in previous attempts to upgrade I had serious conflicts with SiteOx's Quantum Vault plugin.  I removed that plugin prior to upgrade and everything seemed to work perfectly.  All credit cards were automatically charging and life seemed good.  However, apparently certain users had problems that I did not notice until yesterday.  I escalated to WHMCS and paid for the FastTrack support.  They investigated and they told me how the new system works and that there was an error in the migration process of moving the data from the tblclients table to the new location.  They requested a review of a previous backup prior to 4/2 which was presumable when the issue occurred because the new method was introduced in 7.8+ I believe.  In any case, between this post and their feedback on the new mechanism, I was able to review the tblclients table for the customer I was having problems with and I noticed erroneous data in the cardnum/startdate/expdate fields.  I also noticed in the Activity Logs that WHMCS Support tried to clear the encrypted data from these fields.  I manually cleared the cardnum/startdate/expdate fields for the problem customer (we don't store the cards anyway) and the problem was resolved.  

Also worth noting, I had no errors in the Gatewaylog, the errors were only showing up in the Activity log. 

Pay Method migration failed. Card number must be at least 13 chars - User ID: XX

I had upgraded to 7.10.x prior to escalating to support, so it works on that version as welll. 

Thanks, 

Michael Kern

Admin on Demand, LLC 

 

 

[davet]

Thanks for the feedback @mkern!

How did you "manually cleared the cardnum/startdate/expdate fields for the problem customer (we don't store the cards anyway) and the problem was resolved.  "

When I view those fields in PHPMyAdmin I cannot edit them. It shows "Binary - do not edit" and allows me to upload a file to that field. See attached.

[mkern]

 

 

 

 

 

3

37 minutes ago, davet said:

Thanks for the feedback @mkern!

How did you "manually cleared the cardnum/startdate/expdate fields for the problem customer (we don't store the cards anyway) and the problem was resolved.  "

When I view those fields in PHPMyAdmin I cannot edit them. It shows "Binary - do not edit" and allows me to upload a file to that field. See attached.

Hi Dave, 

For me, I ran the following in MySQL CLI, this would be the equivalent to running a SQL statement in PHPMyAdmin. 

select * from tblclients where id=47 \G;

In this example, id=47 was one of the clients profiles that had the problem.  For the 3 tables below, there was erroneous data, possible encrypted, I am not sure, but it was special characters. 

                cardnum: 
              startdate: 
                expdate: 

I backed up the database and then ran an update statement for each of the tables:

update tblclients set cardnum="" where id=47;

update tblclients set startdate=""  where id=47;

update tblclients set expdate=""  where id=47;

This cleared out the fields and then I was able to properly charge the card without the previous error.  This data was apparently breaking the migration process WHMCS is trying to perform on the backend. 

As I had multiple clients with this problem and none of this field data was needed for me I executed the following to fix all of the clients. 

update tblclients set cardnum="";

update tblclients set startdate="";

update tblclients set expdate="";

This solved the problem for me for all clients, now there is a secondary issue where WHMCS thinks there is a "default" card ahead of the real one, but I was instructed that deleting that when the problem occurs will solve the problem.  I haven't bothered with that yet, as I have just manually selected the correct card.  If recurring billing breaks due to the secondary issue this is what they said I needed to do:

 

 

 

 

Quote

From WHMCS Support. 

I'd recommend manually removing any of these "Default" cards (which were likely created by the system trying to create the Pay Methods from the leftover partial card data) via the client's Summary tab:

• Click onto the pay method to display the details
• Then click the delete button in the modal popup.
• Leaving just the Quantum Vault pay method.

Regrettably there isn't an interface to do this en-mass, and trying to modify data in the database directly wouldn't result in the related entries being removed/updated correctly.

 

 

 

 

 

[davet]

Thank you @mkern! Much appreciated!