Re: [webpayments] ACTION: Summarize arguments for/against shipping address capture (#72)

I don't understand the relevance of the branding topic to the question in this issue.

At the heart of the PaymentRequest API, our goal is to make it easy for people to complete checkout flows with less effort and fewer errors. We will also support payment methods that allow transactions to be more secure. The hope and expectation for merchants is that this will increase conversion rates.

A lot of people buy and sell physical goods on the web. These goods need to be shipped to an address. Capturing the address as part of the flow allows greater innovation in finding a flow that is less effort and brings greater conversion rates.

One of the strongest arguments for not capturing shipping addresses is that it is hard to standardize and consequently we could do it later. There might be other standardization efforts that will solve this for us. I understand this argument (and I am using it in response to many other issues - i.e. they don't need to be in v1) however shipping physical goods is such a core use case that I think we _should_ try to solve it in v1.

At some point we are going to have to solve for billing address for some of the payment methods we support so it is almost inevitable that we'll have to solve for addresses. Once that is done, the incremental different to shipping addresses will hopefully be small. It is common for sites to offer to ship to your billing address as a first choice, for example.

David Singer's point is an interesting one but I think we're too far away from that being a reality in the short term. It seems unlikely we'll get much merchant adoption if the API proposes an approach too different from current flows. We need to ensure that there is an easy path to integrate the API into existing sites.

So my proposal is that we continue trying to solve for shipping address - it is too early to give up because it is hard or because we think someone will do it for us. Perhaps we won't be successful but this issue is premature: there's equally no evidence that we won't.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/72#issuecomment-182735697