Skip to content
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

Open
zoemyers opened this issue Aug 3, 2022 · 21 comments · May be fixed by #3483
Assignees
Labels
component: UPE Issues related to adding UPE functionality priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. type: bug The issue is a confirmed bug.

Comments

@zoemyers
Copy link

zoemyers commented Aug 3, 2022

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:

There is an option within the settings to only authorize charges. If you’ve opted in to the new Stripe checkout experience this option won’t be available to you.

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:

  1. Set up a basic WooCommerce & Stripe test site
  2. Configure Stripe to connect to an account with live transactions enabled.
  3. Configure Stripe to live mode and enable New Checkout Experience. Make sure Issue an authorization on checkout, and capture later is unchecked. Save settings.
  4. On the front end, place a test order and purposely have the card decline. I used the Stripe test card 4242 in live mode to have it decline on purpose. Do not complete the order payment successfully.
  5. Visit the WooCommerce > Orders page and locate the test order. It will be on hold and have an open authorization waiting to be captured.

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

Markup 2022-08-03 at 09 16 15

Markup 2022-08-03 at 09 19 43

Markup 2022-08-03 at 09 20 57

Environment (please complete the following information):

  • WordPress Version 6.0.1
  • WooCommerce Version 6.7.0
  • Stripe Plugin Version 6.5.1
  • Browser Chrome Version 103.0.5060.114 (Official Build) (arm64)
  • Just WooCommerce and Stripe
@zoemyers
Copy link
Author

zoemyers commented Aug 3, 2022

5371817-zen

@dougaitken dougaitken added priority: low The issue/PR is low priority—not many people are affected or there’s a workaround, etc. component: UPE Issues related to adding UPE functionality labels Jan 20, 2023
@seanconklin
Copy link

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 requires_payment_method error.

@Octolus
Copy link

Octolus commented Mar 7, 2023

I am having same issue, Apple Pay stuck on requires_payment_method.

@tinsilver
Copy link

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
WooCommerce version: 7.8.0
Wordpress version: 6.2.2

@tinsilver
Copy link

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.

@diegocurbelo diegocurbelo added priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. type: bug The issue is a confirmed bug. and removed priority: low The issue/PR is low priority—not many people are affected or there’s a workaround, etc. labels Jun 28, 2023
@reandimo
Copy link

reandimo commented Jul 14, 2023

@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 Incomplete on the Stripe Dashboard.

Order Note:
"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."

Pls have a look at this issue.

@glagonikas
Copy link

Same note here, and Charge ID is also blank

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.

Looking at our notes, it seems to have started around April 2022 and it affects just a small number of orders.

@Codingkarttryparcel
Copy link

any update on this? i am getting the same error

@rogercoathup
Copy link

rogercoathup commented Aug 7, 2023

We're seeing the same problem since updating to 7.4.2

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.")

WooCommerce Stripe Gateway version: 7.4.2
WooCommerce version: 7.7.2
Wordpress version: 6.2.2

We also suspect it may relate to saved cards

@Darkace01
Copy link

I am having the same issue on mu site

@Darkace01
Copy link

I checked the log and it's showing the transaction is successful but on woocommerce it's on-hold

@StenderIternum
Copy link

StenderIternum commented Jan 15, 2024

We have the same issue, even without the new experience - did anybody find a fix for this?

WooCommerce Stripe Gateway Version 7.9.0
WooCommerce Version 8.4.0
Wordpress : 6.4.2

@shameemreza
Copy link

Another report: 7760044-zen

@mattallan
Copy link
Contributor

I cannot reproduce this on the latest version.

I could however this issue on older versions of our Stripe plugin:

  • Confirmed the original report: With Stripe 6.5.1, live account, authorize and capture disabled, UPE enabled, purchase with a declining card
    Image
  • This comment: Stripe 7.9.0, live account, authorize and capture disabled, UPE disable, purchase with a declining card
    • I could still reproduce the issue on Stripe 7.9.0 with UPE enabled, but unlike this report, I couldn't reproduce it with UPE disabled.

It looks like our deferred intent changes indirectly fixed this issue, so I will close it for now.

For reference, I checked the following:

  • 👍 UPE enabled, live account, declining card. No on-hold order, no intent pending authorization/capture.
  • 👍 UPE disabled, live account, declining card. No on-hold order, no intent awaiting capture.
  • 👍 UPE enabled, test account, declining card. No on-hold order, no intent awaiting capture.
  • 👍 UPE disabled, test account, declining card. No on-hold order, no intent awaiting capture.

If you're still having this issue after upgrading to the latest version please re-open the issue and I'll investigate further

@mattallan mattallan self-assigned this Apr 9, 2024
@ricardoaraujo330
Copy link

Is this issue closed? Still happening to me two years later 😕

@Darkace01
Copy link

I had to disable "Issue an authorization on checkout, and capture later" then created a script to auto complete stripe payments.

add_action('woocommerce_order_status_changed', 'ts_auto_complete_by_payment_method');
function ts_auto_complete_by_payment_method($order_id)
{
  
  if ( ! $order_id ) {
        return;
  }
  global $product;
  $order = wc_get_order( $order_id );
  
  if ($order->data['status'] == 'processing') {
        $payment_method=$order->get_payment_method();
        if ($payment_method!="cod")
        {
            $order->update_status( 'completed' );
        }
      
  }
  
}

@rvisima
Copy link

rvisima commented Sep 19, 2024

This just started happening on one of our sites today out of the blue. What's going on?

Woo 9.3.1
Stripe gateway 8.7.0

@mattallan
Copy link
Contributor

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.

@james-allan
Copy link
Contributor

@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:

  • Are the orders you're seeing this on subscription renewal payments, or orders your customers are placing on the checkout?
  • Which payment method is the customer using? Are they using a credit/debit card, or SEPA or another payment type?
  • Is your store set to authorize and capture payments? You can find this setting in your Stripe plugin settings at WooCommerce → Settings → Payments → Stripe → Settings (see screenshot below).

Screenshot 2024-10-01 at 3 14 29 pm
Issue an authorisation on checkout, and capture later setting

  • Is your store using the legacy checkout experience? You can find this setting at the bottom of your Stripe plugin settings at WooCommerce → Settings → Payments → Stripe → Settings (see screenshot below).

Screenshot 2024-10-01 at 3 23 33 pm
Enable the legacy checkout experience setting

@rvisima
Copy link

rvisima commented Oct 1, 2024

  1. Not a subscription. Just a regular item through the regular checkout process.
  2. Credit card.
  3. "Authorize and capture later" is OFF (unchecked)
  4. Legacy experience is OFF (unchecked)

@mattallan
Copy link
Contributor

I'm wondering if the newer reports of this issue are due to this other similar bug: #3517 (fixed in #3520)

tl;dr
When a customer uses a credit card that requires authentication (sca/3ds) and that payment fails, then they try again. The order was incorrectly being marked as on-hold with this incorrect order note.

We've got a fix that will be available in the next release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: UPE Issues related to adding UPE functionality priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. type: bug The issue is a confirmed bug.
Projects
None yet