Split shipping address from Payment Request API 1.0

[danyao]

Payment Request API currently specifies a standardized interface for merchants to request shipping and contact information from payment methods. However, Basic-Card is the only payment method that supports this interface. The two other payment methods in production, Apple Pay and Google Pay, both implement shipping and contact information collection via method-specific data. Other payment app developers have also requested shifting the collection of such information from the browser to the payment apps.

On the other hand, shipping address is a sensitive piece of personally identifying information of the user. It has been pointed out (e.g. #842) that any interface for collecting shipping address should support richer negotiation to avoid unnecessary collection of user information.

Given the lack of developer interest for the browser to provide shipping address, and the significant development effort involved to fully implement #842, I'd like to propose that we split out the shipping address related behaviors from Payment Request API 1.0 and to be considered in a future iteration of Payment Request API.

[marcoscaceres]

Hi @danyao, you are correct on your description of support. However, I did some testing and requestShipping: true | false is supported by ApplePay over PR API. However, you are absolutely correct in that one can use requiredShippingContactFields: ["postalAddress"] to request a shipping address via ApplePay (and bypass/override requestShipping entirely).

This puts us in a awkward situation in that requestShipping is actually supported by multiple browsers. Happy to discuss further about how we should proceed.

[samuelweiler]

#842 also covers billing address. As I said in #842 (comment), I've seen cases in the wild (in the US) where merchants ask for only postcode for fraud prevention. In #842 (comment) @marcoscaceres observes that billing addresses are (sometimes) used for tax computation, which brings along the full complement of concerns I outlined in #842 (comment), even though my comment makes the opposite assumption about billing addresses being used for tax computation.

As for splitting shipping address out of the Payment Request API: the payment method, whether Basic-Card or otherwise, is still faced with the task of negotiating which portions of the shipping address to share. My understanding from the block diagram @ianbjacobs shared with me is that Payment Request is the only channel to the payment method. If that's true (and perhaps it's not), then Payment Request still needs to have the machinery to pass along the request(s) re: negotiation of address components to the payment method. My open-ended question is: "If this change is made, what channel(s) remain for payment methods to negotiate which portions of the shipping address to share?"

[marcoscaceres]

Presumedly they would use HTML forms or proprietary means (like ApplePay does). @samuelweiler, see my comment above about the proprietary "requiredShippingContactFields" used by ApplePay.

[samuelweiler]

@marcoscaceres thanks. The forms answer makes sense to me. I'm less clear about what happens in the ApplePay case (or, presumably, any case where this negotiation is being pushed to the payment method). Maybe I'm still confused from the block diagram Ian offered. It showed the only channel between the merchant and browser being the Payment Request API.

Which leaves me with: "If this change is made, what channel(s) remain for payment methods to negotiate which portions of the shipping address to share?" How can a merchant iterative indicate that it wants more address granularity (and the reason behind the request)?

[ianbjacobs]

@samuelweiler,

The diagram I shared intended to show where PR API resides with relationship to entities in the payments ecosystem. It did not intend to suggest that it was the only communications channel. As @marcoscaceres indicates, the merchant (or their PSP) can use HTML. I assume that is how the merchant would iteratively request shipping or other information from the user.

[marcoscaceres]

"If this change is made, what channel(s) remain for payment methods to negotiate which portions of the shipping address to share?"

None through Payment Request. One can use a HTML form + the autocomplete attribute.

How can a merchant iterative indicate that it wants more address granularity (and the reason behind the request)?

As above.

[ianbjacobs]

@danyao, what do you think of removing billing address support as well?

Ian

[danyao]

Yeah I think we should remove billing address support as well.

The only "support" for billing address in Payment Request API is the requestBillingAddress bit in PaymentOptions. The interpretation of this bit is delegated to the selected payment app, which returns the billing address via the method-specific details of PaymentResponse. Currently the payment app is also responsible for redacting the billing address when appropriate (Section 18.7)

So if both shipping and billing addresses are removed from the Payment Request API, the end state will be a consistent one: Payment Request API is concerned with collecting common payment inputs (e.g. amount, supported payment apps) and invoking the user-selected payment app via show(). The collection of shipping and billing addresses is the responsibility of merchants, who can either do this via forms, or use the payment-method-specific channel. Note that the vast majority of developers are already doing this today, so the simplification of the spec is just a recognition of the existing usage pattern in the wild.

I believe this will leave the Payment Request API in a simpler state to build upon in the future.

[rsolomakhin]

For the sake of completeness, I'm assuming that contact details (phone, email, name) are also being removed.

[ianbjacobs]

We anticipate adding addresses back to the specification and referring to the Contact Picker API, which was the topic of this issue; we're not reopening the issue at this time, however.

[ianbjacobs]

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