Subscription created without payment method saved in some circumstances

[thracefulton]

Describe the bug

In 4531671-zen the merchant reports the following:

• Subscription renewal orders are failing as of 18 Nov
• New Subscriptions payments are successful via WC Pay
• so there are so far only 8 affected renewal orders Pending Payment with no transaction details in order, WC Pay dashboard or Stripe Connect dashboard.

Reviewing one affected order (id 6575) shows multiple retry rule attempts created, no transactions attempted. Dubug logs for this order:

2021-11-19T14:03:17+00:00 INFO There was a problem updating the WCPay subscription in: Subscription does not contain a valid subscription ID. 2021-11-19T14:03:17+00:00 ERROR There is no saved payment token for order #6575 2021-11-19T14:48:55+00:00 INFO REQUEST GET https://public-api.wordpress.com/wpcom/v2/sites/%s/wcpay/accounts?test_mode=0

To Reproduce

It's unclear what the steps are to recreate this. A new test Subscription order was created and successfully paid with WC Pay.

Actual behavior

• A scheduled subscription renewal order is created and payment is not attempted by WC Pay.
• Subscription → On Hold, renewal order → Pending Payment

Screenshots

Expected behavior

1. Renewal order created
2. saved payment token processes renewal payment
3. Subscription → Active, renewal order → Processing

Additional context

4531671-zen - ticket notes contain links to Stripe Connect account view

[james-allan]

INFO There was a problem updating the WCPay subscription in: Subscription does not contain a valid subscription ID

That error is caused by WCPay subscriptions code trying to update any subscription status in WC Pay, but the subscription doesn't contain WCPay Subscription ID eg they are using the plugin. We should remove these errors or at the very least suppress them on sites running the WC subscriptions plugin.

FWIW, it won't cause any errors or issues. This log entry is simply a debugging info log - it should just be targetted better.

cc @haszari

ERROR There is no saved payment token for order #6575

This one I'm not sure of, I don't think it relates to WCPay Subscriptions.

[htdat]

I am going to close this issue as it's being handled internally. p1637635450408400-slack-C7U3Y3VMY

Feel free to reopen it if necessary.

[brucealdridge]

Have looked through the API requests and found that setup_future_usage was set to null when the original payment intent was created. We never had access to the card and so renewals would fail.

This particular merchant has had successful subscriptions started before and after the given date.

More investigation is required to determine why setup_future_usage was set incorrectly.

[jrick1229]

I saw the same issue in: 4560491-zd-woothemes

One thing I noticed in my case is that all of the parent orders had a $0 total. I wanted to mention that in case this could be the reason no payment method was chosen/stored in the subscription during its creation.

[jrick1229]

^ furthering the above, I was able to find an example with a non-$0 parent order that also had the same issue, so we can assume that's not related.

[brucealdridge]

@jrick1229 I wonder if this is a duplicate of #2994

[jrick1229]

It sounds like it could be @brucealdridge – but note that this does not happen with the Subscriptions functionality solely added from WooCommerce Payments. My example above uses WooCommerce Payments, but they also have WooCommerce Subscriptions installed.

[jrick1229]

Another found: 4562169-zen

Oddly, these also started with a $0 payment, so that at the very least seems to be a pattern.

[namiokuzono]

I commented on the other issue thread #2994, but to note what @jrick1229 said, the customer for 4561824-zen has WC PAY + WC SUB. For anyone who's interested, I've shared a "workaround" in my reply to the ticket 4561824-zen that @nicdwilson had originally mentioned in 4370642-zen.

[brucealdridge]

It sounds like it could be @brucealdridge – but note that this does not happen with the Subscriptions functionality solely added from WooCommerce Payments. My example above uses WooCommerce Payments, but they also have WooCommerce Subscriptions installed.

This shouldn't make a difference. WooCommerce Subscriptions and WooCommerce Payments both share functionality. Anything subscriptions related in WooCommerce Payments will have the same code as in WooCommerce Subscriptions.

These issues may also be attributed to #3471

[chickenn00dle]

I did some more digging into this issue and while I wasn't able to reproduce, I did spend some time looking through the code and figured I'd share what I found:

• setup_future_usage is set to null in the response when creating the intent because we aren't including this parameter at all in our initial request (see request/response snippets below)
• We set the corresponding setup_future_usage request param here in create_and_confirm_intention
• This is called while processing the order here and whether or not we set setup_future_usage depends on whether $save_payment_method is true.
• Finally, the value of $save_payment_method is set in an instance of Payment_Information, which is initialized while processing an order here

For some reason, this is not being correctly set for some of this merchant's subscription transactions. My guess is something is going wrong in either maybe_prepare_subscription_payment_information or in the wc-woocommerce_payment-new_payment_method $_POST check. But it's hard to say without being able to reproduce.

Below is a redacted version of a request/response to and from server for the parent order of an affected subscription:

Request (Notice `setup_future_usage` is not set in request)

``` 2021-11-10T23:57:59+00:00 INFO REQUEST POST https://public-api.wordpress.com/wpcom/v2/sites/%s/wcpay/intentions/pi_ 2021-11-10T23:57:59+00:00 INFO BODY: array ( 'test_mode' => false, 'amount' => 3017.0, 'currency' => 'usd', 'metadata' => array ( 'customer_name' => '(redacted)', 'customer_email' => '(redacted)', 'site_url' => (redacted), 'order_id' => 6491, 'order_key' => 'wc_order_', 'payment_type' => 'WCPay\\Constants\\Payment_Type()', ), 'level3' => array ( 'merchant_reference' => '6491', 'customer_reference' => '6491', 'shipping_amount' => 0.0, 'line_items' => array ( 0 => 'stdClass()', ), 'shipping_from_zip' => (redacted), ), 'description' => 'Online Payment for Order #6491 for redacted', 'payment_method_types' => array ( 0 => 'card', ), 'payment_country' => 'US', 'customer' => 'cus_', ) ```

Response (Notice `setup_future_usage` is null)

``` 2021-11-10T23:58:00+00:00 INFO RESPONSE: array ( 'id' => 'pi_', 'object' => 'payment_intent', 'amount' => 3017, 'amount_capturable' => 0, 'amount_received' => 0, 'amount_subtotal' => 3017, 'application' => 'ca_', 'application_fee_amount' => 117, 'canceled_at' => NULL, 'cancellation_reason' => NULL, 'capture_method' => 'automatic', 'charges' => array ( 'object' => 'list', 'data' => array ( ), 'has_more' => false, 'total_count' => 0, 'url' => '/v1/charges?payment_intent=pi_', ), 'client_secret' => '(redacted)', 'confirmation_method' => 'automatic', 'created' => 1636588501, 'currency' => 'usd', 'customer' => 'cus_', 'description' => 'Online Payment for Order #6491 for redacted', 'invoice' => NULL, 'last_payment_error' => NULL, 'level3' => array ( 'customer_reference' => '6491', 'line_items' => array ( 0 => array ( 'discount_amount' => 0, 'product_code' => '2651', 'product_description' => 'Small Home', 'quantity' => 1, 'tax_amount' => 0, 'unit_cost' => 3017, ), ), 'merchant_reference' => '6491', 'shipping_amount' => 0, 'shipping_from_zip' => (redacted), ), 'livemode' => true, 'metadata' => array ( 'customer_name' => '(redacted)', 'customer_email' => '(redacted)', 'site_url' => (redacted), 'order_id' => '6491', 'order_key' => 'wc_order_', 'payment_type' => 'recurring', ), 'next_action' => NULL, 'on_behalf_of' => NULL, 'payment_method' => NULL, 'payment_method_options' => array ( 'card' => array ( 'installments' => NULL, 'network' => NULL, 'request_three_d_secure' => 'automatic', ), ), 'payment_method_types' => array ( 0 => 'card', ), 'receipt_email' => NULL, 'review' => NULL, 'setup_future_usage' => NULL, 'shipping' => NULL, 'source' => NULL, 'statement_descriptor' => NULL, 'statement_descriptor_suffix' => NULL, 'status' => 'requires_payment_method', 'total_details' => array ( 'amount_discount' => 0, 'amount_tax' => 0, ), 'transfer_data' => NULL, 'transfer_group' => NULL, 'fee_history' => array ( 0 => array ( 'type' => 'base', 'percentage_rate' => 0.029, 'fixed_rate' => 30, 'currency' => 'usd', ), ), ) 2021-11-10T23:58:03+00:00 INFO Begin processing UPE redirect payment for order 6491 for the amount of 30.17 ```

[chickenn00dle]

I've not been able to get to the bottom of this @thracefulton, but I did notice that this merchant is using WooCommerce All Products For Subscriptions, and their subscription products are actually all simple products with subscription plans. This may be irrelevant, but just thought it was worth noting.

It also looks like both WooCommerce All Products For Subscriptions and WooCommerce Payments have updates available. I realize the issue existed prior to these updates being available, but it's worth seeing if they are willing to update. It's possible whatever is causing this bug has since been resolved, which may be why we can't reproduce?

[thracefulton]

It also looks like both WooCommerce All Products For Subscriptions and WooCommerce Payments have updates available. I realize the issue existed prior to these updates being available, but it's worth seeing if they are willing to update. It's possible whatever is causing this bug has since been resolved, which may be why we can't reproduce?

Will do!

[solstudioim]

I've seen the same problem on 4609206-Zen

Some background information:

• Enable payments via saved cards is checked
• The product is a variable subscription product
• WC Pay and WC Subs activated

Every time a subscription product was purchased, a renewal order kept failing, in the log, the same sign appeared:

ERROR There is no saved payment token for order #XXXXX

They have a lot of plugins including a muti language plugin, and when I kept only minimal plugins including WooCommerce Payments and WC Subs, the problem wasn't reproducible anymore.

[AashikP]

Another report in 5222639-zen

Here's how I could replicate this on my test JN site:

1. Create a test JN site
2. Access FTP and update wp-config.php to force site to use HTTP (also enable dev mode for WCPay):

define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST']);
define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']);

define( 'WCPAY_DEV_MODE', true );

3. Configure WooCommerce + WooCommerce Payments - install WooCommerce Subscriptions as well

4. Attempt to checkout a Subscription product to confirm everything is working as expected

5. Access Payments > Settings and disable the Credit/Debit Card option

   

6. Try to check out a Subscription product using a test card (This is possible due to this bug: https://github.com/Automattic/woocommerce-payments/issues/3969)

7. Notice that the card is not saved in the Subscription:

   

• This is very likely caused by a combination of the linked bug report and missing SSL.
• Interestingly, neither enabling Cart payments again, nor disabling the custom code above seems to help Subscriptions save tokens on my test site
• I'm currently asking user in 5222639-zen to change the site and home URL to HTPPS version and try purchasing a Subscription product to see if the cards are correctly saved in live mode.

[haszari]

force site to use HTTP

Thanks for documenting clear reproduce steps @AashikP ! 🙌

If this issue is only affecting sites that don't use HTTPS, I'd say this is an unsupported edge case, since WCPay requires an SSL certificate:

I see this issue has been previously closed (@htdat), maybe we can close this if it's due to no SSL.

We could also look at a follow up issue to add notices/warnings or possibly disable functionality if the site is not using HTTPS.

[htdat]

We could also look at a follow up issue to add notices/warnings or possibly disable functionality if the site is not using HTTPS.

Agreed this approach if we can replicate the issue.

[nicholasjeberlin]

User from 5222639-zen has come back after enabling HTTPS for their site and going through the process of creating a new subscription.

Unfortunately, the card did not save, so let's leave this open for now until we can narrow it down further.

[AashikP]

Just to add to @nicholasjeberlins comment, I tested my own site with the custom code to redirect to HTTP removed, to reconfirm the same behavior this user is seeing. No payment method saved.

[anant1811]

Another one in #5205785-zen

[johndcoy]

@haszari & @chickenn00dle

In 5249701-zd I found that the subscriptions that failed as a result of ERROR There is no saved payment token for order #... also did not have a parent order assigned:

Screenshot link: https://d.pr/i/RjYVxb

We've tried canceling the existing renewal, assigning the parent order, and creating a new renewal order but the new renewal still fails. Although all of these subscriptions have a cost, I think @jrick1229 's find with a $0 order could be related?

[imodouglas]

Same in zen-5205785

[theabhig]

Just checking in again as the user in 5205785 is chasing for an update. @haszari or @chickenn00dle is there anything we can provide to the user in terms of an ETA or any sort of updates? Thanks :)

[haszari]

Thanks for the update @theabhig . Re-reading through the above comments, I'm not sure if we've managed to reproduce this issue yet - do you know if it's been reproduced on a test site (with https)?

zen-5205785

@imodouglas Does this user have $0 initial payments? There are lots of details mentioned in previous comments that might be relevant. Perhaps this merchant's scenario will help us narrow down or reproduce.

@shendy-a8c (reviewer this week) – could you look at the more recent reports of this and try to reproduce on Jurassic Ninja (or other test environment)?

Thanks everyone :)

[pehaa]

Hey @haszari @imodouglas and @shendy-a8c I'm just checking if there is an update I could submit to the user (5205785). Have you been able to reproduce the issue? Thank you!

[haszari]

Thanks for checking @pehaa – no update as far as I'm aware, we still don't have reliable reproduce steps. If the merchant is still experiencing the issue, perhaps they could try to reproduce on a test site to isolate the issue (away from the production site).

[haszari]

Next steps here are to read through the discussion and update the description. In particular:

• Can we reproduce this issue?
• What is the bug that the merchant is reporting, and how does it impact them?
• How many stores/merchants are affected by this?

[solstudioim]

Got another similar case on 6356886-zd-woothemes; the merchant's subscription parent order doesn't have $0 though.

No related fatals.

[solstudioim]

Same like my previous comment, the test subscription product is 1 EURO: 7595069-zd-a8c

[shaunkuschel]

Another report of this on 7623512-zen. This merchant was able to resolve the issue by enabling the use of saved cards in the WooPayments settings. However, I was not able to replicate the issue on my test site while matching all of their Subscriptions and WooPayments settings.

[imodouglas]

8021889-zen

[chrism245]

Another one 81828650-zen. Parent order had a $0 total.

[imodouglas]

8066777-zen parent orders were paid but looks like the token was not saved.