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

I think it's premature to try and resolve this question without seeing how the API would be implemented and used through some demos or wireframes. This issue is highly influenced by UX.

@msporny makes an argument against gathering the shipping address through the API on the basis that this should be done through more appropriate APIs.

The counter-argument is that browsers already hold this data today and should use it to make the checkout experience better for physical goods purchases AND the payments work should not create a dependency on work that hasn't even been chartered yet.

The flow is as follows:
 1. Request shipping address (website)
 1. Get shipping address from user (browser)
 1. Calculate shipping costs (website)
 1. Request payment (website)
 1. Get payment app selection from user (browser)
 1. Process payment request (payment app)

There is a UX-related argument that context switching the user between an address selection dialogue, the website and then a payment app selection dialogue is too much friction. i.e. Completely separate APIs and UI for steps 1 - 3 and then steps 4 - 6 as proposed will be a bad UX.

So there is a requirement to either:
1. have an API call for step 1 and another at step 4 but to reuse the same dialogue which never loses focus (thus making the UX seamless) but goes into a waiting state during step 3.
1. make a single API call at step 1 that instructs the browser to prompt the user for a shipping address as part of the flow

The advantage of 1 is that we have a separation of concerns between getting the shipping address and the payment request. This may negate the need to manage state of the payment request. The disadvantage is that if the website gets the shipping address and then never calls the payment request API you could have a dialogue in focus waiting for the website (and not taking input from the user). So to support this model you'd need to give the website an ability to close that dialogue explicitly or indicate that it will not be requesting a payment afterwards.

The advantage of option 2 is that the browser worries about when to show/hide the dialogue but this introduces a need for the website to be able to update the payment request mid-flow, in effect creating a similar flow to option 1. This seems like a poor design; if there is a high likelihood that the website will update the payment request after initially creating it then why force it to be created at step 1 at all?

COUNTER-PROPOSAL:

The API should allow the website to leverage the ability of the browser to efficiently gather a shipping address by exposing a function to do so. In time this will be deprecated in favor of more generic APIs like those being worked on by the VCTF. This API endpoint should be separate from the payment request API endpoint.

The API should also support the use case where the website does not intend to submit a payment request once it has the shipping address, or this process times out.

Example:

```webidl
interface ShippingAddressResponse {
    Promise<void>                 closeDialogue();
    ...
}

[NoInterfaceObject]
interface Payments {
    Promise<PaymentResponse> requestPayment(...);
    Promise<ShippingAddressResponse> getShippingAddress(...);
};

partial interface Navigator {
    readonly attribute Payments payments;
};
```

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