Automattic / woocommerce-payments

Accept payments via credit card. Manage transactions within WordPress.
https://wordpress.org/plugins/woocommerce-payments/
Other
173 stars 69 forks source link

Subscriptions without some billing details will not renew after updating to 7.3.0 #8352

Closed csmcneill closed 3 months ago

csmcneill commented 7 months ago

Describe the bug

If a merchant removes some billing fields (e.g., billing address, country) from the checkout page, the subscriptions would be successfully created and renew without issue prior to 7.3.0.

However, after updating to 7.3.0, these same subscription renewals will fail, and the order notes indicate the following error:

Error: You passed an empty string for 'billing_details[address][country]'. We assume empty values are an attempt to unset a parameter; however 'billing_details[address][country]' cannot be unset. You should remove 'billing_details[address][country]' from your request or supply a non-empty value.

To Reproduce

  1. Create a simple subscription product
  2. Install WooPayments 7.1.0 (7.2.0 may work here, but I didn't test this)
  3. Install Checkout Field Editor
  4. Remove all billing fields except ZIP code, email, and first/last name
  5. Purchase a subscription via shortcode checkout (CFE is not compatible with the checkout block)
  6. Update to WooPayments 7.3.0
  7. Process a renewal by running the woocommerce_scheduled_subscription_payment hook in the action scheduler.
  8. The renewal will fail

Actual behavior

A renewal fails if there is incomplete billing information provided. However, this only occurs with 7.3.0 active, so it might be related to https://github.com/Automattic/woocommerce-payments/pull/8226

Screenshots

CleanShot 2024-03-07 at 18 39 48

Expected behavior

Since subscriptions renewing with incomplete billing information worked before 7.3.0, maybe it should work in 7.3.0 and beyond — even though we advise against removing core billing fields.

Additional context

p1709858821739469-slack-C7U3Y3VMY 7855095-zen

csmcneill commented 7 months ago

Adding the impact: high label as we currently estimate that ~28 sites are impacted per p1709915385055709-slack-CGGCLBN58

maxlaf commented 6 months ago

7864552-zen Just adding cases here for measuring impact.

rossviviano commented 6 months ago

7869057-zen

claudiulodro commented 6 months ago

I think it would be best to continue supporting as many removed fields as possible. Research shows that the more fields a checkout has the lower the conversion rate will be, so removing unnecessary fields (e.g. many parts of the billing address on digital products) provides a meaningful difference to merchants' revenue.

csmcneill commented 6 months ago

@gpressutto5 @frosso Could either of you check to see if this is related to #8226 please?

I reverted the changes introduced by this PR on my local and was able to resolve the issue. If I had to wager a guess (and pardon my ignorance here), get_billing_details_from_order might be trying to pull billing details on subscription renewals — but when some billing details are not present, the order fails.

frosso commented 6 months ago

@csmcneill it does seem to be related. I tested it locally (with and without those fixes) and came to the same conclusion. I think you're on the right track with the issue.

zoupkat commented 6 months ago

Hey there @frosso Any news on the progress here? Another affected merchant here 7894412-zen Thank you!

frosso commented 6 months ago

Hey @zoupkat! 👋 The issue is on my team's sprint, someone with availability will self-assign and we'll get a resolution within the next week or two.

FangedParakeet commented 6 months ago

Please add your planning poker estimate with Zenhub @gpressutto5

wyter commented 5 months ago

8048923-zen, awaiting fix

robb100 commented 4 months ago

@gpressutto5

This issue was marked as closed on 26.3.24 but has returned with the latest version 7.7.

Can you re-open and prioritise the case as billings are failing constantly?

The 7.4 fix allowed absent address fields to be ignored (which was a fault with 7.3). I've just rolled back to 7.6 and everything still works fine there, so it seems the bug is with 7.7.

Appreciate some urgent attention.

Thanks ✌🏼

8459 #8352

robb100 commented 4 months ago

@FangedParakeet any update? Thanks

frosso commented 4 months ago

Hi @robb100 ! 👋

I tested the steps on the issue again by processing the manual renewal with subscriptions created on both WooPayments 7.1.0 and 7.6.0.

In all cases, the subscription renewed successfully on 7.7.0 and develop, both via the woocommerce_scheduled_subscription_payment action scheduled action and the "Process renewal" admin action.

Screenshot 2024-06-05 at 4 08 36 PM

In all cases, these were the fields at checkout:

Screenshot 2024-06-05 at 4 07 18 PM

Do you happen to have additional details or reproduction steps that could help us?

robb100 commented 4 months ago

@frosso Thanks

This is the error I got on all automatic scheduled subscription payments.

Screenshot 2024-06-05 at 15 11 46

Attempting to manually process the renewal also didn't work on 7.7 (I tried this both from the order back end and also from the front end on the site)

Only after rolling back to 7.6 would renewal complete.

Like your settings, all customers have their First and Last names along with Email address.

frosso commented 4 months ago

Thank you for the additional details @robb100 !

I tried the following setups:

I am still unable to reproduce the error. We'll report back after further testing.

FangedParakeet commented 4 months ago

I just tested this on a JN, where I was also unable to replicate the failure 😞, with the following plugin versions:

Here are the steps I followed, which I believe follow those in the issue description.

  1. Installed WooPayments 7.1.0.
  2. Used Checkout Field Editor to remove all billing fields, except for first/last name, email, and postcode.
  3. Created a simple subscription product and created an order for this product.
  4. Upgraded WooPayments to 7.7.0.
  5. Ran the subscription renewal via the Action Scheduler using the woocommerce_scheduled_subscription_payment hook.
  6. Renewal order created and renewal payment charged successfully, orders updated appropriately.

@robb100, can you provide a little more guidance as to how we might be able to produce this error or share a test site where we might be able instigate and inspect the failure ourselves? 🙏

gpressutto5 commented 4 months ago

I also tested in JN using different versions, blocks and shortcode checkout, and different ways to renew the subscription, but I could not reproduce the error in version 7.7.0.

When the feature to update billing address before processing payment was reimplemented in #8720, one of the test cases covered this issue.

robb100 commented 4 months ago

@FangedParakeet @gpressutto5

I don't have any auto renew payments due on this site for another 2 weeks now.

(for context I'm not a developer or coder, just someone who manages the back end of my site)

I don't have any further info to give you at this stage or a staging site that I can play around with to re-replicate the issue. All I know is that I couldn't process the renewal payments until the version was rolled back to 7.6.

The Woo Auto-update plugin has re-installed the 7.7 - (is there anyway to override the auto updates? it seems to have no settings for that!)...

Anyway. Thanks for looking in to it - I'll update you when the next autorenewals are processed.

frosso commented 3 months ago

@gpressutto5 @FangedParakeet I wanted to raise this internal message, in case you also find it interesting interesting: p1718031304506519-slack-C46H1UYN4

frosso commented 3 months ago

@robb100 thank you again for your patience. We'd like to avoid waiting for possible subscriptions failing on your site. If you're ok with this, we'd like you to create a support ticket within Woo support. Could you please contact us at WooCommerce.com > My Account > Support, providing your system status report. We'd also like to take a closer look with an administrator access on your site, if possible.

Head to Users > Add New and enter "woologin" for the user name and "woologin@woocommerce.com" for the email address. Be sure to set the role to Administrator and click “Add New User” as on the screenshot – pslYE8.png

You won't need to disclose us the password, we'll be able to recover it.

Note that to comply with GDPR rules, you need to disclose that you are sharing access rights to third parties like us in your Terms & Conditions. You can find out more about your responsibilities as a store owner under GDPR here: https://woocommerce.com/posts/the-gdpr-and-you-the-woocommerce-store-owner/

Last, but not least, delete our user account once your interaction with us is done. This helps keep your website safe by limiting the number of users with admin access.

Thank you!

robb100 commented 3 months ago

@frosso I've created the Admin user for you. Where do I send the password and 2FA Auth Code/Backup code, and log in URL to so it reaches you directly.

Thanks again

frosso commented 3 months ago

Thank you @robb100 ! You can contact us at WooCommerce.com > My Account > Support, providing your system status report and referencing this ticket. This way, all the information will remain confidential and be forwarded to my team.

EjayhanFernandes commented 3 months ago

Hi everyone! I was able to assist @robb100 with his issue.

I couldn't replicate the error on WooPayments 7.7.0 on my own test site, so I investigated further and discovered that the problem is related to a custom snippet added to the site that removes the billing address fields for virtual products.

This custom snippet works on WooPayments 7.6.0, allowing users to checkout without billing fields, but it doesn't work on 7.7.0. The failed renewals are due to subscriptions purchased without billing fields on version 7.6.0, which then encounter errors when renewed on version 7.7.0. The renewal orders fail with the following error: aCswu8.png

I think we can close this issue. cc: @frosso

frosso commented 3 months ago

Thank you @EjayhanFernandes ! With this information, I think I was able to reproduce the issue. We are discussing internally the best path forward.