Dynamic Stripe Gateway adding extra "failed" status entry upon a declined payment - v9.0.9 - 9.1

[auxilex]

We are having an issue with the new dynamic Stripe gateway where it adds an extra "failed" entry in the transaction history status. This becomes a problem as a duplicate "Credit Card Payment Failed" email is then sent. On the legacy Stripe module it would only post the "declined" entry and was working properly. Does anyone know why this might be happening? Are others seeing this as well? Any help is greatly appreciated!

Edited Tuesday at 12:00 AM by auxilex

[Waqas Ahmed Waseer]

Not seen this exact one myself, but a duplicate "failed" row right after a "declined" row almost always means WHMCS is hearing about the same decline twice: once from the API response when it tries the charge, and once more from a Stripe webhook a few seconds later. The legacy module and the new one don't record those the same way, so it can show up after the switch even though nothing else changed.

Things I'd check, in this order:

1. Billing > Gateway Log. Find one affected invoice and look at the timestamps on the two entries. If one came from the charge attempt and the second arrived a little later from a webhook, that's your duplicate.

2. In the Stripe dashboard under Developers > Webhooks, look at how many endpoints point to your WHMCS install. If you moved from the legacy module, the old endpoint is often still registered next to the new one, so every payment_intent.payment_failed event gets sent twice. Remove the one the new gateway doesn't use, then let a test payment fail with Stripe's decline test card to confirm only one row and one email come through.

3. If there's only one endpoint and it still happens, open a ticket with WHMCS and attach both gateway log entries for the same invoice. That's what they'll ask for first, and if it's a module bug it gets confirmed faster.

While you wait on a fix, you can stop the second email with an EmailPreSend hook: when the template is "Credit Card Payment Failed", check whether the same email went out for that invoice in the last few minutes and return abortsend => true if it did. It doesn't fix the extra transaction row, but your clients stop getting two failure emails.