ContactAddress 'region' inconsistencies #65
Comments
|
Two-letter codes could work for India using the As for requiring the region in every country, from what I understand, that does not work well in all countries. For example, Google's address in Ireland is "Barrow St, Dublin 4". I do not have to specify the "Co. Dublin" county in order for my package to be delivered there. All that being said, we can do a better job of normalizing addresses that we return from the browser. I definitely agree that Chrome should not be returning "Californnn" in the API. |
|
Thanks for your response. Three letter codes would be fine for Australia. Even 1 letter codes for Ireland - if the response values were always consistent and therefore an expected value. I understand what you mean in terms of requiring the region in every country maybe not working the best. I am actually located in Ireland, and you are correct, we don't always need the county (however that is only in Dublin where there is Dublin 1, 2, 3, 4, etc.). Therefore, we are used to always stating our county also on most address forms, or making our addresses fit online forms. If these addresses were just for reference / printing on a shipping label, there would be no issue. It really is that need to validate addresses against regions, especially in countries where it is common for merchants to only ship to certain regions within a country. Coming from a country where our addresses don't usually fit online address forms (also only introduced postcodes in the last year or two), I don't think it is much effort for users to enter their region once off in their browser saved address, as they would then have all the benefits of using payment request checkout thereafter. |
|
Those are all very good points. What should we do for countries that don't use regions (e.g., Denmark)? |
|
I think this is again a quality of implementation issue, but possibly something we need to add more guidance on in the spec. The browser should be validating region/state information based on the user's country choice... and some countries need to have a mandatory state option, like in Australia. Would that work? |
|
The issue I have with the 'quality of implementation issue' argument is that this is what has been the issue in the past where vendors implement a spec somewhat differently according to their own interpretations, which is the case at point. This has led to small or sometimes very large differences in the implementation, that the developer community has to negotiate around, leading to a typically bloated codebase being pushed down the wire to end users and the expense that comes with that to all parties. This leads to slow adoption of the API by the developer community or in a worst case scenario, prohibits adoption altogether which is definitely something we don't want to see. I would definitely add guidance to the spec, but would probably like something more prescriptive as to the required attributes in a PaymentAddress response. I propose that we indicate what is required or non nullable to the interface for certain attributes in the PaymentAddress, specifically (country, addressLine, city & recipient). For the 'region' attribute, the guidance should be updated to return an ISO 3166 code also, otherwise null for countries such as Denmark as noted above. What do you think? |
|
Countries that don't use regions shouldn't be an issue. If we refer to our main issue which is validating a shipping address's region against the regions in that country for selecting region specific shipping options - we wouldn't have this issue for a country with no regions, as the shipping options would not be region specific. However, just while on topic - I have seen that for the Qatari address form, there is no 'region' when regions are in use in Qatar https://en.wikipedia.org/wiki/ISO_3166-2:QA, where I have requests from merchants for shipping options defined for certain regions. It seems to be the same for Denmark https://en.wikipedia.org/wiki/ISO_3166-2:DK. |
|
It sounds like mandating ISO 3166-2 for region would be the way to go (where applicable) - and null or empty string otherwise. @aestes, @adrianba, @rsolomakhin, @mnoorenberghe, @zkoch... it's a fairly significant change to implementations, but it does resolve a potential huge mess for merchants who would otherwise get a bunch of different values (as @TSMatthews points out). This is what browsers do now:
If there is agreement that ISO 3166-2 is the way to go, then I can add this to w3c/payment-request#654 |
|
@marcoscaceres: The ISO codes would be OK for us. @sebsg: Can we use the |
|
@marcoscaceres: Would it be better to introduce an additional |
|
Could be, but it would still leave |
|
For Chrome is should be possible to use the "isoid" when it's present. We
would just need to figure out what to return if it's not available.
…On Wed, Dec 20, 2017 at 8:55 AM Marcos Cáceres ***@***.***> wrote:
Could be, but it would still leave region potentially too unrealiable to
be useful and add a vector for error (the two might not agree or browser’s
language might not match site’s language, leading to confusion). That might
be ok tho.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#65>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AaKMa2EKfO_sph8WH5lZpoBVq_zhHZGJks5tCRHcgaJpZM4RDnkl>
.
--
Sébastien Séguin-Gagnon | Software Developer | [email protected] |
|
|
Empty string is fine. |
|
agree, that’s what we do with the rest of them. |
|
@sebsg : That's empty string for the |
|
Sounds good! The "region" might still contain useful info for the merchants
for cases where we don't have a "region_iso_id".
…On Wed, Dec 20, 2017 at 11:46 AM Rouslan Solomakhin < ***@***.***> wrote:
@sebsg <https://github.com/sebsg> : That's empty string for the
"region_iso_id" field, to be clear. No changes to the "region" field.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#65>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AaKMa4sawszV-eTsjNu3pDinRjOPPhcMks5tCTnigaJpZM4RDnkl>
.
--
Sébastien Séguin-Gagnon | Software Developer | [email protected] |
|
|
|
that works |
|
Ok cool, I’ll draft something up. |
|
@TSMatthews, would appreciate your thoughts also as we proceeded. I’ll ping you also for review if that’s ok? |
|
@marcoscaceres happy to review. Just to clarify on the addition of the new field (regionCode / region_iso_id) - is this now the field that will be mapped to from the 'region' dropdown on the UI (if there are regions for the country in question)? Want to be clear how both of these fields - 'region' and 'regionCode' would coexist and what we collect from the user. As a note, chrome was mentioned above as always being a free form input for region - seems to be dropdown on web with mapped values (inconsistent format depending on country), input on mobile. |
|
Sorry for the delay - not many people about in the office at the moment for some reason...
Right now, Microsoft Pay adheres to Microsoft-wide GeoPol standards. It's not out of the question for us to change but is going to require conversations with a bunch of teams so we'll have to investigate in the New Year. |
|
@TSMatthews, sorry for the delay... just coming back to this now:
At least Could that work? |
|
@TSMatthews I've staged the changes here: If you prefer to read them in HTML, please see w3c/payment-request#654 (there is a "preview" link at the top, but includes all the changes I'm planing to make to |
|
@marcoscaceres Thank you. 'regionCode' does seem like it will help the inconsistency issues as it must be valid ISO3166-2. Just so I am clear.. the forms could still have 'region' or 'regionCode' right? And it's really up to the browser vendors to implement it? We would not have 'regionCode' being an expected field returned from every address form? 'regionCode' solves inconsistency of value issues, but if it's not a mandatory field, it won't fix our issue that we always need this value (original post -> need region as consistent data and always present, so that we can verify against shipping rules / options specific to certain regions). |
|
@TSMatthews
For Chrome, "regionCode" should be present most of the time. We have the
data for most countries and I'm trying to get the data for the rest. The
reason we cannot guarantee it however is that the ISO standard moves pretty
slowly. So as things change in a certain country, it might take a while for
the changes to get into the ISO. In that case, we don't want to block the
user so we would send the merchant only the "region". This should be pretty
rare though.
Hope this helps!
Le ven. 26 janv. 2018 08 h 17, TSMatthews <[email protected]> a
écrit :
… @marcoscaceres <https://github.com/marcoscaceres> Thank you.
'regionCode' does seem like it will help the inconsistency issues as it
must be valid ISO3166-2.
Just so I am clear.. the forms could still have 'region' or 'regionCode'
right? And it's really up to the browser vendors to implement it?
We would not have 'regionCode' being an expected field returned from every
address form? 'regionCode' solves inconsistency of value issues, but if
it's not a mandatory field, it won't fix our issue that we always need this
value (original post -> need region as consistent data and always present,
so that we can verify against shipping rules / options specific to certain
regions).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#65>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AaKMaxf-ajCA5IrwqEC5HOAaPnqrGrNgks5tOdBrgaJpZM4RDnkl>
.
|
We planned to use dropdowns backed by the ISO 3166-2 codes but that didn't get implemented yet… not sure what we'll ship for an MVP. We do already try to normalize to the region codes where possible e.g. we know that California => CA. @TSMatthews It's still not clear to me from the discussion whether you are expecting the |
|
@sebsg You wrote: "We have the data for most countries and I'm trying to get the data for the rest." Is this an open-source dataset (or standardized registry) that other implementations can use? A common approach would help reduce user confusion across browsers. @mnoorenberghe The original posting from @TSMatthews mentioned shipping options, so it seems that we wouldn't necessarily need to gather the |
IIUC, it's from https://github.com/googlei18n/libaddressinput/wiki/AddressValidationMetadata and it's what we use in Fx already.
Shipping options require knowing two things:
My point is that in order to know (1), you may need to know the region if there are regional laws (e.g. if one province in Belgium prohibits the purchasing of ivory). libaddressinput doesn't currently have regions for Belgium and indicates that they're not required for mailing labels so it's easiest for us to pretend they don't exist but I'm trying to get this understanding standardized as I don't want some browsers returning regions for Belgium and others not. |
I don't know if we can standardize that behavior. That seems overly prescriptive and would be too closely tied to libaddressinput (which neither Edge or Safari rely on). |
Sorry, just noticed this reply now… What I'm talking about isn't tied to libaddressinput at all. It's tied to whether the country writes subdivisions as part of their mailing address (e.g. on an envelope). Since users won't expect to be asked to select their subdivision for a shipping address in some countries that don't use them for mailing, I expect that in Firefox we won't show a subdivision field and therefore won't populate the region or regionCode fields for those countries such as Belgium, Germany, etc. Perhaps the spec and/or MDN should be more clear that an empty string can be valid for mailing purposes. |
Good point. I'll spin up a separate issue to clarify! |
|
We failed to get this implemented across UAs in a timely manner, but we remain committed to having this in the spec. Our plan is to remove regionCode from V1 of the spec, but immediately add it back as v1.1 of the spec. We hope that will buy implementers some time to implement the feature, but without delaying the standardization process. |
marcoscaceres
changed the title
aphillips
added
the
i18n-tracker
I'm having a number of issues integrating our checkout with the payment request API when it comes to shipping options / shipping address forms. These centre around the address 'region', e.g. 'CA' in the US.
Project info / requirement
To give some background, I have a requirement to have shipping options that are available to certain regions within a country. This could be for legal reasons, e.g. in the US, only being able to ship certain goods to certain states. I must therefore, verify user inputted address region values against our shipping options when determining which shipping options to pass to the payment request interface.
Lack of 'region' input
Depending on the country however, sometimes the region is mandatory (US, Australia), optional (Ireland), missing (Qatar). Can this field be mandatory for all countries? (i.e. we would need 'region' to be mandatory in all cases so we can verify our shipping options against the user's country and state)
Inconsistency of input type and value
For both address forms that could be used, i.e. billing and shipping, the value retrieved from the user is not in a consistent format, in terms of input type and response value. On web browsers (as far as I've tested), the region is a dropdown. However, depending on the country, the value returned is not consistent, e.g. it's a 2 letter code such as 'CA' for the US, state name such as 'Delhi' for India, and 'Co. Dublin' for Ireland.
On mobile browsers (and possibly some web, but generally mobile), the 'region' is a free form input, so the customer could enter anything essentially, e.g. 'CA', 'California', 'Californnn'. In this case, we have no direct solution for mapping this value.
Overall solution proposal
The text was updated successfully, but these errors were encountered: