Payment-request: Dealing with name as returned by the API (i18n)

[dandv]

Use case: right now the user can enter anything as their name within a payment method. However, some payment processors require a FirstName + LastName. One would think that most users do enter both, but one of our partners has seen orders failing within the first day of launching PR due to users not adding a last name.

[rsolomakhin]

Hi @dandv,

That's excellent feedback and I hope we can improve the API for your needs. Giving up the user's full name on the card would require user consent, which is another step in the UX flow. How about instead we delegate validation to the browser via something like "requireFamilyName": true option? Please let me know what you think.

Cheers,
Rouslan

[marcoscaceres]

Is it the case for people who don’t use, or have, a last name? I’m trying to figure out if the problem is with the API or that particular payment processor.

[adrianhopebailie]

@dandv My guess is that this is an implementation error.

If a card processor is using the name on the card as part of the auth process for a card payment they should not be using PaymentResponse.payerName they should be using BasicCardResponse.cardholderName.

Can you confirm this is the case?

[chinnagogulapati]

Hi Marcos/Adrian,
I am from JCrew, our payment processes CyberSource validates name on the card (BasicCardResponse.cardholderName) and BasicCardResponse.billingaddress.
Billing address validation is mainly to avoid fraud in case of lost card, so we send name on card and billing address too, they validate all the required fields including first & last name on billing address first then send request to Banks.

In this case some users are having one name only not having first & last name in billing address as your UI ask full name in one field, i saw 4-5 rejections from CyberSource saying bill address last name is required after we launched Payment Request API 2 days back .

I hope this information helps.
-Chinna

[marcoscaceres]

In this case some users are having one name only not having first & last name in billing address as your UI ask full name in one field,

The single line entry for all name inputs is correct as per the API. We don't distinguish between name parts because it's nearly impossible to do so on a global scale: please see Personal names around the world.

When it comes to billing information, there are three possible places to get this information (from most authoritative, to least authoritative):

// All single line.
response.details.billingAddress.recipient; 
response.details.cardholderName; 
response.payerName; 

Thus, you will either need to speak to CyberSource to correctly deal with this. Alternatively, you will need to use some heuristics in your application to split the names based on user's locale before sending it up to CyberSource for processing.

[marcoscaceres]

Based on the outcome of this discussion, we should probably draft up some Internationalization Considerations.

[sideshowbarker]

Based on the outcome of this discussion, we should probably draft up some Internationalization Considerations.

(paging in @r12a)

[r12a]

I haven't read the thread yet, but i added an i18n-comment label. That will cause this issue to become visible to the i18n folks via their daily and weekly digests. I'll take a closer look shortly.

[chinnagogulapati]

@marcoscaceres
I understand the i18n concerns, Also spoke to Cybersource and it make sense to me about the validation to avoid fraud.
Why con't we have paymentRequest.addEventListener (paymentoptionchange) and event having select card and billing address data. So venders like us can validate address and return error message to customers, same as shipping address change.

[ianbjacobs]

Hi @chinnagogulapati,

Card data is only available after the user has selected a payment app and approved payment. At this point, the party that called the API can evaluate the response data and determine what action to take, including sending a message to the user and relaunching Payment Request API.

Receiving user data before the user has agreed to pay seems problematic from a privacy and security perspective.

One way to approach this might be to create a new payment method where there is additional data (from the merchant or their service provider) that is made available to the payment app. The payment app could then do some sort of back end validation and try to improve the user experience in the payment app, before returning the final (validated) data back to the merchant side.

Would that make sense and be useful? If so, what would the additional input data be for this payment method?

Ian

[adrianhopebailie]

@chinnagogulapati , thanks for the feedback. I think that it is important to also get feedback from the implementors on where they source that data.

When a user is prompted to provide their name (the input that @marcoscaceres is referring to) that should only be used to populate response.payerName.

If the user is paying by card and the browser is capturing this information (including the "Name on Card") then this should be a new input and returned as
response.details.cardholderName.

If the browser is attempting to optimize this by capturing the name once and using it in both return fields then that is a bug in the implementation not the specification.

@molly26dalton @rsolomakhin Any insights here? Are you differentiating between Payer Name and Cardholder Name?

[rsolomakhin]

Are you differentiating between Payer Name and Cardholder Name?

Chrome differentiates between Payer Name (requestPayerName: true), Cardholder name, and Billing address recipient name (supportedMethodNames: "basic-card" for the latter two). These are three different input fields in UI that the user can set to different values.

[marcoscaceres]

If the browser is attempting to optimize this by capturing the name once and using it in both return fields then that is a bug in the implementation not the specification.

Agree. I don't think (hope 🙏) anyone does that.

[marcoscaceres]

Re-reading this, this is not much actionable stuff to do, so closing.