New Zealand: Zone regions break Google Pay

[raifd]

Describe the bug

If under WooCommerce > Settings > Shipping > Shipping Zones > Zone Regions a region of New Zealand is selected, Google Pay will fail to render the shipping methods, giving an invalid address error, thus making a purchase impossible.

To Reproduce

1. Create a brand new site with WooPayments on the latest version
2. Create a new shipping zone for New Zealand
3. Under WooCommerce > Settings > Shipping > Shipping Zones > Zone Regions add a new region (Canterbury, New Zealand for example)
4. Try to checkout with Google Pay (Here is an address you can use with a valid Canterbury ZIP Code: 180 High Street, Oxford, 7430)
5. Now head back WooCommerce > Settings > Shipping > Shipping Zones > Zone Regions remove the Zone region and instead limit it just by ZIP Codes
6. Try to pay again.

Actual behavior

Google Pay fails to pick up the shipping options if a zone region is added. It works fine with just ZIP Codes.

Screenshots

N/A

Expected behavior

Google Pay should pick up the address even when a zone region is present under Shipping Zones.

Desktop (please complete the following information):

• OS: macOS 14.0 (23A344)
• Browser: Google Chrome
• Version: 120

Smartphone (please complete the following information):

N/A

Additional context

JN site with the issue:

URL: https://helpful-millipede.jurassic.ninja/wp-admin/ Username: demo Password: 7kNtOaemp6NH

SSR: `

WordPress Environment

WordPress address (URL): https://helpful-millipede.jurassic.ninja Site address (URL): https://helpful-millipede.jurassic.ninja WC Version: 8.4.0 REST API Version: ✔ 8.4.0 WC Blocks Version: ✔ 11.6.2 Action Scheduler Version: ✔ 3.7.0 Log Directory Writable: ✔ WP Version: 6.4.2 WP Multisite: – WP Memory Limit: 256 MB WP Debug Mode: ✔ WP Cron: ✔ Language: en_US External object cache: –

Server Environment

Server Info: Apache/2.4.58 (Unix) OpenSSL/1.0.2g PHP Version: 8.0.30 PHP Post Max Size: 1 GB PHP Time Limit: 30 PHP Max Input Vars: 5000 cURL Version: 7.47.0 OpenSSL/1.0.2g

SUHOSIN Installed: – MySQL Version: 5.7.33-0ubuntu0.16.04.1-log Max Upload Size: 512 MB Default Timezone is UTC: ✔ fsockopen/cURL: ✔ SoapClient: ✔ DOMDocument: ✔ GZip: ✔ Multibyte String: ✔ Remote Post: ✔ Remote Get: ✔

Database

WC Database Version: 8.4.0 WC Database Prefix: wp_ Total Database Size: 6.39MB Database Data Size: 4.63MB Database Index Size: 1.76MB wp_woocommerce_sessions: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_woocommerce_api_keys: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_woocommerce_attribute_taxonomies: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_woocommerce_downloadable_product_permissions: Data: 0.02MB + Index: 0.06MB + Engine InnoDB wp_woocommerce_order_items: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_woocommerce_order_itemmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_woocommerce_tax_rates: Data: 0.02MB + Index: 0.06MB + Engine InnoDB wp_woocommerce_tax_rate_locations: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_woocommerce_shipping_zones: Data: 0.02MB + Index: 0.00MB + Engine InnoDB wp_woocommerce_shipping_zone_locations: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_woocommerce_shipping_zone_methods: Data: 0.02MB + Index: 0.00MB + Engine InnoDB wp_woocommerce_payment_tokens: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_woocommerce_payment_tokenmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_woocommerce_log: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_actionscheduler_actions: Data: 0.02MB + Index: 0.11MB + Engine InnoDB wp_actionscheduler_claims: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_actionscheduler_groups: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_actionscheduler_logs: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_commentmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_comments: Data: 0.02MB + Index: 0.09MB + Engine InnoDB wp_jetpack_sync_queue: Data: 0.02MB + Index: 0.06MB + Engine InnoDB wp_links: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_options: Data: 3.52MB + Index: 0.06MB + Engine InnoDB wp_postmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_posts: Data: 0.06MB + Index: 0.06MB + Engine InnoDB wp_termmeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_terms: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_term_relationships: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_term_taxonomy: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_usermeta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_users: Data: 0.02MB + Index: 0.05MB + Engine InnoDB wp_wc_admin_notes: Data: 0.06MB + Index: 0.00MB + Engine InnoDB wp_wc_admin_note_actions: Data: 0.05MB + Index: 0.02MB + Engine InnoDB wp_wc_category_lookup: Data: 0.02MB + Index: 0.00MB + Engine InnoDB wp_wc_customer_lookup: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_wc_download_log: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_wc_orders: Data: 0.02MB + Index: 0.11MB + Engine InnoDB wp_wc_orders_meta: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_wc_order_addresses: Data: 0.02MB + Index: 0.06MB + Engine InnoDB wp_wc_order_coupon_lookup: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_wc_order_operational_data: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_wc_order_product_lookup: Data: 0.02MB + Index: 0.06MB + Engine InnoDB wp_wc_order_stats: Data: 0.02MB + Index: 0.05MB + Engine InnoDB wp_wc_order_tax_lookup: Data: 0.02MB + Index: 0.03MB + Engine InnoDB wp_wc_product_attributes_lookup: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_wc_product_download_directories: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_wc_product_meta_lookup: Data: 0.02MB + Index: 0.09MB + Engine InnoDB wp_wc_rate_limits: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_wc_reserved_stock: Data: 0.02MB + Index: 0.00MB + Engine InnoDB wp_wc_tax_rate_classes: Data: 0.02MB + Index: 0.02MB + Engine InnoDB wp_wc_webhooks: Data: 0.02MB + Index: 0.02MB + Engine InnoDB

Post Type Counts

attachment: 1 page: 7 post: 2 product: 1 wp_navigation: 1 wp_template: 2

Security

Secure connection (HTTPS): ✔ Hide errors from visitors: ❌Error messages should not be shown to visitors.

Active Plugins (5)

Companion Plugin: by Osk – 1.30 Jetpack: by Automattic – 12.9.3 WooCommerce Payments Dev Tools: by Automattic – WooPayments: by Automattic – 7.0.0 WooCommerce: by Automattic – 8.4.0

Inactive Plugins (2)

Akismet Anti-spam: Spam Protection: by Automattic - Anti-spam Team – 5.3 Hello Dolly: by Matt Mullenweg – 1.7.2

Settings

API Enabled: – Force SSL: – Currency: USD ($) Currency Position: left Thousand Separator: , Decimal Separator: . Number of Decimals: 2 Taxonomies: Product Types: external (external) grouped (grouped) simple (simple) variable (variable)

Taxonomies: Product Visibility: exclude-from-catalog (exclude-from-catalog) exclude-from-search (exclude-from-search) featured (featured) outofstock (outofstock) rated-1 (rated-1) rated-2 (rated-2) rated-3 (rated-3) rated-4 (rated-4) rated-5 (rated-5)

Connected to Woo.com: – Enforce Approved Product Download Directories: ✔ HPOS feature screen enabled: ✔ HPOS feature enabled: ✔ Order datastore: Automattic\WooCommerce\Internal\DataStores\Orders\OrdersTableDataStore HPOS data sync enabled: –

WC Pages

Shop base: #6 - /shop/ Cart: #7 - /cart/ Checkout: #8 - /checkout/ My account: #9 - /my-account/ Terms and conditions: ❌ Page not set

Theme

Name: Twenty Twenty-Four Version: 1.0 Author URL: https://wordpress.org Child Theme: ❌ – If you are modifying WooCommerce on a parent theme that you did not build personally we recommend using a child theme. See: How to create a child theme WooCommerce Support: ❌ Not declared

Templates

Overrides: /srv/users/user13ca2844/apps/user13ca2844/public/wp-content/plugins/woocommerce/packages/woocommerce-blocks/templates/notices/error.php /srv/users/user13ca2844/apps/user13ca2844/public/wp-content/plugins/woocommerce/packages/woocommerce-blocks/templates/notices/notice.php /srv/users/user13ca2844/apps/user13ca2844/public/wp-content/plugins/woocommerce/packages/woocommerce-blocks/templates/notices/success.php

WooPayments

Version: 7.0.0 Connected to WPCOM: Yes WPCOM Blog ID: 227678380 Account ID: acct_1OV7zlCMmuN1d6xV Payment Gateway: Enabled Test Mode: Enabled Enabled APMs: card WooPay: Not eligible Apple Pay / Google Pay: Enabled (product,cart,checkout) Fraud Protection Level: basic Multi-currency: Enabled Public Key Encryption: Disabled Auth and Capture: Enabled Documents: Disabled Logging: Enabled

Admin

Enabled Features: activity-panels analytics product-block-editor coupons core-profiler customer-effort-score-tracks import-products-task experimental-fashion-sample-products shipping-smart-defaults shipping-setting-tour homescreen marketing mobile-app-banner navigation onboarding onboarding-tasks product-variation-management product-virtual-downloadable remote-inbox-notifications remote-free-extensions payment-gateway-suggestions shipping-label-banner subscriptions store-alerts transient-notices woo-mobile-welcome wc-pay-promotion wc-pay-welcome-page

Disabled Features: customize-store minified-js new-product-management-experience product-external-affiliate settings async-product-editor-category-field

Daily Cron: ✔ Next scheduled: 2024-01-06 07:37:46 +00:00 Options: ✔ Notes: 65 Onboarding: -

Action Scheduler

Complete: 4 Oldest: 2024-01-05 07:37:57 +0000 Newest: 2024-01-05 07:45:21 +0000

Failed: 2 Oldest: 2024-01-05 07:43:12 +0000 Newest: 2024-01-05 07:45:21 +0000

Pending: 1 Oldest: 2024-01-06 07:37:57 +0000 Newest: 2024-01-06 07:37:57 +0000

Status report information

Generated at: 2024-01-05 08:05:50 +00:00 `

[csmcneill]

FWIW, I can reproduce this with Google Pay via Stripe.

Here's the network response from the ?wc-ajax=wc_stripe_get_shipping_options endpoint:

{
    "displayItems": [
        {
            "label": "NZ Google Pay Test",
            "amount": 1000
        },
        {
            "label": "Shipping",
            "amount": 0
        }
    ],
    "total": {
        "label": "EXAMPLE.COM (via WooCommerce)",
        "amount": 1000,
        "pending": false
    },
    "result": "invalid_shipping_address"
}

What I think is happening is that Google does not have a way to distinguish the Region as defined in Woo core. Google Pay offers a Suburb field when adding a shipping address, but that doesn't have parity with the Region distinction in the Woo shipping zones. As a result, it creates an error that is similar to shipping a product to a shipping zone that doesn't exist.

[jessy-p]

This issue impacts Express checkout buttons, checkout UI, Local Payment Methods, Buy Now Pay Later (BNPL), and Additional Payment Methods (including Apple Pay / Google Pay), so assigning to Heisenberg (based on team responsibilities Pc2DNy-3z-p2) @FangedParakeet. Assigning as part of Gamma Triage process PcreKM-yM-p2.

[raifd]

Originally reported on 7490480-zen

[frosso]

While investigating this, I stumbled upon a myriad of seemingly related issues. The common theme is, however, how addresses are handled/stored at the WC core level VS how Apple Pay/Google Pay handle/store these addresses.

In the case of NZ, this is how Google Pay/Apple Pay require address data (notice the lack of a "State" field):

In the case of WC checkout, the "Country/Region" is, instead, available (but not required):

What I think is happening is that Google does not have a way to distinguish the Region as defined in Woo core. Google Pay offers a Suburb field when adding a shipping address, but that doesn't have parity with the Region distinction in the Woo shipping zones. As a result, it creates an error that is similar to shipping a product to a shipping zone that doesn't exist.

I also concluded that the underlying issue is that Google Pay/Apple Pay are not providing WooPayments (and thus WC core) with a "State" field value. Given the lack of said value, WC core falls back to the most suitable shipping zone (e.g.: a configured NZ-based shipping zone or a "global" shipping zone).

The issue might require some sort of patch at the core level, but I'll confirm this once I investigate a bit more when the sun decides to return from its nightly hide-and-seek game and brighten up my part of the world again (i.e.: I'll continue investigating more tomorrow).

My plan is to further test the behavior of WC core at checkout (both shortcode and blocks versions) with a similarly-entered NZ address.

[csmcneill]

@frosso We had a deeper discussion on this topic here: p1704361038452359-slack-C3NCP7ZJ6

I did some testing on my site's /cart/ page and it seems to indicate that this is an issue with how Woo core is handling the Region data:

You can test this out a bit on the cart page without using Google Pay:

1. Create a shipping zone that only services Canterbury, New Zealand and Queensland, Australia.
2. Add a shipping method.
3. Add a physical product to your cart.
4. Use a combination of Australia, Queensland, any string of letters for the Suburb, and any string of four numbers for the Postcode.
5. You’ll match a shipping zone created in step 1.
6. Change the shipping address to New Zealand, Canterbury, any string of letters for the City, any string of four numbers for the Postcode.
7. You’ll match the shipping zone created in step 1.
8. Remove the Region (since it’s optional).
9. You won’t match the shipping zone created in step 1.

[FangedParakeet]

I just want to try to sum up everyone's findings here, if my oft suspect reading comprehension can be relied upon.

It seems that we do have a workaround, since defining the shipping zone with zip codes instead of the region allows the validation to progress, so I think that somewhat lowers the severity of this pesky pickle. However, it does appear as if this issue is on the onus of Woo Core, since it seems that the required state field isn't really relevant to New Zealand and it doesn't seem that either suburb or region really represents a congruent replacement for this field either.

In woocommerce/woocommerce#36701, we solved a similar problem with Goopple Pay--as I've recently heard it christened--by removing the requirement of the state field entirely for countries where it is not relevant (in this case, Bulgaria and Hungary). @csmcneill, do you think that would be a suitable solution for this predicament, as well--to be clear, removing the requirement of the state field for NZ addresses? It seems that, in any case, neither state nor suburb or region are required for NZ address validation and the zip code should be sufficient. If that is indeed the case here, that could be a quick win to add this fix to core, judging by the relatively small size of the PR above performing this fix for HU and BG.

[frosso]

PLEASE NOTE: with this comment, I want to show the test results without coming to quick conclusions.

I wanted to validate if the presence (or omittance) of the state/country field would yield to expected results in WC core. Spoiler alert: nothing sus came out of this investigation.

Shipping zones setup 1

First off, I created shipping zones with a country-wide "catch-all". Then, I proceeded testing the checkout with (and without) the county/state field present at checkout for a few countries having different requirements.

This is my shipping zones setup (note that the order they are displayed/saved is important):

With a HU address and no "county" selected (state/county is optional for HU) - Hungary flat rate is returned (which is expected):

With a HU address and a matching "county" selected - state-specific flat rate is returned (which is expected):

With an Australia address and no state selected (state is required) - Australia flat rate is returned (which is expected):

With an Australia-NSW address - Australia flat rate is returned (which is expected):

With an Australia-Queensland address - Queensland flat rate is returned (which is expected):

With a NZ address and no"region" selected (state/county is optional for NZ) - NZ flat rate is returned (which is expected):

With a NZ-Canterbury address - Canterbury flat rate is returned (which is expected):

Shipping zones setup 2

In this second test round, I created shipping zones without a country-wide "catch-all". Then, I proceeded testing the checkout with (and without) the county/state field present at checkout for a few countries having different requirements.

Then, I tried with the following shipping zones setup - in this case, they're all state-specific (and there's no country-wide shipping zone):

With an Australia address and no state selected (state is required) - no rates returned (which is expected):

With an Australia-NSW address - no rates returned (which is expected):

With an Australia-Queensland address - Queensland flat rate is returned (which is expected):

With a NZ address and no"region" selected (state/county is optional for NZ) - no rates returned (which is expected):

With a NZ-Auckland address - no rates returned (which is expected):

With a NZ-Canterbury address - Canterbury flat rate is returned (which is expected):

[frosso]

So, (unless I missed some critical test case) to me, it seems that WC core is behaving as expected. The presence of the "Region" value (or lack of its value) seems to be returning the correct shipping rates.

I initially had some suspicions on Woo core, but it was because I had the shipping zones misconfigured on my local setup (they weren't correctly sorted).

The main problem is that Woo Core allows to provide different rates with a "region" filtering option. But, unfortunately, this "region" (or "state") is not present ( https://github.com/Automattic/woocommerce-payments/issues/7978#issuecomment-1881499433 ) on the Apple/Google Pay address setup. So it's not going to be provided to WC Payments (or any payments provider, really). Unfortunately, the "suburb" field (present in both Apple Pay and Google Pay) doesn't seem to match the definition of "region" in NZ either (i.e.: we can't use the "suburb" field as "region" in WC core).

As far as I understand it, the "region" field shouldn't be used to address an envelope in NZ (hence why it's marked as "optional" in WC core, and why it's just omitted as a whole in Google Pay/Apple Pay).

I could test this only by manually submitting the shipping payload through the ?wc-ajax=wcpay_get_shipping_options action, because Google Pay test mode doesn't allow me to add new addresses.

So this seems to make some sense to me: for New Zealand, setting shipping zones with postcode filtering makes more sense than using state filtering. WC Core doesn't include a matching algorithm for postcodes & country-specific regions.

But I can also see this being confusing for merchants: they're trying to set up a shipping zone for a specific region, but unless the customer enters a value for said region, the rates aren't going to be filtered.

Maybe it would be helpful to include a messaging on the WC Core shipping rates setup settings, to state that if a "region"/"state"/"county" field is used to filter rates on a country that has optional "region"/"state"/"county" fields, the customer might get the wrong rates 🤷 Please let me know if I missed something, otherwise I'll raise this for internal discussion with the core team.

[pierorocca]

"Region" is not something one is going to find in a standard address schema. As far as I can tell, in the shipping zone settings "region" is constructed. In Canada and the US, provinces and states equates to a region according to the shipping zone creator. Italy looks like a list of cities rather than what constitutes a "region" in Italy which actually has regions.

I would expect a standard address to be provided back to core and core then must figure out if that standard address is within the zone as defined by the merchant. Having "region" in the shopper address forms seems very suspect to me and a shopper could literally pick anything they wanted to game the rate if core is not doing any checking against the actual address and postal code.

Thoughts?

[pierorocca]

I'll also add that if you're shipping with a carrier like FedEx or UPS, within country they have proprietary concepts of zones that are mapped to various zip codes. The postal code and country are the key piece of data since with those two pieces of info, you can lookup city, state/province, and the local delivery area.

[frosso]

Italy looks like a list of cities rather than what constitutes a "region" in Italy which actually has regions.

Italy does have regions, but you wouldn't use them in address forms. Instead, you'd use the "province" - which is aligned with what the WC form asks for.

Having "region" in the shopper address forms seems very suspect to me and a shopper could literally pick anything they wanted to game the rate if core is not doing any checking against the actual address and postal code. I'll also add that if you're shipping with a carrier like FedEx or UPS, within country they have proprietary concepts of zones that are mapped to various zip codes. The postal code and country are the key piece of data since with those two pieces of info, you can lookup city, state/province, and the local delivery area.

I am in total agreement that for a NZ address, the "region" seems to be unnecessary 👍 As far as I can see, the address validation is usually part of other WC extensions, due to the nuances between different countries and carriers. For example: the USPS, UPS, FedEx live rates extensions we have in the marketplace do ensure that the address entered can be delivered to, and the APIs will make guesses to provide the best live rates result in case of address "piece" inconsistencies (e.g.: entering a ZIP code that is not valid for the province/region, subtle misspelling, or other nuances).

But in the case of WC core, I doubt that address validation will be built-in in the foreseeable future. In this ticket, we have issues with zip-to-region matching. The matching service would need to be provided worldwide. And even then, the association might not be straightforward. There are exceptions that can complicate things (like US zip codes 42223 or 97635, which span state boundaries). The address validation would likely need to be provided as a service.

In this case, the merchant does not rely on any plugin but uses the WC built-in settings page. The settings page allows merchants to set a filter by choosing a NZ country, but what I think is misleading (in the case of NZ - or other countries that have optional state/region at checkout) is that the merchant isn't informed that their filter could be circumvented if their customer doesn't enter a value for the field at checkout. So I think we could improve the situation by tweaking WC core settings, and inform the merchant of such 🤷

[pierorocca]

So I think we could improve the situation by tweaking WC core settings, and inform the merchant of such 🤷

From a shopper perspective it's overall an awkward experience that one would not encounter on other platforms. I'm wondering if it does more harm than good to subject users to our limitation.

@laurajohnsonwoo would you have a perspective on Core Shipping Zones and how they manifest in the shopper address component?

[frosso]

From a shopper perspective it's overall an awkward experience that one would not encounter on other platforms. I'm wondering if it does more harm than good to subject users to our limitation.

As long as the merchant shipping zone settings are set up correctly (i.e.: the "region" filter isn't used for countries where the "region" is optional), the shopper's experience shouldn't be impacted.

I'm failing to see how the shopper would experience an awkward situation (as long as the merchant's settings are correctly configured).

[paulostp]

The core shipping zone settings make some assumptions as to how addresses are constructed and, in doing so, put on some merchants the onus of finding a way to make WooCommerce work for their country. The "Country > State > Post Code" template works for a lot of countries — the fact that this issue doesn't come up often is proof of that. But, as express checkouts get more popular for online shopping outside the US, these issues are bound to pop up from time to time. Of note that this affects all the payment gateways that support express checkouts, not just WooPayments.

As long as the merchant shipping zone settings are set up correctly (i.e.: the "region" filter isn't used for countries where the "region" is optional), the shopper's experience shouldn't be impacted.

I think the issue here is that the shopper will see that "Region (optional)" field at the checkout, which is a weird experience. For most of my 20 something years shopping online, I've been asked to fill in a "State" field when there are no states where I come from. Back then it was OK, "these foreigners don't know, it's fine". But if a shop that's supposedly based in my home country is showing me an address form that is making stuff up, I will find it strange. Of course, nothing is stopping the merchant from editing code or installing a plugin to make the field disappear, but we're back at my first point of making the merchant responsible for fixing the core behavior.

[pierorocca]

I'm failing to see how the shopper would experience an awkward situation (as long as the merchant's settings are correctly configured).

What I'm seeing is that the region is merchant named and defined. It's not a part of a shopper's mental concept of their address. Parts of an address subject to the whims of how a merchant chooses to define or name it, shifts the burden to the shopper to figure it out. Extra fields, extra work, extra cognitive load. It's not something a shopper encounters on a day to day basis and it would be inconsistent from store to store. Asking a shopper to enter anything but their address to present shipping options smells like an incomplete solution.

I agree with @paulostp (see Paul M's 2024 customer notes on inadequate localization), not localizing properly can be off putting and in some cases make the platform not viable. As a Canadian, seeing State instead of Province in a form is irritating. Localization is important and not impossible. Every country's address format is known and documented and there are a variety of options, paid and opensource, to match a standard address to the merchant defined zone.

[frosso]

Asking here, a "region" (in the case of NZ) is considered like a "state" in the US, and it is part of what people would normally fill on an envelope: p1704802914001699-slack-C9DPRE3AS

[pierorocca]

NZ mailing addresses lack state/province and regions. City, postal, and suburb (optional) only. https://support.nzpost.co.nz/s/article/What-is-the-correct-way-to-address-my-letters?language=en_US

Regions in the NZ context appear to be related to administrative zones over resources and planning. I think it aligns somewhat with counties in the US? Their unitary system of government means there are no states or provinces, only the federal goverment and then local administration/councils. Very interesting. https://en.wikipedia.org/wiki/Regions_of_New_Zealand

[frosso]

Regardless of the solution that will be implemented, we confirmed that the issue is external to WooPayments. I created a separate issue in Woo Core here: https://github.com/woocommerce/woocommerce/issues/43711