Recipient and payerName are lacking i18n support

[nickjshearer]

We have two properties right now, recipient (in PaymentAddress) and payerName (in PaymentResponse) which are hold a user's full name and are plain DOMStrings.

I think this is going to cause a few problems for internationalization.

Firstly, merchants and websites won't be able to infer the correct ordering, since in many countries the family name comes before the given name (e.g, China). This will cause problems, since for many merchants they may want to address the user by their family name or otherwise format it for communications. Additionally it's not defined whether implementations should or shouldn't return prefixes (Mr, Ms, Dr, etc), making it harder for parsing to occur.

Secondly, and this is less important but still relevant for i18n, sometimes users may wish to provide (and merchants may wish to receive) a phonetic representation for the name in addition to the name itself.

I think we need to consider replacing the plain DOMString with a better data structure that at the very least has distinct fields for given and family name, and ideally with room for expansion to additional fields like a phonetic representation.

[marcoscaceres]

@nickjshearer, would https://github.com/w3c/browser-payment-api/issues/480 address this?

[nickjshearer]

Yep, I'm happy with that.

[aphillips]

Actually, breaking the customer's name into component fields introduces internationalization issues that are potentially not present with an opaque string representation. With a single "full name" string, the user can input their name however they like it to be displayed. Implementations can't infer family or given name or do operations like sorting, but modeling these is complex. Does your specification really want/need that?

[r12a]

For further background information on @aphillips comments, see
Personal names around the world
https://www.w3.org/International/questions/qa-personal-names