Re: [webpayments] Should a Payment Request API have shipping address APIs? (#39)

> How does this feature reduce shopping cart abandonment?

I tried to address that in the sentence following the one you quoted. Much of abandonment, at least on mobile, happens long before the user arrives at the point of collecting payment information (coming from our research). So to improve only the final step doesn't go far enough.

> For shipping address, we have requestAutocomplete already, why aren't we depending on that?

I suspect you're confusing things. requestAutocomplete was a solution geared towards improving payments in the browser. Shipping was just one component of that. Perhaps you mean autofill? And we could, but this relies on users still knowing that autofill is enabled before dropping off the checkout flow (which they don't, and they drop off). Also, rAc isn't widely supported and will probably be deprecated in favor of whatever payments API emerges from this.

> To be clear, I don't think that anyone is arguing that shipping information is not important. We do want to automate the collection of it. That said, we don't want to automate it in a way that incurs technical debt in the Web Platform.

I disagree that this is technical debt, because I don't see shipping addresses and things like loyalty cards as being in the same category. So I think we can standardize shipping, which again, is ubiquitous to all physical good transactions, and later standardize other assertions or things like loyalty cards.

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