Skip to main content

4.0.10 Release Notes

Version 4.0.10 is a patch release with two bug fixes and two additions.

Download 4.0.10

Bug Fixes​

Orders Paid With Affirm and Other Redirect-Based Payment Methods Now Complete More Reliably​

Orders paid with Affirm and other redirect-based payment methods are confirmed through two channels: a Stripe webhook, and the checkout page completing after the customer is redirected back from the payment provider. Previously, only card payments deferred to the webhook so it wouldn't race the redirect-based confirmation; every other payment method processed the webhook immediately. This meant both channels could occasionally send a duplicate transactional email for the same order, and if the redirect back to the store was interrupted, for example by a network error or the customer's browser closing before checkout finished loading, the webhook could also stand down without the order ever being completed.

The same deferral behavior previously used only for card payments now applies to all redirect-based payment methods, including Affirm, Klarna, and Afterpay. This prevents the duplicate transactional email, and ensures the webhook reliably completes the order's status update and transactional emails if the redirect back to the store is interrupted.

Cancelled or Refunded Orders Could Be Reactivated by a Delayed Webhook​

In rare cases, a Stripe webhook confirming a payment could arrive after the corresponding order had already been cancelled or refunded in WooCommerce, for example when a delayed authorization capture succeeds after staff have already manually cancelled the order. The plugin would complete the order again as if it were newly paid, moving a cancelled or refunded order back to a paid status.

Webhook processing now checks the order's current status before completing it, and no longer acts on orders that are cancelled or refunded. Orders in a failed status are unaffected by this check, since a failed order can still complete successfully if the same payment is retried and later succeeds.

Additions​

Universal Payment Method Now Detects the Selected Payment Method More Reliably​

When Universal Payment Method is the active gateway, the plugin determines which specific payment method the customer selected, such as a credit card, so it can apply that method's own settings, including manual capture. Previously this was detected only from an event that fires after the customer interacts with the payment fields, so in rare cases checkout could be submitted before the selection was detected, and the payment was processed using Universal Payment Method's own settings instead of the selected method's settings.

The plugin now also confirms the selected payment method immediately before checkout is submitted, in addition to the existing detection, so the correct method's settings are applied consistently.

Migration Support Added for Stripe Plugin by Themehigh​

Stores moving from Stripe Plugin by Themehigh now have their existing payment method and order data recognized and converted automatically, with no action required, following the same migration pattern already used for other supported plugins. This includes recognizing that plugin's gateway IDs during conversion, adopting existing Stripe customer records, and resolving the correct saved payment method for subscription renewals.

New Filters​

FilterDescription
wc_stripe_webhook_blocked_order_statusesModify the list of order statuses that a Stripe webhook is not allowed to move an order out of. Defaults to cancelled and refunded.