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

@adrianba 

> This issue mixes a number of questions:

Yes, happy to split them out if you like but they seem linked/dependent and worth addressing together.

> Should events or Promises be used in the API?

The API will use only Promises or both Promises and Events.

I think we are mostly in agreement that the website should call an API,  supplying a payment request, and in return will get a promise that resolves to the final payment response.

At this point the website no longer has focus so it can do some asynch processing but nothing that requires user interaction.

Which begs the question, do we need events at all? That will be implicitly answered by addressing https://github.com/w3c/webpayments/issues/55

i.e. Are there interactions with the browser or payment app that will require the website to update the payment request? _(Getting the shipping address is an example of one but whether that is included in the payment request is still under debate -- my point about these being linked issues)_

If not, why complicate the interaction with the API using events. Why does the website need to track the state of the payment request at all? As discussed in the issue above there are pros and cons to both approaches (having and not having events) and I suggest we look at the flows and use cases to determine which is best.

> Should PaymentRequest constructor or navigator.paymentrequest singleton be used?

There is a third option, use the PaymentRequest object but don't provide the payment details in the constructor. My strongest objection to the proposed pattern is that the website must instantiate the payment request at a time when it may not have all the data it requires. Where possible we should make it easy for the website to _prepare_ the payment request and gather all of the data required to do this before _making_ the payment request.

My argument in favour of using a static (or singleton) `payments` object that is an attribute of the `navigator` is that I don't foresee the website ever having multiple payments requests in flight at the same time (or put another way, ever instantiating multiple PaymentRequest objects).

The UI pattern that has been proposed precludes this from happening unless the payment can be executed without the website losing focus (i.e. the payment app can process the payment without needing input AND we support this pattern - seems challenging on mobile).
 
> the object has a well-defined linear life cycle from created to closed

This seems like an argument in favour of using a static object.

As has been pointed out by a few members already the proposed pattern is very similar to `XMLHttpRequest` which has been much maligned for how hard it is to use and has now been replaced with `fetch` as a result.

Most crucially though, the fact that we intend to take focus away from the website during this linear flow suggests that complex asynchronous operations will not be possible, in as much as they will not be able to do anything that requires UI.

Designing an API that provides a mechanism for the website to update the payment request during the life-cycle of the payment places complex requirements on the deployment environment. Flexibility introduces complexity but the current proposal seems to introduce the complexity without providing any additional flexibility.

> Is the PaymentRequest proposal too high level? Should shipping address be removed from the PaymentRequest flow because it is doing too much?

and

> Should shipping address be available as a separate getShippingAddress() method?

I am in favour of moving (not removing) the ability to get a shipping address but there is already a long thread discussing this here: https://github.com/w3c/webpayments/issues/39

@bifurcation 

We can't provide websites with an API that allows them to farm data from users about what payment methods they have available.

The current design is intended to place the user agent (mediator - see the [component architecture](https://github.com/w3c/webpayments/wiki/A-Payments-Initiation-Architecture-for-the-Web)) in between the website and the user to protect the user's privacy.

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