International Address Validation Problems

Leafcutter

We do quite a bit of international sales and are making extensive use of the international address lookup and validation system that's built into FC. By and large, it's been really helpful for folks. That said, we are starting to accumulate a list of strange behaviors, incorrect validations, excess information requests, etc.

For example:
• The UK no longer requires that counties be included in the address, but the system includes them by default. This adds a 6th line to the address, which mucks up our import to USPS because only 5 lines are allowed.
• Ecuador and UAE (among many others) don't use postal codes but the system requires the customer to enter one anyways, which leads people to abandon check out.
• Some valid Dutch postal codes won't validate, making it impossible for some folks to successfully check out.

What is the proper channel for feeding these bug and fix requests to whoever manages the international validation system? We'd be happy to help knock them down one a time to improve the system for everyone. Thanks!

fc_adam

@Leafcutter,

Posting them here is fine!

We can update our locations object to not require postcodes for countries that don't require them. If you can get us a list of those, we can do that.

Similarly, we can set countries that don't require a region to be specified to set that as not required.

For the Dutch postal codes, could you get us some examples of ones that aren't working that should be?

Leafcutter

@fc_adam - Okay, here goes Round 1...

Countries for which Postal Code should NOT be required
• Ecuador
• UAE
• Qatar
• Hong Kong
• Panama
• We will keep a running list of others

UK Region/County
It seems the checkout form is adding the county/region automatically for all UK addresses, based on the postal code lookup. Try postal code: CB43DB with country set to United Kingdom to see what I mean. "Church End" is the city (we need this), and "Cambridgeshire" is the county (which should not be part of the mailing address). Setting the region as not required won't actually fix this issue, because it's not a separate field requiring entry to begin with. It's just extra data being appended to the city info. Any ideas how to fix this one? Here's more info confirming that Royal Mail dropped the county info from the address system back in 1996:
https://en.wikipedia.org/wiki/Postal_counties_of_the_United_Kingdom

Dutch Addresses
There are many many thousands of Dutch postal codes, as each one only covers about 10 houses, so we have no idea how many may or may not be validating properly. An example of one that won't validate, but is valid with Google Maps, is: 2162 BT. Note that the checkout page fails to match City = "Lisse". It then seems to accept manual entry for City and State, but then if you do that and place the order, it tries to validate the zip code again before submitting, which erases the manual City and State entries, and then order fails due to missing City and State. Finally, this "State," entry box can be removed as State is not required for Netherlands.

Thanks much!

fc_adam

@Leafcutter,

Non required postcodes
Thanks for those - I've created a ticket to update those countries

UK Region/County
Ah, thanks for clarifying. I can see what you mean now. As best I can tell, while county information isn't required anymore, it can be optionally included if you like. From what you said though, you're hitting this issue with importing into USPS's systems which don't allow for the additional line. I'll create a ticket to look at altering how our automated lookups work for countries that don't require the region/county information. Is there any way to alter your import in the meantime, as unfortunately I can't give you any timeframe of when we might be able to make that change.

Dutch Addresses
Thanks for that example. I can see from a quick search, as you noted, that it is a valid postal code - but our lookup service isn't recognising it. I'll reach out to our provider there and see if they're aware and when an update might be possible there. For the region - it's already marked as not required, so while it's displayed it's an optional field for completion.

Leafcutter

@fc_adam,

Okay re non-required post codes, thanks!

Re the UK county issue, the county data is hard to strip during import because it's not being provided in a separate column. It's attached to the city info in the same field, so there's no easy way to dump it without also losing the city. So let us know what you learn on that one. In the meantime, we will strip it manually on the Endicia end of things whenever the address renders too long.

Re Dutch postal codes, I just tried two more (9945VD and 5554BC) and they also did not return matches. So this problem may run deep. Perhaps the Dutch postal code lookup just isn't working at all?

fc_adam

@Leafcutter,

The city and state data should still be provided in their respective city and state columns when exporting the transaction through the API, webhooks or transactions exports. How are you receiving the information?

Leafcutter

fc_adam,

You're right, the UK county does indeed export via the "State" column on its own. Good to know. We use OrderDesk and I don't see an obvious way to strip out the State data only in instances where the country = UK. We'll look into it tho. Thanks and let us know if/when the Dutch postal lookup issues get cleaned up.

dustystrings

Has the issue with postal codes been fixed? We're still experiencing the occasional abandoned cart from customers in Hong Kong because it's requiring a postal code and they don't have one. If that did get fixed, is there something we need to update on our end?

UP

Ireland also don't use postcodes, another one to add to the list.

fc_adam

Sorry for the delay in updating this thread. We did recently roll out a fix for the postal code requirements for some countries. The ones mentioned in this thread have all been updated (or already were) and postal codes should no longer be required for those countries in 2.0 stores.

dustystrings

Just checking in on this again, since we've had a couple of issues this week with Ireland and Hong Kong addresses not being accepted without a postal code. We get the error: USPS Error: DestinationPostalCode is required when AcceptanceDateTime is populated.

Your post says the postal codes should no longer be required for those countries, so I'm wondering if we need to manually update something on our end to implement that fix. We're using 2.0 with a fair amount of custom shipping logic.

Thanks!

fc_adam

@dustystrings,

The postal code not being required is something related specifically to our checkout validations - meaning the checkout marks the customers information as completed even if they don't provide a postcode for countries that don't require it. It looks like USPS does require the postal code though - and that's not something that our checkout validations will control.

In that instance you'd need to set the postal code back to required for Ireland and Hong Kong. To do that, you would add this to your store's custom footer within the "Add custom header and footer code to your templates" configuration option:

<script>
function updatePC() {
  FC.json.config.locations.HK.pc.req = true;
  FC.json.config.locations.IE.pc.req = true;
}
{% if cart_is_fullpage or context == 'checkout' %}FC.client.on("ready.done", updatePC);{% else %}updatePC();{% endif %}
</script>

dustystrings

@fc_adam,

Ok, I see. Silly USPS.

It looks like you can fake a postal code (put a 0 in that field) and it'll go through without throwing the USPS error, so I'd like to find a way to let customers know that. Ideally, a message would show at the bottom of the checkout shipping address section, but only if they've selected HK or IE for the country. I've tried this in my checkout template, but nothing happens, so likely I've got it wrong! Can you help?

    {# SHIPPING ADDRESS ===================================================== #}
    {% if shipping_address.has_shippable_products %}
        <section data-fc-id="block-customer-shipping" class="fc-checkout__section--customer-shipping-address">
        {{ block('customer_shipping') }}
        </section><!-- data-fc-id="block-customer-shipping" -->
    {% if (shipping_address.country == IE or shipping_address.country == HK) %}
        <p class="no-postcode-message">If your country does not require postal codes and you do not know what your code is, try entering 0 in the postcode box.<p>
    {% endif %}
{% endif %}

fc_adam

@dustystrings,

You're very close - you'd need to wrap the two country codes in quotations like "IE" and "HK".

dustystrings

Thanks @fc_adam, that got me on the right track. I actually ended up taking out the if statement and adding a script to the footer to toggle the message on and off when the country is changed. It seems to be working, but if you wouldn't mind taking a quick look and letting me know if you see anything that's missing, that would be awesome!

In the checkout template:

        {# SHIPPING ADDRESS ===================================================== #}
    {% if shipping_address.has_shippable_products %}
        <section data-fc-id="block-customer-shipping" class="fc-checkout__section--customer-shipping-address">
        {{ block('customer_shipping') }}
        <p class="no-postcode-message">If your country does not require postal codes and you do not know what your code is, try entering 0 in the postcode box.<p>
        </section><!-- data-fc-id="block-customer-shipping" -->
{% endif %}

In the custom footer:

<script>
function togglePostcodeMessage() {
	var country = FC.json.shipping_address.country;
	if (country == "IE" || country == "HK") $(".no-postcode-message").css("display", "block");
	else $(".no-postcode-message").css("display","none");
}
FC.client.on('ready.done', togglePostcodeMessage);
FC.client.on('customer-address-change', togglePostcodeMessage);
</script>

fc_adam

@dustystrings,

Nice approach - if that works for your needs then you should be good to go. Instead of hooking into customer-address-change you could just hook into render.done. It would make the function run more often than it'd need to in reality, but it shouldn't cause any issues and would ensure the message always displays as it should.

dustystrings

Thanks a bunch!