Payments failing with 'requires_payment_method' error on some orders after updating to WooCommerce 7.6.0 #2608

sefod · 2023-05-02T16:32:11Z

Describe the bug
Starting on V7.6.0, some (not all) payments are failing to send the card data to Stripe ("source"), and therefore ending in a "requires_payment_method" error, where the order fails to process the payment and gets to On Hold.

The result behavior is similar as this issue: #2404
except that it's:

Not using the New Checkout experience
Not using Apple Pay/Google pay

The error did not happen at all before the update to 7.6.0

To Reproduce

A Registered (Logged) Customer creates an order and chooses Stripe Card (Not Google/Apple pay) as payment method
The error happens only in certain orders, but I haven't been able to identify what is that triggers. Will expand in further comments if I can identify that.
Most of the failed orders are from customers that returned, and had other successful orders with those (saved) cards, so the card itself doesn't seem to be the issue.

Expected behavior
The order goes to Processed/Completed

Screenshots

(Note the empty Charge ID in the order note above)

Environment (please complete the following information):

WordPress Version: 6.2
WooCommerce Version: 7.6.0
Stripe Plugin Version: 7.3.0
Browser [e.g. chrome, safari] and Version: Multiple
Any other plugins installed:
Gravity Forms | | by Gravity Forms – 2.7.4
Action Scheduler | | by Automattic – 3.5.4
Advanced Custom Fields | | by WP Engine – 6.1.4
Akismet Anti-Spam | | by Automattic – 5.1
WP AutoTerms | | by WP AutoTerms – 2.5.0
WP Engine Smart Plugin Manager | | by WP Engine – 5.13.28
CartFlows Pro | | by CartFlows Inc – 1.11.10
CartFlows | | by CartFlows Inc – 1.11.10
Custom Start Date For WooCommerce Subscriptions | | by Launch & Sell – 1.3.10
Dante Framework | | by Swift Ideas – 1.0.13
DCO Comment Attachment | | by Denis Yanchevskiy – 2.4.0
Yoast Duplicate Post | | by Enrico Battocchi & Team Yoast – 4.5
Dynamic.ooo - Dynamic Content for Elementor | | by Dynamic.ooo – 2.9.3
WP E-Signature Business add-ons | | by ApproveMe.com – 1.8.1
WP E-Signature | | by ApproveMe.com – 1.8.1.1
Extras for Elementor | | by Namogo – 2.2.51
Elementor Pro | | by Elementor.com – 3.12.3
Elementor | | by Elementor.com – 3.12.2
Events Manager Pro | | by Pixelite – 3.1.3
Events Manager | | by Pixelite – 6.3
FluentCRM - Marketing Automation For WordPress | | by WP Email Newsletter Team - FluentCRM – 2.8.01
FluentSMTP | | by FluentSMTP & WPManageNinja Team – 2.2.4
WP-FormAssembly | | by FormAssembly / Drew Buschhorn – 2.0.8
Gravity Forms Mailchimp Add-On | | by Gravity Forms – 5.2.0
Gravity Forms Stripe Add-On | | by Gravity Forms – 4.3
Gravity Forms Zapier Add-On | | by Gravity Forms – 4.2
WPCode Lite | | by WPCode – 2.0.10
Intercom | | by Intercom – 2.6.5
JetEngine | | by Crocoblock – 3.1.4
LearnDash LMS - Course Grid | | by LearnDash – 2.0.7
LearnDash Licensing & Management | | by LearnDash – 1.2
LearnDash LMS - Notifications | | by LearnDash – 1.6.1
LearnDash LMS - WooCommerce Integration | | by LearnDash – 1.9.6
Lucky Orange | | by Lucky Orange – 2.1.3
Mailchimp for WooCommerce | | by Mailchimp – 2.8.3
Meta Box | | by MetaBox.io – 5.6.18
PixelYourSite PRO | | by PixelYourSite – 9.5.5
Pods - Custom Content Types and Fields | | by Pods Framework Team – 2.9.13
Blubrry PowerPress | | by Blubrry – 10.0.7
Redirection | | by John Godley – 5.3.10
Rank Math SEO | | by Rank Math – 1.0.112
LearnDash LMS | | by LearnDash – 4.5.3
ShortPixel Image Optimizer | | by ShortPixel - Convert WebP/AVIF & Optimize Images – 5.2.1
Simple Share Buttons Adder | | by Simple Share Buttons – 8.4.7
SUMO Payment Plans | | by Fantastic Plugins – 10.1
Uncanny Automator Pro | | by Uncanny Owl – 4.11.0.1
Uncanny Automator | | by Uncanny Automator, Uncanny Owl – 4.14.0.1
User Switching | | by John Blackbourn & contributors – 1.7.0
Woo Custom Emails Per Product | | by Alex Mustin – 2.2.9
WooEvents | | by ExThemes – 3.3.4
WooCommerce Appointments | | by BookingWP – 4.16.1
WP E-Signature - WooCommerce by ApproveMe.com | | by ApproveMe.com – 1.7.7
WooCommerce Direct Links | | by Piotr Krzyzek – 1.0.1
WooCommerce Stripe Gateway | | by WooCommerce – 7.3.0
WooCommerce Subscriptions - Preserve Billing Schedule | | by Prospress Inc. – 1.0.0
WooCommerce Subscriptions | | by WooCommerce – 5.0.1
WooCommerce Xero Integration | | by WooCommerce – 1.7.56
WooCommerce | | by Automattic – 7.6.1
WP All Export Pro | | by Soflyy – 1.8.3
WP All Import Pro | | by Soflyy – 4.7.9
WP Crontrol | | by John Blackbourn & crontributors – 1.15.2
WP Fusion | | by Very Good Plugins – 3.41.7
WP All Export - WooCommerce Export Add-On Pro | | by Soflyy – 1.0.6
WP All Import - User Import Add-On Pro | | by Soflyy – 1.1.8
WP All Import - WooCommerce Import Add-On Pro

sefod · 2023-05-02T16:40:17Z

@reykjalin Maybe you have some clues about this?
I can see that there are contributions of yours to includes/abstracts/abstract-wc-stripe-payment-gateway.php around latest versions.

Thanks and hope you don't mind me tagging you 😄

Heres a copy of a failed request (with replaced values):

{ "description": "My Site Name - Order 114433", "capture_method": "automatic", "metadata": { "order_id": "114433", "site_url": "https://www.mysite.com", "customer_email": "[email protected]", "save_payment_method": "true", "customer_name": "Customer1 Customer1" }, "statement_descriptor": "My Site Name", "setup_future_usage": "off_session", "customer": "cus_LXXXXXXXXXXXN", "currency": "usd", "amount": "4500", "payment_method_types": { "0": "card" } }

And here's one that successfull, for the same product, different qty (note the difference in order, maybe says something?):

{ "description": "My Site Name - Order 114428", "capture_method": "automatic", "metadata": { "order_id": "114428", "site_url": "https://www.mysite.com", "customer_email": "[email protected]", "save_payment_method": "true", "customer_name": "Customer2 Customer2" }, "source": "src_1XXXXXXXXXXXXXXXXXXXXXXv", "currency": "usd", "customer": "cus_8XXXXXXXXXXXXQ", "setup_future_usage": "off_session", "statement_descriptor": "My Site Name", "amount": "1000", "payment_method_types": { "0": "card" } }

reykjalin · 2023-05-03T01:20:54Z

Starting on V7.6.0,

The latest version of the plugin is v7.3.0, I just want to sure that's the actual version installed on your site instead of a v7.6.0 that would not be from us 🙂

some (not all) payments are failing to send the card data to Stripe ("source")

Hmm, it's interesting that some card payments are still using the source parameter. We removed usage of the Source API in favor of the Payment Methods API in v7.3.0 to add support for new regulations in India.

Unfortunately it's a little bit difficult for us to figure out exactly what's going on, especially given the amount of plugins installed on your store. The first step would be to figure out a way to reproduce the issue, and then go through conflict testing to make sure the issue isn't being caused by another plugin — perhaps another plugin that's expecting the plugin to use Sources instead of Payment Methods and hooking into the payment process somehow?

We have never run into an issue like this during our testing or development, so I'm not sure this is an issue with the Stripe plugin itself. We'll keep this issue open, so please let us know if you find out any more information or figure out how to reproduce the issue!

sefod · 2023-05-03T10:11:36Z

Thanks for your input.
The version that started to break this was the WooCommerce 7.6.0 update (April 13/14 2023), not the WooCommerce Stripe one (7.3.0 Currently)

I've done some tests myself and didn't manage to replicate the error, but it was still happening until yesterday.
I'll try to replicate this consistently and get back to you, but if in the meantime you have any ideas, I'm open.

Babylon1999 · 2023-05-08T16:23:58Z

Same story in zd-6271204 and 6270414

However, in Stripe the payment is successful it's just the order status that's not changing.

jacoswan · 2023-05-16T12:16:16Z

Also in 6295231-zen and same as above, Stripe shows successful but the WC order shows not.

Could it be related/similar to #2559 ?

igorhereira · 2023-05-16T12:30:07Z

6295050-zen
6295479-zen

sefod · 2023-05-16T13:03:57Z

@reykjalin I have a new clue on this:

So far, all the failed transactions were with customers that had old card tokens ('card_' instead of 'src_') saved, and I suspect that because of that, the function add_payment_method_to_request_array is not adding the source component to the payment intent request.

I'm not sure if that's the actual function that causes the issue, since if you search 'src_' in the plugin code you'll find a few instances of strpos( $payment_method_id, 'src_' ) that were not there on previous versions of the plugin.

I suspect that because old customers still have cards on file that have the old format, the plugin is not sending the right data and the payment intent is failing.

I've compared the requests of all the failed payments and the successful ones, and the only difference is in the SOURCE, as shown in #2608 (comment)

I'm still unsure why this doesn't seem to be the case for subscription renewal payments, since I had no issues with that. Maybe those go through a different set of functions, but I think this can be a clue to follow.

SteStory · 2023-05-16T13:17:14Z

I have a similar error but in my case doesnt matter its guests checking out and still seeing orders set as on hold:
https://wordpress.org/support/topic/orders-placed-on-hold/#new-topic-0

Also in my case Stripe is not taking any payment and no money is leaving accounts.

In my instance, i've created a staging site with all plugins and themes disabled except WooCommerce and WooCommerce Stripe Gateway:
https://staging.turnerhallcampsite.co.uk/

Initially when checking out I get an error: "Payment processing failed. Please retry." but if you retry the payment goes through to "Thank you. Your order has been received."

However, in the back end, it is set to "on hold" with the 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 Failed to On hold."

In WooCommerce>Status>Logs, the log for the payment says:

_**>
2023-05-16T13:11:08+00:00 DEBUG
====Stripe Version: 7.4.0====
====Start Log====
payment_methods/pm_1N8NehH2KHLE1SgkLRyGBG9d
====End Log====

2023-05-16T13:11:08+00:00 DEBUG
====Stripe Version: 7.4.0====
====Start Log====
customers request: Array
(
[email] => [email protected]
[description] => Name: Ste Story, Guest
[name] => Ste Story
[metadata] => Array
(
)

[preferred_locales] => Array
    (
        [0] => en-US
    )

)

====End Log====

2023-05-16T13:11:08+00:00 DEBUG
====Stripe Version: 7.4.0====
====Start Log====
Error: stdClass Object
(
[token_id] =>
[customer] =>
[source] =>
[source_object] =>
[payment_method] =>
)

====End Log====

2023-05-16T13:11:30+00:00 DEBUG
====Stripe Version: 7.4.0====
====Start Log====
payment_methods/pm_1N8Nf3H2KHLE1SgkvTCYsrkX
====End Log====

2023-05-16T13:11:30+00:00 DEBUG
====Stripe Version: 7.4.0====
====Start Log====
customers request: Array
(
[email] => [email protected]
[description] => Name: Ste Story, Guest
[name] => Ste Story
[metadata] => Array
(
)

[preferred_locales] => Array
    (
        [0] => en-US
    )

)

====End Log====

2023-05-16T13:11:30+00:00 DEBUG
====Stripe Version: 7.4.0====
====Start Log====
Error: stdClass Object
(
[token_id] =>
[customer] => cus_NuC3GZlMlknOl2
[source] =>
[source_object] =>
[payment_method] =>
)

====End Log====

2023-05-16T13:11:33+00:00 DEBUG
====Stripe Version: 7.4.0====
====Start Log====
payment_methods/pm_1N8Nf7H2KHLE1Sgk6F9UA5Rg
====End Log====

2023-05-16T13:11:34+00:00 DEBUG
====Stripe Version: 7.4.0====
====Start Log====
customers request: Array
(
[email] => [email protected]
[description] => Name: Ste Story, Guest
[name] => Ste Story
[metadata] => Array
(
)

[preferred_locales] => Array
    (
        [0] => en-US
    )

)

====End Log====

2023-05-16T13:11:34+00:00 DEBUG
====Stripe Version: 7.4.0====
====Start Log====
Info: Begin processing payment for order 9375 for the amount of 0.50
====End Log====

2023-05-16T13:11:34+00:00 DEBUG
====Stripe Version: 7.4.0====
====Start Log====
payment_intents request: Array
(
[amount] => 50
[currency] => gbp
[description] => Turner Hall Campsite - Order 9375
[metadata] => Array
(
[customer_name] => Ste Story
[customer_email] => [email protected]
[order_id] => 9375
[site_url] => https://staging.turnerhallcampsite.co.uk
)

[capture_method] => automatic
[payment_method_types] => Array
    (
        [0] => card
    )

[payment_method] => pm_1N8Nf7H2KHLE1Sgk6F9UA5Rg
[customer] => cus_NuC3y8Akm8Ivqs
[statement_descriptor] => Turner Hall Campsite

)

====End Log====

2023-05-16T13:11:34+00:00 DEBUG
====Stripe Version: 7.4.0====
====Start Log====
Stripe PaymentIntent initiated for order 9375
====End Log====

2023-05-16T13:11:34+00:00 DEBUG
====Stripe Version: 7.4.0====
====Start Log====
Processing response:
====End Log====**_

outrank-james · 2023-05-16T14:51:28Z

We look to be having exactly the same error on a fair few of our client websites today. Looks like it all happened around this time 24 hours ago, straight across all websites.

Orders being taken are placed on hold, and payments not authorised on Stripe.

Just seen other posts on the Wordpress forum for the plugin.

SteStory · 2023-05-16T14:53:29Z

We look to be having exactly the same error on a fair few of our client websites today. Looks like it all happened around this time 24 hours ago, straight across all websites.

Orders being taken are placed on hold, and payments not authorised on Stripe.

Just seen other posts on the Wordpress forum for the plugin.

Yes as per here: https://wordpress.org/support/topic/orders-placed-on-hold/#post-16742036
Not sure if a new issue from the above or same.

eignition · 2023-05-16T15:12:02Z

We have the same issue

We look to be having exactly the same error on a fair few of our client websites today. Looks like it all happened around this time 24 hours ago, straight across all websites.

Orders being taken are placed on hold, and payments not authorised on Stripe.

Just seen other posts on the Wordpress forum for the plugin.

As per here: https://wordpress.org/support/topic/orders-placed-on-hold/#post-16742036

bwasellwulff · 2023-05-16T15:42:35Z

Same issue here. It happened some time last night. Stripe log not throwing any errors. Payments being placed on hold. I tried two test transactions, the first worked and went through, the second using the same process did not.

reykjalin · 2023-05-16T17:49:02Z

Thank you all for reporting! The immediate way to work around the issue for now is to downgrade to v7.2.0 of the Stripe gateway while we investigate further. We sincerely apologize for the inconvenience!

So far, all the failed transactions were with customers that had old card tokens ('card_' instead of 'src_') saved

Thank you @sefod! This could be the issue. We should be able to at least use this to investigate further.

The issue @SteStory is seeing seems like it might be slightly different, but it could be related. We'll investigate that as well.

reykjalin · 2023-05-16T17:57:20Z

I missed that it looks like no plugin updates happened in many of these cases, which is very concerning. Downgrading to 7.2.0 might solve the issues in these cases, but if the errors aren't related to any plugin updates that might not solve the issue.

However, since the initially reported issue at least seems related to changes in v7.3.0 downgrading to v7.2.0 is the most likely action to help directly. If any of you try that and find that it helps, please let us know here since it will help eliminate some of the guesswork on our end.

SteStory · 2023-05-16T18:07:22Z

Thank you all for reporting! The immediate way to work around the issue for now is to downgrade to v7.2.0 of the Stripe gateway while we investigate further. We sincerely apologize for the inconvenience!

So far, all the failed transactions were with customers that had old card tokens ('card_' instead of 'src_') saved

Thank you @sefod! This could be the issue. We should be able to at least use this to investigate further.

The issue @SteStory is seeing seems like it might be slightly different, but it could be related. We'll investigate that as well.

Hi!

It appears our issue may all be connected by host provider - 20i - please read wordpress support forum here:

https://wordpress.org/support/topic/orders-placed-on-hold/#post-16742036

I guess there may be a block or disconnect either 20i side, Stripe side or somewhere in the middle? But certainly something that needs investigating, it appears an acute issue as of around 24 hours ago, with no connections to upgraded plugins or amendments from our side.

reykjalin · 2023-05-16T18:10:37Z

It appears our issue may all be connected by host provider - 20i - please read wordpress support forum here:

Based on @outrank-james's comment that may not be the case? We'll keep investigating regardless, thank you for following up!

SteStory · 2023-05-16T18:16:11Z

It appears our issue may all be connected by host provider - 20i - please read wordpress support forum here:

Based on @outrank-james's comment that may not be the case? We'll keep investigating regardless, thank you for following up!

Yes perhaps not, but seems coincidental everyone in that thread is with 20i, and 20i themselves have mentioned they are unable to connect to Stripe: here

I wonder if it is coincidental, perhaps some preloaded wordpress/software amendments when you create a 20i wordpress install is throwing conflicts, which would mean if he has taken a 20i site into local environment it may have the error with it?

shevene · 2023-05-16T18:20:42Z

6296883-zen

ChrisAshwell · 2023-05-16T19:15:27Z

Been dealing with this issue all day today and spoke with Stripe twice, who just sent me to Woocommerce support both times.

I received the following back from WooCommerce (Automattic) support this evening, it seems as though they are aware of the issue:

"As you can see in the comments, a few other merchants are affected so you can expect an update from the developers in the same thread soon, however, we don't have an estimate on when a fix will be released. I suggest subscribing to the thread for updates."

Fingers crossed they will provide an update soon!

valigraphics · 2023-05-16T20:24:00Z

I am not with 20i and I have this issue with my site. I didnt even notice it until I took 2 payments in person and the clients left. I downgraded to 7.2 but what happens to the two payments I took?

feedbackfans · 2023-05-16T20:53:32Z

I can confirm this wasn't due to a plugin update as I'm experiencing this issue as of today, on 20i hosting with no updates to WooCommerce or this Stripe plugin. Smells more like a forced config change by the host (20i).

SteStory · 2023-05-16T20:58:31Z

One of my clients has now recieved an email from stripe stating they misconfigured something and caused IP rate limiting resulting in failed APIs. They state it is now resolved and I can confirm that client is able to recieve payments once more.

Tldr: stripe issue, fixed now.

reykjalin · 2023-05-16T22:59:07Z

@sefod I think this issue has become really noisy with an unrelated issue. As such I think it's best if we move your original request to a new issue, since a lot of external places have started linking to this issue as a source of truth for the issue of payments being put on hold.

I'll take care of creating a new issue once we've figured out what's going on with the newer reports. Feel free to unsubscribe from this issue, I'll make sure to ping you on the new one later this week 🙂

sefod · 2023-05-17T08:13:22Z

@reykjalin I understand 😅
FYI: So far, I haven't got any failed ones after patching the add_payment_method_to_request_array function to add 'card_', so we might be onto something.

I'll stay tuned.
Thanks for your help again.

reykjalin · 2023-05-17T14:17:26Z

Update on the issue with payments being put on hold and the related support thread from the plugin forums:

Stripe have confirmed that some stores were impacted by excessive rate limiting applied by Stripe's systems and that the situation should be resolved. Stripe only sent communications to accounts that exceeded 20 transactions during the time frame where the excessive rate limiting was applied.

If you have questions you can reach out to Stripe and give them the incident identifier B3U0QUFAO.

valigraphics · 2023-05-17T15:16:00Z

This has not been resolved for me. Stripe says that my issue is on Woocommerce side even after giving them the incident referenced above. I need this fixed asap as I cant take credit card payments in my Print shop. Please advise

Levi-70 · 2023-05-17T17:53:42Z

@reykjalin I understand 😅 FYI: So far, I haven't got any failed ones after patching the add_payment_method_to_request_array function to add 'card_', so we might be onto something.

I'll stay tuned. Thanks for your help again.

I have noticed 2 issues

incomplete payments and yes i notice by me as well that they are all old subscribers starting with card_ (not src_ or the new pm_)
(This seems to be closely related) when a customer (or admin) use the customer payment page, to pay for a subscription that is on hold and they use a card on file (could be only cards with id starting card_) the page goes through and says thank you for your order but subscription status stays on hold

another thing I noticed in stripe that you will only have the incomplete status once per (woocommerce) order (even if you have multiple attempts)that you will only have the incomplete status once per (woocommerce) order (even if you have multiple attempts)

to me the second point is a much greater problem.

I don't think I have been effected by rate limiting from stripe my few incomplete payments are btw Apr 30th and May 11th so this is probably unrelated to the other problems discussed here

But likely that the multiple issues are closely related (but even if they are there should be some safe guard that if a payment didn't go through for whatever reason even if just effects old card_ids it shouldn't show the customer a success page. (for WooSubscriptions)

(in general something i noticed in stripe recently that when you create an invoice (payment link to a customer) once that link is clicked it creates a status incomplete until paid, probably totally unrelated but somethin I noticed recently so maybe some change in stripe

here is an image when using the customer payment page while using a card on file that failed but still show success message with status still remaining on hold

Levi-70 · 2023-05-17T18:47:45Z

@sefod how do I get that patch?

@reykjalin I understand 😅 FYI: So far, I haven't got any failed ones after patching the add_payment_method_to_request_array function to add 'card_', so we might be onto something.

I'll stay tuned. Thanks for your help again.

gabriel-fuentes · 2023-05-17T19:57:50Z

6300402-zen

sefod · 2023-05-18T08:01:10Z

@Levi-70

DISCLAIMER: I do not recommend editing the plugin code directly. This is a temporary solution that I made for myself, and can't ensure this will work or that it won't brake something else on your site. Plus it might be reverted on the next plugin update. Implement at your own risk, and test on staging environment.

DISCLAIMER 2:This is a solution to the original issue create by myself, not to the issues presented by other users in any of the other comments (which in most case are a different issue altogether).

With that said, I've modified the first conditional on the function add_payment_method_to_request_array of the Stripe plugin to look like this:
if ( 0 === strpos( $payment_method_id, 'src_' ) || 0 === strpos( $payment_method_id, 'card_' ) ) {

dougaitken · 2023-05-23T11:34:27Z

@valigraphics please reach out to the WooCommerce.com support team directly with full details of your scenario so they can jump in. Thanks.

sefod · 2023-06-14T13:17:04Z

@reykjalin Any updates on this or the new GitHub issue that you mentioned by any chance?

The error is still happening with the latest version.

Cheers

harry1079 · 2023-06-19T15:09:25Z

Still happening to us. So far, it has occurred on random orders between 8 - 14 June 2023.

Levi-70 · 2023-06-19T21:54:47Z

any plan for an official fix?

tinsilver · 2023-06-28T12:09:29Z

We are experiencing the same issue. It appears to be when customers are using a saved payment method that doesn't work (in our cases it was expired cards). For the customer the order appears to complete, but the order doesn't capture payment and the order is set to on hold. Removing the saved payment method and retrying payment with a new card solves the problem, but the issue is that the customer doesn't know to try this until we contact them.

WooCommerce Stripe Gateway version: 7.4.1
WooCommerce version: 7.8.0
Wordpress version: 6.2.2

We are not able to downgrade to payment plugin 7.2.0 because there is another issue with subscription errors in that version.

Levi-70 · 2023-06-28T14:49:05Z

@tinsilver I suspect its not only expired cards but long time subscribers that are using card ids starting with card_
by updating to a new card you are probably using pm_ (or src_)

tinsilver · 2023-06-28T16:11:40Z

@tinsilver I suspect its not only expired cards but long time subscribers that are using card ids starting with card_ by updating to a new card you are probably using pm_ (or src_)

Hi @Levi-70 - yes, I think you are correct

Babylon1999 · 2023-07-02T19:20:32Z

zd-6478661 seems related

Brianmitchtay · 2023-07-03T19:51:45Z

Seeing this in 6474994-zen

They've noted that they have checked the stored payment methods for some of their affected customers in the {prefix}_woocommerce_payment_tokens table and they had their tokens saved as card_ tokens, so implementing the addition suggested by @sefod above is so far working to resolve the issue.

thenbrent · 2023-07-04T03:30:54Z

This has been moved to the top of our team's bug backlog as of today.

Because there are various unrelated issues being posted in comments on this thread, I want to clarify the fix we will be working on here will be for the issues clearly articulated in this comment:

old customers still have cards on file that have the old format, the plugin is not sending the right data and the payment intent is failing.

My understanding of the 20i hosting issues is that they have been fixed separately already; however, if you have those or other issues to the above, please open a new issues because once the card_ prefix issue is addressed, this issue will be closed.

ericboles · 2023-07-12T19:11:30Z

I am running into this same issue after updating plugins recently. As @sefod highlighted, I saw this with an older subscription customer that has information stored as card instead of src. As a long-time customer, they have also added multiple cards to their Stripe customer record over the years as cards have been updated/expired. At minimum, it appears that the latest version of the Stripe plugin is not passing the necessary card_ parameter in the POST /v1/payment_intents request.

You can see the POST /v1/payment_intents requests below from the same long-time customer's subscription renewal (customer ID information has been anonymized). The first request was successful from before I updated the Stripe plugin (WooCommerce Stripe Gateway/6.3.0). It charged the correct card successfully.

And the next requests are from the latest version of the plugin (WooCommerce Stripe Gateway/7.4.1). For the renewal, the plugin sent 2 requests at the same time. One request results in a Received unknown parameter: level3 and the other failed to pass the card_ parameter so Stripe resorted to an old expired card resulting in a declined payment.

The customer then attempted to manually process the renewal using the correct card that was already stored in their account that has been successfully charged many times before today. That POST /v1/payment_intents request also failed to pass the card_ information and put the order on hold within WooCommerce--showing the same Stripe charge authorized (Charge ID: )..... order note that @sefod highlighted.

Ultimately, the card was successfully charged from within the Stripe dashboard--so this was not an issue with the card itself.

I hope this background can help identify the bug and fix the issue.

Here is a successful request body for an automatic subscription renewal a few months ago sent from WooCommerce Stripe Gateway/6.3.0 before I the plugin was updated:

  "confirmation_method": "automatic",
  "description": "Product - Order 105219",
  "shipping": {
    "address": {
      "country": "CA",
      "line1": "123 Anywhere Blvd.",
      "state": "ON",
      "city": "Toronto",
      "postal_code": "M1R 0E9",
      "line2": ""
    },
    "name": "Joe Customer"
  },
  "metadata": {
    "order_id": "105219",
    "site_url": "https://www.thestore.com",
    "customer_email": "[email protected]",
    "payment_type": "recurring",
    "customer_name": "Joe Customer"
  },
  "currency": "usd",
  "off_session": "true",
  "customer": ["cus_UUidCustomerHere"](https://dashboard.stripe.com/customers/cus_UUidCustomerHere),
  "payment_method": "card_uuIDCardHere",
  "confirm": "true",
  "amount": "10000",
  "payment_method_types": {
    "0": "card"
  }
}

And here is a failed request body for an automatic subscription renewal from the exact same customer that should charge the same card as before. It was sent from WooCommerce Stripe Gateway/7.4.1 after the plugin was updated (again, customer ID information has been anonymized). There were two POST /v1/payment_intents requests logged at the same time (7/12/23, 3:25:55 PM UTC). The first one failed with the error parameter_unknown - level3 Received unknown parameter: level3

Neither request passed the card_ information as it had been from the earlier renewal using a previous version of the plugin. With out that information, it appears Stripe resorted to the first card that this customer used back in 2017 that has since expired so the order failed.

First Request at 7/12/23, 3:25:55 PM UTC:

{
  "payment_method_types": {
    "0": "card"
  },
  "description": "Product - Order 108232",
  "confirm": "true",
  "metadata": {
    "order_id": "108232",
    "site_url": "https://www.thestore.com",
    "customer_email": "[email protected]",
    "payment_type": "recurring",
    "customer_name": "Joe Customer"
  },
  "level3": {
    "merchant_reference": "35205",
    "shipping_amount": "0",
    "line_items": {
      "0": {
        "discount_amount": "0",
        "unit_cost": "10000",
        "product_description": "The Product",
        "product_code": "463",
        "quantity": "1",
        "tax_amount": "0"
      }
    }
  },
  "currency": "usd",
  "off_session": "true",
  "customer": ["cus_UUidCustomerHere"](https://dashboard.stripe.com/customers/cus_UUidCustomerHere),
  "confirmation_method": "automatic",
  "amount": "10000",
  "shipping": {
    "address": {
      "country": "CA",
      "line1": "123 Anywhere Blvd.",
      "state": "ON",
      "city": "Toronto",
      "postal_code": "M1R 0E9",
      "line2": ""
    },
    "name": "Joe Customer"
  }
}

Second Request at 7/12/23, 3:25:55 PM UTC:

{
  "shipping": {
    "address": {
      "country": "CA",
      "line1": "123 Anywhere Blvd.",
      "state": "ON",
      "city": "Toronto",
      "postal_code": "M1R 0E9",
      "line2": ""
    },
    "name": "Joe Customer"
  },
  "description": "Product - Order 108232",
  "confirmation_method": "automatic",
  "metadata": {
    "order_id": "108232",
    "site_url": "https://www.thestore.com",
    "customer_email": "[email protected]",
    "payment_type": "recurring",
    "customer_name": "Joe Customer"
  },
  "currency": "usd",
  "off_session": "true",
  "customer": ["cus_UUidCustomerHere"](https://dashboard.stripe.com/customers/cus_UUidCustomerHere),
  "confirm": "true",
  "amount": "10000",
  "payment_method_types": {
    "0": "card"
  }
}

The customer then went back into their WooCommerce account to select the correct card already saved in their Stripe customer record to manually process the renewal again (the card was not reentered--it was selected from the list of available cards in their account). The request still doesn't pass the card_ information and the response from Stripe failed with "status": "requires_payment_method"

Manual renewal request from within WooCommerce customer account after payment failed with expired card:

{
  "payment_method_types": {
    "0": "card"
  },
  "description": "Product - Order 108232",
  "capture_method": "automatic",
  "metadata": {
    "payment_type": "recurring",
    "order_id": "108232",
    "site_url": "https://www.thestore.com",
    "customer_email": "[email protected]",
    "save_payment_method": "true",
    "customer_name": "Joe Customer"
  },
  "currency": "usd",
  "customer": ["cus_UUidCustomerHere"](https://dashboard.stripe.com/customers/cus_UUidCustomerHere),
  "setup_future_usage": "off_session",
  "amount": "10000",
  "shipping": {
    "address": {
      "country": "CA",
      "line1": "123 Anywhere Blvd.",
      "state": "ON",
      "city": "Toronto",
      "postal_code": "M1R 0E9",
      "line2": ""
    },
    "name": "Joe Customer"
  }
}

Within the WooCommerce backend, the order and subscription were shown as On Hold and this error is seen--the same as @sefod mentioned.

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 Failed to On hold."

Levi-70 · 2023-07-12T19:16:45Z

@ericboles wow you really did a nice detailed job with that post
one thing I would add is that when the customer pays from the customer page using their old card (card_) it seems that it was successful by the order confirmation page (thank you for your order etc.)
like the picture that i posted earlier

ericboles · 2023-07-12T19:25:01Z

Thanks, @Levi-70. That is true. To the customer, the order appears successful initially--the customer is sent to the order confirmation page (away from the checkout page). The store admin also receives a "New subscription renewal order" email. However, the order and subscription are still both on hold within WooCommerce.

sefod · 2023-07-19T07:29:26Z

@thenbrent any updates on this?

I can confirm that since I applied that patch, I haven't had any further issues with payments.

At the moment, I'm manually re-applying the patch after each new plugin version, which is less than ideal.

Let me know if there's anything I can help with on my side to accelerate this.

Thanks!

thenbrent · 2023-07-25T03:43:11Z

@sefod this issue remains at the top of the team's backlog of issues without any PR / assignee.

A number of security issues have consumed the team's efforts the last few weeks (and months) hence the delay.

I appreciate the offer to help accelerate - a PR might be of some help to give us a head start; however, we'll still need to review and test before release which is where the majority of the time will go.

thenbrent · 2023-07-26T04:55:44Z

@sefod we now have a PR in review to address this issue here: #2665.

reykjalin added priority: low The issue/PR is low priority—not many people are affected or there’s a workaround, etc. type: bug The issue is a confirmed bug. needs repro This issue needs to be reproduced / verified. labels May 3, 2023

diegocurbelo added priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. 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

james-allan self-assigned this Jul 25, 2023

james-allan mentioned this issue Jul 25, 2023

Allow card_ prefixed payment method IDs when attaching to a payment request #2665

Merged

4 tasks

james-allan closed this as completed in #2665 Aug 7, 2023

rogercoathup mentioned this issue Aug 9, 2023

Some orders going on-hold since upgrading to 7.4.2 #2673

Closed

Payments failing with 'requires_payment_method' error on some orders after updating to WooCommerce 7.6.0 #2608

Payments failing with 'requires_payment_method' error on some orders after updating to WooCommerce 7.6.0 #2608

Comments

sefod commented May 2, 2023

sefod commented May 2, 2023 • edited Loading

reykjalin commented May 3, 2023

sefod commented May 3, 2023

Babylon1999 commented May 8, 2023

jacoswan commented May 16, 2023 • edited Loading

igorhereira commented May 16, 2023

sefod commented May 16, 2023

SteStory commented May 16, 2023 • edited Loading

outrank-james commented May 16, 2023

SteStory commented May 16, 2023

eignition commented May 16, 2023

bwasellwulff commented May 16, 2023

reykjalin commented May 16, 2023

reykjalin commented May 16, 2023

SteStory commented May 16, 2023

reykjalin commented May 16, 2023

SteStory commented May 16, 2023

shevene commented May 16, 2023

ChrisAshwell commented May 16, 2023 • edited Loading

valigraphics commented May 16, 2023

feedbackfans commented May 16, 2023

SteStory commented May 16, 2023

reykjalin commented May 16, 2023

sefod commented May 17, 2023

reykjalin commented May 17, 2023

valigraphics commented May 17, 2023

Levi-70 commented May 17, 2023 • edited Loading

Levi-70 commented May 17, 2023

gabriel-fuentes commented May 17, 2023

sefod commented May 18, 2023

dougaitken commented May 23, 2023

sefod commented Jun 14, 2023

harry1079 commented Jun 19, 2023

Levi-70 commented Jun 19, 2023

tinsilver commented Jun 28, 2023

Levi-70 commented Jun 28, 2023

tinsilver commented Jun 28, 2023

Babylon1999 commented Jul 2, 2023

Brianmitchtay commented Jul 3, 2023

thenbrent commented Jul 4, 2023

ericboles commented Jul 12, 2023 • edited Loading

Levi-70 commented Jul 12, 2023

ericboles commented Jul 12, 2023

sefod commented Jul 19, 2023

thenbrent commented Jul 25, 2023

thenbrent commented Jul 26, 2023

sefod commented May 2, 2023 •

edited

Loading

jacoswan commented May 16, 2023 •

edited

Loading

SteStory commented May 16, 2023 •

edited

Loading

ChrisAshwell commented May 16, 2023 •

edited

Loading

Levi-70 commented May 17, 2023 •

edited

Loading

ericboles commented Jul 12, 2023 •

edited

Loading