Re: [paymentrequest] Use navigator.payments rather than creating a new object instance (#42)

This issue mixes a number of questions:

1. Should events or Promises be used in the API?
2. Should PaymentRequest constructor or `navigator.paymentrequest` singleton be used?
3. Is the PaymentRequest proposal too high level? Should shipping address be removed from the PaymentRequest flow because it is doing too much?
4. Should shipping address be available as a separate `getShippingAddress()` method?

Here are my thoughts on each of these.

1. Events are used when something may happen multiple times. Promises can only be resolved once. We've tried to use Promises where they make sense and to use events where they may be fired multiple times. Reading between the lines, there's a suggestion that `updatePaymentRequest()` could accept a Promise wrapping the asynchronous work the page wants to do (the suggestion was to "allow the merchant website to provide hooks that may return promises"). That's something worth considering, especially if we believe most sites will need to do something asynchronous in response to the event.

2. I don't yet understand the proposal to change to use a `navigator.paymentrequest` singleton. One reason we went with the constructor approach is that the object has a well-defined linear life cycle from `created` to `closed` and it is much simpler to not have to worry about re-using objects for different payment operations.

3. This is a complex issue and a key one that we need to discuss and solve.
In general, the extensible web approach is to build low level APIs and to allow web developers to build higher level experiences using HTML/CSS/JavaScript. However, APIs that deal with privacy sensitive data (such as addresses) and privileged operations (such as making a payment) need to ensure that users understand and consent to the operations. Understanding and consenting to many low-level operations is difficult to do without confusing and annoying the user. At the same time, payment operations will likely differ significantly between different operating environments and different form factors. The user agent may well have to orchestrate multiple third-party payment applications.
This creates a tension and it is for this reason that we're promoting the idea of incubating different ideas to try to get some experience of what works well before deciding. The PaymentRequest proposal argues for a higher-level domain-specific API that allows the user agent to coordinate the different parts of the request with the goal of creating a smoother checkout flow. It remains to be seen if this will be the best option and we need more experimentation and discussion.

4. With the current API proposal it is possible to make a PaymentRequest and not use the shipping address option. It is interesting to consider whether we should also make the opposite possible so that merchants who want to build a more linear flow where they ask for shipping details independent from payment could still use the API.

---
Reply to this email directly or view it on GitHub:
https://github.com/WICG/paymentrequest/issues/42#issuecomment-173238189