Re: [w3c/webpayments] [Payment Apps] Extending invocation of payment apps with other techniques than HTTP (#156)

> Yes, this represents one way of achieving this goal. It has (as described) certain drawbacks.

The reason we took this approach is based on the assumption that we can't always guarantee that it will be possible to establish a bi-directional asynchronous channel between the payment app and its invoking Web page.

You are making assumptions about the deployment context that we chose to not make. You assume that the browser can continue to act as a reliable bi-directional proxy between the app and the website and I'm not sure we can always assume this.

If we come to the conclusion that all payment apps are deployed as Javascript that runs in the browser (the current proposal - not yet documented) then I think we are in a better situation than the one you describe anyway.

After invocation of the payment app script we have two contexts running in the browser at two different origins (the merchant and the payment app publisher) and I'm pretty sure nothing prevents these from using postMessage to establish a channel between them.

Now, if there is a way for a native app to be invoked and communicated with it can be done from the origin of that apps publisher (which seems like something you'd want) as opposed to trying to handle a channel between xyzmerchant.com and abcapppublisher.com's native app.



---
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/156#issuecomment-232338220