Re: [webpayments] Should we expose status change events in the browser API? (#41)

@dlongley said:
> I believe this can be solved much more elegantly by making the collection of address information a separate operation.

and 

> Another way of looking at this is that the current API allows the payment request to be sent prematurely.

:+1: to this separation of concerns and changing the shape of the API so that the payment request data is not required at step 1 (currently in the paymentRequest constructor). 

I also think @dlongley 's earlier comments about the current shape of the API are very valid and justify a separate issue or should be repeated here: https://github.com/w3c/webpayments/issues/36

As I see it, the case for allowing the browser to help gather shipping address is premised on the fact that this is data many browsers already have (from form auto-complete systems) or will gather each time a user makes a purchase. The goal is to leverage this and allow the UA to gather the shipping data on the merchants behalf as part of the "check-out" flow, using the same UI that will be used for the payment, thereby making the flow slicker and hopefully reducing abandonment.

The current shape of the API (a single API call that both submits the payment request data and attempts to gather shipping data) is based on this goal in an effort to create a mechanism by which the UA can reuse the same dialogue to gather the shipping data and get the user's payment app selection.

I propose that it is possible for UAs to offer the user what appears to be a seamless flow (gathering shipping data and then processing the payment) using separate API calls from the website.

I made a crude example of that here which surfaces a few ideas about how this might be acheived: https://github.com/w3c/webpayments/issues/39#issuecomment-165488995

In the example I used the Credential Management API which I think in the long term is the correct way to do this. I am open to suggestions as to how this same thing might be achieved in the short term without compromising the payment API.

Would it make sense for there to be an API function like:
```javascript
navigator.payments.getShippingAddress(...);
```
which becomes a shortcut to this in the long term:
```javascript
navigator.credentials.get({"type": "shippingAddress", ... });
```

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