Fix address validation for manually entered orders

[daledupreez]

Fixes STRIPE-659

Changes proposed in this Pull Request:

The underlying driver for this PR is that the original code that made customer validation stricter, #4464, always required all fields. We previously shipped #4489 to relax those restrictions when users are adding payment methods. This PR refactors some of the code from #4489 to be a bit more generic so we can identify specific contexts in which we expect a smaller set of customer details to be available. The PR also relaxes customer validation for the "Pay for order" page, making it possible for manually entered orders to be handled with limited customer information.

At a technical level, the changes in this PR are as follows:

• Change a number of functions to accept a nullable $current_context string parameter instead of a $is_add_payment_method_page boolean parameter.
  • The changes include a normalization step for all public method so callers of the previous API get the same behaviour.
    • This was only released in 9.7.1, but I still want to avoid unnecessary breakages
• Update WC_Stripe_Customer->get_create_customer_required_fields() to require only an email address when we are on the pay for order page in addition to the case for adding a payment method.
• Updating the two callers to specify the appropriate context string.

Testing instructions

• Run a current version of the plugin (e.g. from 9.7.1, 9.8.0, or `develop)
• Ensure Stripe is connected in test mode and you have at least one product
• Navigate to WooCommerce -> Orders and then click on the "Add order" button
• Add some line items to the order
• For the billing details, enter only the user's email address
• Save the order
• Once the order is saved, find the "Customer payment page" link in the General section of the order details and copy the link
• In an incognito window or different browser window, navigate to that link
• Try to make payment
• You should get a validation error
• Now switch to this branch, and re-submit the payment
• The payment should now be processed and you should be redirected to the order received page

---

• Covered with tests (or have a good reason not to test in description ☝️)
• [N/A] Tested on mobile (or does not apply)

Changelog entry

• This Pull Request does not require a changelog entry. (Comment required below)

Changelog Entry Comment

Comment

Post merge

• Added testing instructions to the Release Testing Instructions wiki page (or does not apply)
• Added the needs docs label (or does not apply)
• Included this PR in the Release Thread scope (or does not apply)

[Copilot]

Pull Request Overview

This PR fixes address validation issues for manually entered orders by relaxing customer validation requirements on the "pay for order" page. Previously, strict validation prevented orders with minimal customer information (e.g., email only) from being processed.

• Refactors validation context parameters from boolean flags to string-based contexts
• Allows minimal customer details (email only) for both "add payment method" and "pay for order" pages
• Maintains backward compatibility with existing API callers

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
includes/class-wc-stripe-customer.php	Core changes to validation logic, adding context-aware customer field requirements and parameter normalization
includes/payment-methods/class-wc-stripe-upe-payment-gateway.php	Updates customer creation call to pass "pay_for_order" context
includes/class-wc-stripe-intent-controller.php	Updates setup intent creation to use new string-based context parameter
readme.txt	Adds changelog entry for the fix
changelog.txt	Adds changelog entry for the fix

[wjrosa]

Code is good and works as expected! Left some optional suggestions

[malithsen]

Looks good and tests well

[daledupreez]

I've reviewed the E2E failures, and it looks like the Default failures are already being addressed in #4592, and the issues with the Optimized Checkout tests seem to be unrelated to this PR.

[freedjack]

I have been seeing this issue on a wp/woocommerce/civicrm instance. I have created a small plugin that solves the address issue for us and may be of use to someone while this issue is being resolved.
https://github.com/freedjack/woocommerce-stripe-address-fix