"No such source: pm_....." during checkout attempts

[n9yty]

Describe the bug We had issues as in ticket #2602 when we updated to 7.3.0. We reverted to 7.2.0 and now some customers are seeing an error message during checkout with "No such source:" and a value starting with pm. It seems it is calling the /sources/ API endpoint with at pm value which should bar a payment method, right?

We are stuck because moving to 7.3.0 means our subscriptions won't renew and staying at 7.2.0 means this happens to some customers and they can not place an order.

To Reproduce Unfortunately this is not affecting all customers and we have not been able to reproduce it.

Expected behavior The order placement process should complete normally.

Environment (please complete the following information): WordPress 6.2 WooCommerce 7.6.0 Stripe Plugin: 7.2.0 (after failed upgrade to 7.3.0)

Additional context Here is a log entry from a failed attempt:

====Stripe Version: 7.2.0==== ====Start Log==== sources/pm_{redacted} ====End Log====

====Stripe Version: 7.2.0==== ====Start Log==== Error: stdClass Object ( [error] => stdClass Object ( [code] => resource_missing [docurl] => https://stripe.com/docs/error-codes/resource-missing [message] => No such source: 'pm{redacted}' [param] => [request_logurl] => https://dashboard.stripe.com/logs/req{redacted}?t=1682098342 [type] => invalid_request_error )

)

====End Log====

[imodouglas]

Hi @n9yty, I just tested this on my end and I was not able to replicate this. It will be best to know if this is a site-specific issue and what troubleshooting steps have been taken.

Also, can you try upgrading to the latest version 7.4.0, and try again with your site in conflict test mode?

[lynnjat7]

I think this might be related: 6271770-zen

We're seeing similar errors with the source ID field after trying to upgrade to 7.3/7.4 and then having to downgrade to 7.2 due to a different bug ($0 subscriptions cannot renew).

This appears to be a valid bug, dev team is investigating.

[tinsilver]

We have this exact issue. We had to roll back because of the $0 subscription bug and now half the orders have this failed payment method error

[n9yty]

nice to see such rapid response on an issue that debilitates incoming orders for a significant portion of the customer base.

[CrzyMan]

I had this problem. It started 2023-04-19 between 10:18am and 2:10pm MT.

Most online suggestions were that I was probably mixing the usage of live and test keys. That was not my case.

Thankfully (and unfortunately) the source of the problem was that I made a custom generate_create_intent_request() to add some platform specific fields and metadata. It was based on an old version of woocommerce-gateway-stripe\includes\abstracts\abstract-wc-stripe-payment-gateway.php > generate_create_intent_request().

Basically, the problem is that payment sources (e.g. "src_xxx", cards saved to a profile) and payment methods (e.g. "pm_xxx") are different, but used to be interchangeable. Previously, they BOTH worked when put as the source OR payment_method property. Now, source can ONLY be a payment source (e.g. "src_xxx"), while payment_method can be either.

So, this was my initial change.

HOWEVER Upon inspecting a more recent version of woocommerce-gateway-stripe\includes\abstracts\abstract-wc-stripe-payment-gateway.php > generate_create_intent_request(), it turns out that you guys knew this and there is a whole function to manage that for us! (Thank you!)

/**
* Generates the request when creating a new payment intent.
*
* @param WC_Order $order           The order that is being paid for.
* @param object   $prepared_source The source that is used for the payment.
* @return array                    The arguments for the request.
*/
public function generate_create_intent_request( $order, $prepared_source ) {
    $full_request = $this->generate_payment_request( $order, $prepared_source );
    // ...
    $request = [
        // calculated props and ones from $full_request
    ];
    // ...
    if ( isset( $full_request['source'] ) ) {
        // THIS BEAUTIFUL THING RIGHT HERE!
        $request = WC_Stripe_Helper::add_payment_method_to_request_array( $full_request['source'], $request );
    }
    // ...
}

So, if you are getting the "No such source: pm_..." error, it could be that you are giving a payment method instead of a source. If that is the case, I'd argue that a more enlightening error message would have been "Payment method provided instead of payment source".

It sounds like this is a case where the naming convention used to be kind of ambiguous and you could pass in whatever, but they got more specific over time until they completely broke ambiguous operation.

While this may not be the exact location of the error for this ticket, I hope it sheds light on the nature of what it could be.

[NickGreen]

We are getting an error which seems to me to be similar:

resource_missing - source
No such source: 'pm_xxxx'

This was the response from the logs, suggesting that the request was made as a source:

  "error": {
    "code": "resource_missing",
    "doc_url": "https://stripe.com/docs/error-codes/resource-missing",
    "message": "No such source: 'pm_xxxx'",
    "param": "source",
    "request_log_url": "https://dashboard.stripe.com/logs/req_xxxx",
    "type": "invalid_request_error"
  }

That payment method does exist in Stripe for that customer, as they had added it 5 minutes prior. It is currently still attached to the customer in Stripe.

We are not running any custom Stripe-related code that would impact this.

[CrzyMan]

@NickGreen are you able to provide anonymized data for

• payment method in stripe
• order in woocommerce (specifically the meta-data _stripe_source_id)

I'm starting to wonder how much of it is just people choosing a strange payment method.

[n9yty]

I don't know about the current issue, but the previous issue was due to changes they made in the plugin, but it didn't handle some things right and when you downgraded it caused incompatibilities based on cached user information in their browser so it wasn't easy to fix globally. I haven't seen this in recent versions on our site, so you have a different cause.

[shaunkuschel]

Another report of this on 6712627-zen.

In this case the transactions are being processed successfully in WooCommerce and no errors are found in the Stripe Gateway logs or Order Notes, but the Stripe account dashboard has this error logged daily.

This user has decided to use WooPayments instead of the Stripe gateway plugin.

[github-actions[bot]]

Hi, This issue has gone 150 days (5 months) without any activity. This means it is time for a check-in to make sure it is still relevant. If you are still experiencing this issue with the latest version, you can help the project by responding to confirm the problem and by providing any updated reproduction steps. Thanks for helping out.