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

@adrianhopebailie wrote:
>Apple can do this in their solution because the solution is only available if you're using an all Apple stack.

Indeed.  My proposals and interests are entirely devoted to giving third parties (which in this context include all banks, as well as giants like VISA and Alibaba), access to a _similar_ stack but not limited to a specific platform or application.

>The platform agnostic way to establish this channel would be for the request to contain a callback URL or similar that allows the payment app to establish a channel after it receives the request.

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

>The platform specific mechanisms are outside the scope of the W3C to define but event then it seems fraught with trouble to try and establish a channel from a native payment app to the client side code of the payee website.

Well, the core concept (establishing a bi-directional asynchronous channel between a native app and its invoking Web page), is already a part of the Chrome _desktop browser_ since years back.  I have successfully used it on Mac, Windows, and Linux _without any changes whatsoever in the Web side of the code_.

The Mozilla folks are trying to create a standard out of this but have decided to take the Chrome desktop concept "as is" which I think is a pretty bad idea for numerous reasons including the likely "NO" from the Android team.

Regarding the often mentioned security issues, I don't see (maybe I'm blinded by enthusiasm...), that adding a channel to the invoking Web page would introduce even half of the the issues that we already have by just invoking a native application from a Web page like in Android Intents.

---
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-232334282