Nifty Direct Debit and Stripe module clash in 7.8

[Si]

Lots of failed payments (but strangely not all) with the new 7.8 using the Stripe Gateway.  Here's the process each morning.

1.  Look at the FAILED PAYMENTS in admin area.
2.  Click on the invoice and select ATTTEMPT CAPTURE
3. Result is "No Credit Card Details are stored for this client so the capture could not be attempted."
4. Click on Customer's Profile and voila.....there is a card under PAYMENT METHODS, (which they have used for years as payment).  
5. Click on the card to Open the modal.  (the modal opens and shows the card details).
6. Modal opens for Payment Method with all details completed EXCEPT:  the gateway is not STRIPE it is Nifty Direct Debit (Gocardless)

I can't delete the card.

I can't charge the card.  Stuck in limbo.  Obviously because the remote operations are all failing.

HELP

[Si]

I can manually edit tblpaymethods in phpmyadmin - (which I've now done for each client) to make their payment method stripe.  (It was showing as nifty_direct_debit) but yet they have never paid any invoices using direct debit.  Once changed to stripe, I am able to process the payment.  At this point, I don't know how many more of my customers are affected by this, or what caused it.  It appears to be random.

(Incidentally changing the payment method default in the clients account to Stripe didn't make any difference).

Edited September 2, 2019 by Si

[WHMCS John]

Hi @Si,

WHMCS attempts to migrate card details/tokens into a Pay Method based upon the data present at the time of migration.

I've observed in some cases that if there was only a GatewayID stored in tblclients (no expirydate or card cardlastfour) and there is a bank account type gateway enabled, that could explain how it was assigned to this nifty_direct_debit module.

With Stripe, we'd expect to see the cus_xxx token in tblclients.gatewaysid, along with an expirydate and cardlastfour numbers.

Can you confirm what data you had in tblclients for these clients prior to updating?

[DeSoto]

I am having the same issue with stripe except there is no gateway listed in the modal.

Prior data does show cus_xxx and the other card info is there and appears to be encrypted.

I opened a ticket over 24 hours ago: #KYI-603563

[DeSoto]

This may help...

If I manually attempt capture, I get "No Credit Card Details are stored for this client so the capture could not be attempted." but clients appear to be able to pay fine as they are now getting overdue notices sent to them.

[paravelsolutions]

I was able to manually change the default payment method on some of them to Credit Card in the Profile tab and that allowed me to manually process some of the transactions.  There are several that still would not go through though.

[Si]

This is all over the place.

Not sure now it has anything to do with nifty direct debit at all.  I'm having to manually process cards every morning because they failed during the cron overnight.  I go to the invoice 'ATTEMPT CAPTURE' and get the 'no credit card details stored for this client' message.  Then I view the client, and see that they have a credit card and a history of invoices paid automatically with the card using the cron.  No Direct Debit details.  

Some have Stripe as the payment gateway, some have nothing.

then....back to the invoice, click on ATTEMPT CAPTURE again.  This time the card does show in the modal.  ???????

I process the payment manually and all goes through without issue.

Something somewhere is fundamentally wrong.      

[xyzulu]

Have you upgraded to 7.8.1 yet?

[Si]

No. Does it address / fix the issues ?   Don't want to upgrade / create more issues or be told to roll back.

[xyzulu]

I am also facing a similar issue (not being able to delete cards), however for it is for some customers who never had a card on file.. after visiting their profile they then have an undeletable card (I can delete them manually of course). I've opened a ticket with WHMCS about this quite a few days ago.. so they are well aware.

 

Still, 7.8.1 fixed all the other Stripe issues I had.. especially the ones where I had to process invoices manually. Also, before 7.8.1 invoices were being charged but not marked as paid.

[glenn]

6 minutes ago, Si said:

No. Does it address / fix the issues ?   Don't want to upgrade / create more issues or be told to roll back.

Yes, it does:

MODULE-7075 - Correct API data exchange with Stripe for cards stored prior to 7.8.0
https://docs.whmcs.com/Changelog:WHMCS_V7.8

[Si]

OK, I've upgraded to 7.8.1 - will wait to see what happens when the cron runs next after midnight tonight. 🤞

[paravelsolutions]

I have upgraded to 7.8.1 and the issue remains.

[WHMCS John]

Hi all,

The Pay Method migration is based on an evaluation of a number of factors such as the data in the tblclients table, their invoice payment methods, any default gateway assigned on the Profile tab, and the code within the gateway modules themselves.

How did the Nifty Direct Debit module store the bank details in the client's record (tblclients) before the update? Are there any other tables is stores data, as the migration process won't know about those.

If the client record contains unexpected data, then this could explain the behaviour.

Please do anonymize any information before posting it here publicly.

 

 

[paravelsolutions]

We were able to resolve this issue with the assistance of Sachin. The issue was extraneous information in the database for clients, probably from before we used Stripe as our processor. The solution was to clear data for the cardnum, startdate, expdate and issuenumber fields in the database. Unfortunately, we did have to do it one at a time, but here is what we did:

First, you will need to make a backup of your database.

Then, get the Client ID number for each client that is having issues.

Next, run this query on the database replacing CLIENTID with the actual Client ID number.

UPDATE `tblclients` SET `tblclients`.`cardnum` = '', `tblclients`.`startdate` = '', `tblclients`.`issuenumber` = '' WHERE id = CLIENTID;

You'll need to repeat this for every client unless they are all on the same payment method. If they are on the same payment method, you could theoretically remove the WHERE clause from the end of the SQL command and run it for all client all at once.

After you have run the MySQL update, you will need to go into each customer and go to the profile tab in WHMCS. In the payment method, select "Credit Card" and click save. Even if Credit Card is already displayed, you will need to click save in order for the payment processing to work.

Now you should be able to process payment on the outstanding invoices.

Hope this helps someone.

[Si]

Thanks for this, but it didn't work for me.

I have a client who used to pay via master card.  Now, in the admin area, he has no credit card listed - just NiftyDirect Debit (GoCardless) under PAY METHODS.

His default payment method is set to Gocardless (and has been for months).  So all invoices are generated with 

BUT, when I view an invoice (which has Direct Debit as the payment option) and then click ATTEMPT CAPTURE - credit card details appear in the modal.   ?

I've run the SQL query above for this client, and it executes 1 line (as expected) but nothing changes.  The client still shows a credit card on the invoice, but not on the client account itself.

Even more strange, when I login as the customer and view PAYMENT METHODS, the card shows up there.  But if I try to delete it as the client, it generates the error:  

Oops!

Something went wrong and we couldn't process your request.

then a whole list of Remote Storage Errors in php files.

It's just a complete mess.

BTW - I'm currently running 7.8.1 and all of the 3 hot fixes available through this community .

Really reluctant to update to 7.8.2 until I know for sure all of this is not going to become an even bigger mess.

Edited September 6, 2019 by Si

[Si]

This just gets worse.  Upgraded to 7.8.2 as none of the hot fixes solved all of the issues.  The remote transactions are now working. BUT  Now I have a REALLY STRANGE situation.

Can someone from WHMCS answer this please?  Or has anyone else come across this?

New customer of 6 months. Never paid via card, only debit card through GoCardless.  At some point since the upgrade to 7.8 or 7.8.1 or 7.8.2 (or during the upload of the 3 hot fixes) - this has now appeared on his account:

How on earth did that appear on a clients account?  I can't remove it remotely.  That fails.  I removed it in the DB and then could no longer access the clients profile and he couldn't  access payment methods in his client area.  So 

1)  how can I get rid of it safely and
2)  I had to login to his client account to manually pay his invoice via Direct Debit and 
3)  There are still random direct debit invoices not being processed via the cron (some are, some aren't) and I cannot for the life of me find out what is the common cause. 

All of this started from the 7.8 upgrade.

Edited September 7, 2019 by Si

[xyzulu]

You need to remove the card from two database tables.. 

 

.. tblcreditcards and .... tblpaymentmethods

I have the same issue.. WHMCS know about this since I opened a ticket with the when 7.8.0 was released.

 

Edited September 7, 2019 by xyzulu

[Si]

13 minutes ago, xyzulu said:

You need to remove the card from two database tables.. 

 

.. tblcreditcards and .... tblpaymentmethods

I have the same issue.. WHMCS know about this since I opened a ticket with the when 7.8.0 was released.

 

Thanks, but I tried that.  When I delete the card from the tblcreditcards I can no longer load the customer in whmcs admin.   It doesn't appear in tblpaymentmethods

Edited September 7, 2019 by Si