Add Ability To Customize Shipping Methods In Apple/Google Pay Express Checkout

[StefsterNYC]

Is your feature request related to a problem? Please describe.

When using Apple Pay/Google Pay express checkout buttons with WooCommerce Stripe, customers frequently receive incorrect shipping charges. The displayed shipping cost in the Apple/Google Pay popup does not match what is actually applied to the final order.

Specifically: When a customer selects a paid shipping option (e.g., "2-Day Shipping - $15") in the Apple/Google Pay interface, WooCommerce may override this selection and apply a different shipping method (e.g., Free Shipping) during order processing if that method is technically available based on cart total or other conditions. This results in orders being charged $0 for shipping when the customer explicitly selected and saw a $15 charge, or vice versa.

This creates a broken checkout experience where customers cannot trust that the total they approve in Apple/Google Pay matches what they'll actually be charged.

Describe the solution you'd like

The Stripe for WooCommerce plugin should provide reliable hooks or mechanisms to:

1. Control which shipping methods are available during Apple/Google Pay shipping calculation (not just displayed, but actually available for selection)
2. Ensure that whatever shipping method the customer selects in the Apple/Google Pay interface is honored during order processing
3. Prevent WooCommerce from overriding the customer's shipping selection with a different method, even if other methods technically qualify based on cart rules

Ideally, Stripe/WooCommerce should work with Apple and Google to implement a shipping calculation flow that respects merchant shipping logic and customer selection, rather than the current disconnected approach where display and processing use different logic.

Describe alternatives you've considered

• Using wc_stripe_payment_request_shipping_options filter - this only controls display, not actual processing
• Using woocommerce_package_rates filter - unreliable during Apple/Google Pay address changes
• Disabling certain shipping methods conditionally - causes race conditions during recalculation
• Simplifying shipping setup to avoid conflicts - not practical for merchants with complex shipping requirements

None of these workarounds provide a reliable solution. The core issue is architectural.

Additional context

This was initially reported as an issue before in #1824 (2021) but was never resolved. It's still an issue 4 years later and continues to affect merchants worldwide using express checkout with multiple shipping options.

This issue particularly affects merchants with:

• Conditional free shipping (e.g., free over $75, otherwise paid)
• Multiple shipping speed options at different price points
• Live carrier rates that need to display alongside flat/free options

The payment request button context and WooCommerce's order processing context appear to calculate shipping independently, leading to mismatches. A proper solution would require coordination between Stripe, WooCommerce, and the payment providers (Apple/Google) to ensure shipping selection integrity throughout the entire checkout flow.