MODULE-7114 Stripe statement descriptor not being set with 7.8.2

[Tom Catchesides]

I submitted a support ticket about this a couple of hours ago but am hoping that someone might be able to answer this more quickly here.

We upgraded to WHMCS 7.8.2 at the weekend to ensure compliance with SCA via WHMCS's own Stripe gateway. Since then, the statement descriptors on our customers' bank statements read "FALSE" for regular subscription payments. I'm obviously concerned that this is going to lead to unnecessary chargebacks. 

We haven't changed any settings at the Stripe end and have a default statement descriptor set on there. In WHMCS, the statement descriptor is set to "{CompanyName}" and our company name field is set.

Has anyone else seen this problem with WHMCS 7.8 and Stripe? Does anyone have any ideas for workarounds?

[aquiss]

 

[zomex]

I reported a similar issue on the thread above which is being investigated.

My issue was the description within my Stripe account showing the transaction ID rather than the invoice number used by WHMCS.

I wasn't aware/I don't think it's been reported of showing false on clients statements. If this is another bug it is much more serious.

[Tom Catchesides]

1 hour ago, zomex said:

My issue was the description within my Stripe account showing the transaction ID rather than the invoice number used by WHMCS.

The description in Stripe is fine for us. It's the statement descriptor that's a serious problem. I've attached screenshots of what I see in our Stripe dashboard for a charge made this week compared to one made last month with WHMCS 7.6.

[Tom Catchesides]

FYI, WHMCS have acknowledged the problem via my support ticket and say that they're working on a fix. Case number MODULE-7114 .

[SubZeroFX]

It's been a while now - when we can expect a fix?

[WHMCS John]

Hi @SubZeroFX,

This is currently planned to be included in our next maintenance release (v7.8.3) before the end of the month.

[Tom Catchesides]

7 hours ago, WHMCS John said:

Hi @SubZeroFX,

This is currently planned to be included in our next maintenance release (v7.8.3) before the end of the month.

It's very disappointing to hear that it might be another 10 days until this bug is fixed, because that will mean that this problem is still affecting us three weeks after I first reported it.

Upgrading to WHMCS 7.8 has been a frustrating and disappointing experience. My company felt forced into the upgrade because of the need for SCA compliance, but a number of frustrating Stripe-related bugs made it into the release. This particular bug is especially frustrating because it's something that directly affects our customers.

[wintech2003]

And it looks like 7.8.3 didn't resolve it: 

 

[Tom Catchesides]

18 hours ago, wintech2003 said:

And it looks like 7.8.3 didn't resolve it: 

The problem that I reported in the original post was fixed by 7.8.3: WHMCS is now setting the Stripe statement descriptor correctly.

[DennisHermannsen]

It isn't for us. Stripe is still not setting the correct description for all transactions.

[wintech2003]

5 hours ago, Tom Catchesides said:

The problem that I reported in the original post was fixed by 7.8.3: WHMCS is now setting the Stripe statement descriptor correctly.

Does this apply even on payments done manually by the customers themselves? 

[Tom Catchesides]

17 hours ago, wintech2003 said:

Does this apply even on payments done manually by the customers themselves? 

For transactions made by customers via our shopping cart, the statement descriptor is being set to "{StripeStatementDescriptorPrefix} SHOPPING CART". No invoice number, but we can at least identify ourselves.

[wintech2003]

Thanks for clarifying. I don't consider this "fixed".

It was working fine before the update, and it is working fine for captures done by the cron, so manual transactions should also show up properly with the invoice number and only {StripeStatementDescriptorPrefix} without SHOPPING CART next to it. Just like it does for transactions via the cron.

[WHMCS John]

Hi all,

As a separate topic has been started to discuss this latest case (and already linked), I'm going to close this topic to further discussion.

Please continue over at: