Re: [w3c/payment-request] PaymentAddress 'region' inconsistencies (#663)

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.
The PaymentAddress doesn't state that a country is a required attribute, so however unlikely it is, an implementation could in theory omit this value in the response and render the whole PaymentAddress useless as it would be too ambiguous to decide which is the correct address.

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?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/663#issuecomment-352725251