contact-picker
contact-picker copied to clipboard
w3c
Add payerGivenName + payerFamilyName to PaymentAddress
It would be good to then clarify that payerName would be the user’s preferred rendering of their name.
Yes, that works for me. I would prefer we provide a hint as to the ordering instead of the full name, but I appreciate some implementors have shipped already and that would be a breaking change. Additionally we can then use payerName to indicate not just ordering but other potential information.
Some background - this is an important requirement for certain sectors and markets such as Asia. Additionally, merchants in the travel and financial industries often have regulatory or legal requirements to collect names in a standardized format.
What do you intend to do for people who only have one name? are both of these optional fields?
Have we checked with the travel/financial industries what they expect to be in each field? e.g. middle names: are they put with given names? This would be in addition to fullName: would we not risk then that both are filled in, but that they are inconsistent?
@nickjshearer, do you some insights about the above and what the conventions are for things like middle names, etc?
I'm postponing this, as unfortunately we've not received any response from @hober.
I'm not sure I have all that much insight here. Here's a little bit of background:
PassKit generally handles names in component form. This wouldn't be much of a problem for PaymentResponse.payerName (we could compose the single field from what we get from PassKit), but it's problematic for PaymentAddress.recipient, as we'd have to figure out how to decompose the name into an NSPersonNameComponents object. It's not impossible, but it'd be much better to be able to pass-through name components directly.
Whether or not this is something that needs to be addressed before entering LCCR is not obvious to me. If it isn't, I guess we'll raise it as a CR comment.
I just now saw this. I don't think either @r12a or I saw this previously for some reason. I added a comment to w3c/payment-request#471 and am a little concerned that this proposal overlooks the problems inherent in personal names--these can have multiple fields (not limited to 1 or 2) and different rules associated with them. Splitting names into fields introduces the need to account for the cultural and functional (such as sorting) variations associated with personal names.
This is not to say "don't do it". Only that this proposal appears inadequate/incomplete.
@hober: How is PaymentResponse.payerName different from PaymentAddress.recipient? I thought these fields contain the same type of info: full name of a person.
Just noticing this thread now. (For future reference, @ianbjacobs and others, note that if you stick the i18n-tracker label on an issue, the i18n WG will be notified about it for each new comment.) I'll add it to our tracker, and read the thread...
@r12a and @aphillips could you have a look at this proposal?
@ianbjacobs do you have a link to 'the proposal' ? tx
@r12a, I'm not exactly sure what "the proposal" is. Is it simply the front of this thread? https://github.com/w3c/contact-picker/issues/69
(I welcome help from the Editors here.)
Ian
@ianbjacobs I think we will postpone to after we go to CR. That will give @hober and friends at Apple time to figure out if they can make this work with NSPersonNameComponents... and if we do need to add these things after all. Fingers crossed we can do without! 🤞
@aestes, can you kindly take a look at the discussion in this issue? With respect to WebKit's implementation and NSPersonNameComponents, where you able to make things work in your implementation without requiring payerGivenName and payerFamilyName? If so, can we close this?
The issues summarized at https://www.w3.org/International/questions/qa-personal-names make me wonder if it's a good idea to add payerGivenName and payerFamilyName. At the least, it would help to have a clearer idea of the motivation and requirements here.
@stpeter That Q+A document does summarize the range of variation and the problem space inherent in personal names. Using a single, undivided field is an avoidance tactic. The other end of the spectrum, familiar to implementers of address book and contact applications, is a much more complex, nuanced data structure (which is usually coupled with locale-based presentation to hide unneeded complexity from e.g. your US English customers unless/except where they want it).
Given+Family is a pretty common pattern that, while by no means universal, can be made sensible as an intermediate compromise between an opaque single-name-string and the full richness of human culturally linked naming. When it is the only structure for personal names, that usually leads to bad compromises for cultures that need more/fewer tokens for a name. If it is an adjunct to the opaque name string (payerName??) to allow a richer set of features, that might be okay. I would probably go at least one more step and allow for pronunciation fields (in Japanese, the "yomi") so that the resulting structure could be used for sorting a list of payers in Chinese/Japanese. But there is a slippery slope here.
Thanks @aphillips for weighing in.
As one data point, it might be interesting to know what credit card issuers require for naming throughout the world - even though from a Web Payments perspective (a) in the long term we don't want to be tied to credit cards and debit cards as payment instruments and (b) things like prepaid cards don't have names associated with them.
Furthermore, it would be helpful to understand the requirements here. For instance, is this needed for sorting or validation, and by which parties in the ecosystem (merchant, payment service provider, etc.)? Knowing that might help us figure out if this is really something we want the user agent to handle and enforce.
@xfq @marcoscaceres Thank u for telling me this discussion here.
I am native Japanese speaker. I know there are deep-rooted problems there.
I don't want to consider about the meaning / structure of the name. Indeed, I think simple specification is good too.
But, In Japan almost all people's names are represented in Kanji character like '山田太郎'. The name '山田太郎' is composed from family-name '山田' and given-name '太郎'. Some younger people write it as '山田 太郎' so that we can distinguish which one is the family-name. But it is not formal representation, Japanese text-book always represent full-name like '山田太郎' without space delimiter.
In-Japan, family is important because family-registration by the law. Though younger people do not think so anymore. But there is a long long history and legal system. These system had introduced from China about a thousand year ago. So, I think It is common problem in Asian countries. In Japan, different family-names in a single family is also not allowed by the law.
Some people might wonder what is a problem. Single full-name fields is enough? No, because In Japan, almost all system require family-name and given-name. Especially, delivery carrier's system require these fields separatedly. I can't explain reasonable reason why they use these fields separatedly. But they uses, and almost all people don't care because it is a common-sence.
Here is an example implementation of Google contacts.
And when I enter these fields, and save it single full-name field is automatically generated like below.
I think Google and Apple doing well in this area. I know it is hard work to defining these feature in standard specification
But i'm glad if I can pass paymentOption object like {requiredPayerNameFields: ['familyName', 'givenName', 'phoneticFamilyName', 'phoneticGivenName']}.
Also need to consider about shippingAddress too.
In Japan, it is enough. I don't need to require 'middleName' or 'phoneticMiddleName' though other people who uses another locale has diefferent requirements.
Sorry for the long text, and thank you for reading my opinion.
This issue was raised in Payment Request, but closed once we removed addresses from that API. Since the features are now part of Contact Picker, we are transferring the issue here.
