Re: [webpayments] What is the appropriate conversational pattern for the API? (#55)

The purpose of the issue is to tease out the design constraints of the various deployment scenarios for the browser API, or as you put it:

> whether it can be practically implemented.

I think it's fair to say we have established one clear constraint: that a "chatty" conversational pattern between the website and payment app is not possible with the architecture that is currently envisioned on mobile devices (i.e. a payment app is a stand-alone app separate from the browser).

What this implies is that once we are ready to submit a payment request to the payment app we must have gathered all of the data required for the payment app to process the request as the payment app can't make requests back to the website for more data.

The only way this could be achieved is through an out of band mechanism as described in #76 which the majority of the group seem to feel does not need to be standardized yet.

On the other hand, as your proposal demonstrates, a website and the browser can easily exchange numerous messages (prior to passing control to the payment app) but the second design constraint that the issue addresses is whether this is practical given that once the browser has started processing the initial API call it will have taken the focus away from the website.

Since the website has lost focus any callback to the website (whether via events, resolving promises or any other mechanism) freezes the UI in a "waiting" state until the website responds or the call times out.

I don't believe that these calls can be made asynchronously as the use cases suggest user interface updates will be required once the browser receives a response.

Therefore my assertion is that there are two design constraints we must consider:

1. It will be impossible to implement this API in all deployment scenarios (esp mobile) if the API requires numerous messages to be passed back and forth between the __website__ and the __payment app__ therefor the API should assume that a single request can be passed to the payment app and it will receive a single response.
1. It is undesirable to lock up the user interface while the browser waits for the website to respond to a callback or event (eg: shipping option selection or shipping address change) therefor the API should use a pattern for making these requests that allows the browser to intelligently manage the flow and where possible avoid website callbacks. 

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