Re: [w3c/webpayments] How can a Web Based Payment App cancel the payment flow? (#128)

@dlongley said:

> I'm not yet convinced we want those apps that also provide a Web-based UI to work that way. It may be more natural for them to interface with the user agent using JavaScript and Promises. Maintaining state may also be easier this way.

Can you elaborate?

The motivation for the HTTP POST is that there is no session yet between the browser and the app and the very first interaction contains the whole payment request.

The advantage is that the payment app can tailor it's response entirely using content-type negotiation and/or redirects.

In one instance it may possibly not even render UI. If the user has setup rules in the payment app to automatically authorize certain payments (eg: from certain merchants below certain values etc) the payment app could simply respond with a JSON-encoded payment response and the browser would never need to render any payment app UI.

In addition it supports the case where the payment app wants to redirect the request to native app. This can easily be supported by doing a redirect to a URL with a custom URL protocol like `mypaymentapp://`.

If we force the browser to first render the web-based payment app before the app even sees the content of the request then we can't support either of these uses cases without a nasty user experience of UI that may appear and then vanish or need to be loaded in the backgorund.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/128#issuecomment-215391572