Adding custom fields next after shipping options have been added.

[mustafa-x]

Some ecommerce sites require extra fields with the shipping details other than the address they are sending to. E.G;

• Type of residence
• Instructions to the delivery driver
• Notes to the merchant

Ideally having an empty text field, which could be populated by the user would work in most cases. Or adding a drop down.

The reason for doing this in the PR API rather than on the merchants site, is the UX flow would seem broken to partially ask for some delivery details on the merchants site and others in the PR API.

The other alternative is to ask for all delivery details on the Merchant side, but this begs the question of why using PR API in the first place when all you are asking is credit card details.

This was originally filed as a chrome bug, moved here for discussion

[rockeynebhwani]

When it comes to "Delivery instructions", other challenge is that every carrier has their own character limits for this field. Typically such a restriction is applied on front end by retailer (provided they know which carrier is going to fulfill the order). If you are going to allow a empty text field, you need to think about this also.

[ianbjacobs]

Hi @mustafa-x,

This topic is one of the earliest that the Working Group has pondered: for the data collection portion of the API, what fields should be supported? Opinions have varied, as you might imagine, and we've reached reasonable consensus on a sort of "minimal" set that can be returned quickly and without typing.

From a UI perspective, I understand that it would be handy to have an extra form field
nearby. But special instructions and notes to the merchant are not likely to stored data
quickly reused, which is the strong suit of PR API.

My expectation (based on WG discussion) is that we may learn through broad deployment
that we need to add additional fields.

In the meantime, it would be great to show some code for how a merchant might
use the PR API response to trigger additional UI (in a Web page) to gather this
information.

For that reason I'm pinging @rsolomakhin and @andrelyver to see if they have
code suggestions, and ideally we would add them to our developer portal:
https://github.com/w3c/payment-request-info/wiki/CodeExamples

Ian

[mustafa-x]

Hi @ianbjacobs

Thanks for replying, one idea that I had that it could be tied to the users address, that way they could auto select it with the address already, but the issue of character limits comes into play.

From a UX perspective I am not sure what the most elegant flow would be, either asking the user beforehand or after. The only issue here is that the user is entering part of their address details through a separate UI and part through the PR API. That feels broken to me.

I am working with some merchants, if this comes up again ill post feedback here.

[rsolomakhin]

@zkoch and I have directed @mustafa-x here because we're reluctant to add these fields to the API. In our reasoning, if these fields are important to the user, the user should add them to the "Street Address" part of their address on file. If the merchant feels the need to explicitly call out the additional fields, they can show <input type="text"> fields after checkout. I'll see whether I can add a clean example of the latter to the CodeExamples wiki.

[rsolomakhin]

See https://github.com/w3c/payment-request-info/wiki/CodeExamples#collect-delivery-instructions

[ianbjacobs]

@rsolomakhin, thanks for the dcode! @mustafa-x, please have a look and share with merchants as part of your conversations. Feedback very welcome!

Ian

[mustafa-x]

Many thanks all!.

I would go one step further with that code example and perhaps call it something more generic such as "Showing user extra UI if the payment is successful", as I can see a couple of use cases for that snippet.

[ianbjacobs]

@mustafa-x, good idea. I have made the change:
https://github.com/w3c/payment-request-info/wiki/CodeExamples#show-additional-user-interface-after-successful-payment

Are you satisfied with this outcome and can we close this issue?

I look forward to more feedback as you use the API.

Ian

[rockeynebhwani]

@ianbjacobs This is better than nothing.. but I can give you another use case where it's absolutely mandatory for merchant to capture some information at the time of placing order (for legal reasons) and it can't be assumed that customer is going to provide this after the checkout. From our experience, not many customers read instructions on thank you page.

Here is the use case -

A merchant offering click and collect / Ship to store functionality sells Knives (some geographies have strict signature requirements on delivery/collection for such items) OR Let's say XBox games (which are 18+). Merchant needs to make sure customer declares in this case that are above 18. In addition to these declarations, obviously merchants are supposed to check IDs.and

Also in some cases some merchants may also ask who will be collecting the item in store and customer placing order can nominate a 'pick up person' to collect the order (You can see Walmart.com for 'pick up person' functionality). This can be provided post checkout as proposed by you and @mustafa-x

[ianbjacobs]

Hi @rockeynebhwani,

My first reaction to the use cases is that the customer assertions (e.g., "I am old enough") should be captured earlier in the checkout flow, before calling Payment Request API. Indeed, the ability to call Payment Request API might be gated on the user checking a box confirming their age.

Ian

[ianbjacobs]

We added addresses back to the specification in the 7 August 2024 CRD