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 October 27 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.

[auxilex]

The logs are showing both these entries are coming from the new Stripe Dynamic Payments module. The only endpoint is stripe_dynamic.php. We also updated to the latest Stripe API version for testing. We did find that removing the payment.failed destination event from within Stripe stops the "failed" WHMCS entry and the declined charge entry still shows. We are still testing to see whether this causes an issue as having 3 destination events seems to be the default. Is anyone  using charge.failed, charge.succeeded, and payment_method.updated as destination events and not seeing the "failed" entry on declined payments?

[Waqas Ahmed Waseer]

Thanks for checking the logs, that narrows it down a lot. If both rows come from stripe_dynamic.php and that's the only endpoint, it isn't leftover config on your side. The module is recording the decline from the charge attempt and then recording the charge.failed webhook as a second event for the same attempt. I'd still put that in a ticket with WHMCS, with the two gateway log entries for one invoice attached, so it gets fixed in the module rather than everyone working around it.

On dropping that event: whether it's safe depends on what you take through Stripe. For card payments that WHMCS attempts itself (the cron capture, or a client clicking Pay Now), the decline comes back in the API response right away, so the webhook only repeats what WHMCS already knows. Where the webhook earns its keep is a payment that fails later, after the charge call has already returned, like an ACH or SEPA debit that bounces a few days on. Without it, as far as I can tell, that invoice would just stay unpaid with no failure email and nothing in the gateway log, and you'd only spot it in the Stripe dashboard.

So if you're cards only, removing it is a reasonable stopgap. Run one test with Stripe's generic decline test card (4000 0000 0000 0002) and one successful payment to confirm you get one failed row, one email, and paid invoices still go through. If you offer bank debits, I'd keep the event and stop the duplicate email with an EmailPreSend hook instead. Either way, make a note to add the event back once WHMCS ships a fix.