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

@zkoch,

> 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.

In this [research](http://blog.crazyegg.com/2012/11/21/reasons-for-shopping-cart-abandonment/), shopping cart abandonment occurred 22% of the time because shipping costs were displayed too late in the payment process. This, it seems, could only be mitigated by requesting the shipping information (or a shipping estimate at the very least) earlier in the process. The current API would encourage merchants to collect shipping information and display updated final prices at the very end of the process, potentially codifying this portion of the shopping cart abandonment problem into the Web Payments API.

The research also indicates that 44% of shopping cart abandonment was due to the cost of shipping. It seems clear to me that the *change* of price at the last minute, after a user has already done all of their shopping is a very significant trigger for cart abandonment. This can be due to taxes or shipping or other costs that are hidden until too late in the process. Therefore, in my view, if we can, we should try to avoid building a high-level API that suggests that the merchant ought to collect shipping information late and adjust prices after a payment request has already been submitted.

In order to prevent abandonment, merchants need to be encouraged to include the cost of shipping in their products, offer free shipping, or collect shipping/location/taxes information earlier. We should be trying to push them in that direction, yet, I believe the current approach would encourage them to head the opposite way.

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