Context:

Whenever I mention "Apple Pay", "Google Pay" might also be valid.

I have a plugin that adds the Portuguese districts (states) to WooCommerce.
If the shop owner decides to set shipping zones using those "Portuguese States", the Apple Pay payment modal won't request a Portuguese State, so the shipping state will be sent blank to wc_ajax_wc_stripe_get_shipping_options, and there's an error of the address not being valid:

Which I can fix with the wc_stripe_payment_request_shipping_posted_values filter (since I can easily convert the postcode to the required state in my plugin).

The next step for Apple Pay is to call wc_stripe_normalize_address, in which Stripe makes some corrections to the address, based on exceptions, in the normalize_state and fix_address_fields_mapping methods.

In these methods, there are no filters that allow 3rd party developers to manipulate the address, which makes the address go back to the original, without the new state that we were able to fix on get_shipping_options.

The payment seems to go through, the Apple Pay dialog is closed, and the final /wp-json/wc/store/v1/checkout?_locale=site call is made, which fails with woocommerce_rest_invalid_shipping_option, I suspect because the fact that there's no state makes the chosen shipping method not be valid.

Request:

Add filter to both the normalize_state and fix_address_fields_mapping methods to allow 3rd party developers to manipulate the address, similar to wc_stripe_payment_request_shipping_posted_values.

Of course, in normalize_state, this needs to be done for $billing_postcode, $billing_state, $shipping_postcode, and $shipping_state before calling the get_normalized_state method, or else this will fail immediately.

Further down the process, the final /wp-json/wc/store/v1/checkout?_locale=site call is made, and it fails with woocommerce_rest_invalid_shipping_option, probably because the fact that the state is now empty makes the chosen shipping method not valid.

Actually, I can confirm that's the reason, as I've forced a state on normalize_state, after your Hong Kong exceptions, and the checkout went through without any glitch:

This is precisely where we need the filters, so that 3rd party developers can implement exceptions just like you did for Hong Kong.