-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Checkout Experience: Failed Payments Start New Orders with Manual Authorization Even with Option Disabled #2404
Comments
5371817-zen |
Somebody in the WordPress.org support section routed my ticket from October to this one, originally written up here: https://wordpress.org/support/topic/occasional-order-coming-in-on-hold-when-using-the-new-checkout-experience/#new-topic-0 However, I see one major difference, which might be clues for this one (related?). In our case, the new checkout experience with immediate capture (same as above) was failing every time that somebody used ApplePay (different from above). The order would come in On Hold status with the same order note traces as above, but the cards were not actually declined and our Stripe logs indicated the |
I am having same issue, Apple Pay stuck on requires_payment_method. |
I am having a similar issue - the orders go straight to on hold and the order notes show the card was authorised but payment not taken ("Stripe charge authorized (Charge ID: ). Process order to take payment, or cancel to remove the pre-authorization. Attempting to refund the order in part or in full will release the authorization and cancel the payment. Order status changed from Pending Payment to On Hold.") However, differently to the above, we aren't using Apple Pay or the new checkout experience. WooCommerce Stripe Gateway version: 7.4.1 |
Further to my last message, we've been experimenting and this seems to be related to customers who have an expired saved payment method. When they try and place an order, the checkout picks up the saved payment method but when they complete the checkout there is no error message displayed to the user. Instead they see the order confirmation screen, but the payment is not captured and the order is set to on-hold. This is a serious customer facing issue and we have been receiving complaints. Please look into this issue as a priority. |
@tinsilver I had the same issue with a customer's site with the latest update and I had to rollback to version 7.2.1 to solve it, the exact same message and the payment intent shows as Order Note: Pls have a look at this issue. |
Same note here, and
Looking at our notes, it seems to have started around April 2022 and it affects just a small number of orders. |
any update on this? i am getting the same error |
We're seeing the same problem since updating to 7.4.2
WooCommerce Stripe Gateway version: 7.4.2 We also suspect it may relate to saved cards |
I am having the same issue on mu site |
I checked the log and it's showing the transaction is successful but on woocommerce it's on-hold |
We have the same issue, even without the new experience - did anybody find a fix for this? WooCommerce Stripe Gateway Version 7.9.0 |
Another report: 7760044-zen |
I cannot reproduce this on the latest version. I could however this issue on older versions of our Stripe plugin:
It looks like our deferred intent changes indirectly fixed this issue, so I will close it for now. For reference, I checked the following:
If you're still having this issue after upgrading to the latest version please re-open the issue and I'll investigate further |
Is this issue closed? Still happening to me two years later 😕 |
I had to disable "Issue an authorization on checkout, and capture later" then created a script to auto complete stripe payments.
|
This just started happening on one of our sites today out of the blue. What's going on? Woo 9.3.1 |
Thanks everyone for reporting that this issue is still present in the latest Stripe version. When I tested this back in April, I couldn't reproduce it, but it's possible that I missed something, or the bug may have been reintroduced by recent changes 🤔. I'll re-open this issue and investigate it further. |
@rvisima and @ricardoaraujo330 can you provide any further information about your set up? We have some proposed changes (#3483) that should resolve the originally reported issue, however, we think there might be more to this given you're still experiencing the issue recently. To be sure we've caught the issue you're experiencing, I have a few follow up questions:
|
|
I'm wondering if the newer reports of this issue are due to this other similar bug: #3517 (fixed in #3520) tl;dr We've got a fix that will be available in the next release. |
Describe the bug
When the Stripe extension is in Live Mode, and New Checkout Experience is enabled under Experimental Features, and
Issue an authorization on checkout, and capture later
is unchecked, a customer makes a purchase and their card is declined.An order is created, a payment intent is created and authorized to charge, and the order status is "on hold." The order notes reflect "Stripe charge authorized (Charge ID: pi_XXXXXXXXXXXXXXX). Process order to take payment, or cancel to remove the pre-authorization. Attempting to refund the order in part or in full will release the authorization and cancel the payment. Order status changed from Pending payment to On hold." This does not seem to obey the setting to capture immediately.
Per the documentation:
This seems to indicate manual capture isn't the expected behavior here with that option unchecked and New Checkout Experience enabled.
With Test Mode enabled, and/or the New Checkout Experience disabled, failed payments due to the card declining are ignored and do not create an order, which seems to obey the setting to capture immediately.
To Reproduce
Steps to reproduce the behavior:
Issue an authorization on checkout, and capture later
is unchecked. Save settings.Expected behavior
I would expect the New Checkout Experience to respect the setting
Issue an authorization on checkout, and capture later
or to default to capture immediately.Screenshots
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: