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

We can actually separate this issue into two discussions as the API facilitates communication between both the website and the payment app and the website and the payment mediator (user agent/browser).

As such the design restrictions are different.

To illustrate, it may be quite simple for browser vendors to implement a facility whereby the website is exchanging numerous messages with the payment mediator (assumed to be built into the browser). Such a mechanism is suggested in the [paymentRequest proposal](http://wicg.github.io/paymentrequest/specs/paymentrequest.html) for getting the shipping address directly from the browser prior to selecting a payment app.

However, extending this to the payment app could be very challenging, especially in the mobile deployment scenario where the payment app will likely be an entirely separate application to the browser and inter-app communication is not well supported.

I would suggest that trying to support a "chatty" conversation pattern between the website and the payment app is not feasible via the API (due to restrictions described above for mobile).

On the other hand supporting such a pattern between the website and browser SHOULD only be done if absolutely required as it adds significant complexity to the API with regards to state management of the payment request (see #64, #36 and #41). (To date the only requirement driving this is the gathering of the shipping address as discussed in #39).

An alternative mechanism for payment apps to communicate with the website during the processing of a payment request is discussed in #76. This mechanism has the benefit of having few standardization requirements (only a standard for sharing a callback URL in the payment request is required). It also offers all of the pros of **Option 2** above with none of the cons.

Even if it is not standardized this method is likely to become a de-facto standard as payment app publishers and merchants seek out a mechanism to support use cases like dynamically updated offers (payment requests) based on the user indicating they are loyalty program members, have vouchers/coupons, or wish to make a multi-tender payment.

This suggests that there is very little motivating for a complex conversation pattern in the API.
i.e. We should stick to a simple request/response with no events.

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