webhook failure resulting in payment failure

[WillBrubaker]

Describe the bug In 4617767-zen the user reports that they are experiencing failed payments. The Stripe logs indicate that:

====Stripe Version: 5.9.0====
====Start Log====
Canceled webhook abort: Order was not processed by Stripe: 4596
====End Log====

I'm not clear if this is the same as #1196

To Reproduce Steps to reproduce the behavior:

1. I guess use Bancontact

Expected behavior That a valid payment results in an order marked as paid rather than canceling for non-payment.

Screenshots If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

• WordPress Version
• WooCommerce Version
• Stripe Plugin Version
• Browser [e.g. chrome, safari] and Version
• Any other plugins installed

Additional context Add any other context about the problem here.

[cesarcosta99]

@WillBrubaker I've performed a checkout with Bancontact test on a fresh WP and plugin installations with both the new checkout experience enabled/disabled and the two tests passed without any kind of errors. I'd appreciate if the user could perform a conflict test and provide more details so we can try to reproduce it.

[Hotpuppy]

I have the same issue where a small number of orders timeout and the payment fails to post back.

In reviewing the transactions there is a pattern. The customer has a payment failure. Either bad CVC, bad AVS, or just a charge decline. They typically correct this in a couple of minutes and the charge completes successfully on Stripe.

In WC the transaction shows as "pending payment" and then "failed" because the payment did not post back in a timely manner. These either require a manual correction in WC, or a refund in Stripe. Often the customer is upset as well. Especially if it's not manually caught before they get their statement. My charges are all reasonably small ($6-$10) but it seems like there should be a more graceful way to handle these payment situations.

I found a stackoverflow post that suggested the timeout is set to 60 seconds in the PHP code of the plugin. I have not personally verified this, but I'm mentioning it in case it's helpful.