Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Payment Apps] Extending invocation of payment apps with other techniques than HTTP #156

Closed
LaurentCastillo opened this issue Jul 7, 2016 · 12 comments

Comments

@LaurentCastillo
Copy link
Contributor

commented Jul 7, 2016

How would we extend the invoke of a payment app with other things than HTTP (like native messaging)? In the spec or outside (i.e. keep it a UA specific native API)? Should we give an example of such an invocation?

@cyberphone

This comment has been minimized.

Copy link

commented Jul 7, 2016

Hi @LaurentCastillo
In my interpretation Native Messaging features two steps:

  1. Invocation of the native App.
  2. Creating a channel between the invoking Web page and the native App.

It is really the latter that makes the difference with schemes using HTTP including:

  • Potentially eliminating session state-holding outside of what is usually already provided through the invoking Web page.
  • Enables (voluntarily) reuse of the the browser's communication facilities (like "fetch()") which means that external communication required by invoked Apps would be subject to the same security constraints (SOP, CORS, etc) as "real" Web applications, whereas Apps POSTing data OOB are free breaking such rules whenever they want.
  • Improved alignment with Wallets using NFC/BLE since these typically do not require Internet connectivity; they rather need a bi-directorial "channel" to the merchant. The exact nature of this channel can easily be abstracted.
  • Support for Web page and App life-cycle management. This is currently a major hassle in Android where the invoking Web page becomes "orphaned" and the App continues on its own leading to a poor user experience and occasionally to crashes.
  • Compliance with the SPA (Single Page Application) pattern.

Regarding actual implementations, there is no consensus here, and most W3C folks actually appear to be against standardization of Native Messaging.

Anyway, from what I can deduct, Apple have already created a proprietary and application specific Native Messaging solution: https://developer.apple.com/reference/applepayjs/applepaysession

var request = {
  countryCode: 'US',
  currencyCode: 'USD',
  supportedNetworks: ['visa', 'masterCard'],
  merchantCapabilities: ['supports3DS'],
  total: { label: 'Your Label', amount: '10.00' },
}
var session = new ApplePaySession(1, request);
@adrianhopebailie

This comment has been minimized.

Copy link
Collaborator

commented Jul 13, 2016

  1. Creating a channel between the invoking Web page and the native App.

@cyberphone - I agree with this statement but think there are ways to do this that you're ignoring

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

In situations where this is not guaranteed we must cross boundaries (network and process) over channels that use platform-agnostic technology like HTTP.

The approach of the PaymentRequest API is to simply define the interface for initiation.

If the payment method employed is simply returning some credentials that are used by the merchant or PSP to process the payment then we can use the response returned through the API for this.

If the payment method is any more sophisticated (like most payment methods) where the payment is actually processed by the payer's payment app then it's pretty likely that a different channel between the payment app and the payee will be established for this.

Note that here I am talking about a channel between the payment app and the payee (NOT the payee website). Trying to communicate directly with the client side code of the payee website is fraught with trouble (as you have pointed out numerous times) so it would be far more likely that the payment app would communicate directly with the payee's back-end systems.

Once the payment app completes it's processing it can return a response to the website that is no more than a signal that it is complete (it may contain some data that allows the website to reconcile the processing that the app did with it's back-end services but this is not essential).

The website can then call out to it's own back0end service to establish the state of the payment and behave accordingly.

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.

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.

@cyberphone

This comment has been minimized.

Copy link

commented Jul 13, 2016

@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.

@adrianhopebailie

This comment has been minimized.

Copy link
Collaborator

commented Jul 13, 2016

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.

@cyberphone

This comment has been minimized.

Copy link

commented Jul 13, 2016

@adrianhopebailie You should only think of native messaging as a more powerful version of Android Intents because that's all it is claimed to be.

@adrianhopebailie

This comment has been minimized.

Copy link
Collaborator

commented Jul 13, 2016

@adrianhopebailie You should only think of native messaging as a more powerful version of Android Intents because that's all it is claimed to be.

Then what does it have to do with the payment API? If native messaging was standardised within W3C then I'd consider messaging between the payee website and a native app in scope for us to standardize. Since it's not, I don't.

If we continue on the track we are on nothing will change in future if native messaging becomes a standard. Payment Apps (deployed as javascript running in the browser within a context bound to the origin of the publisher) will just have an additional standardized way to communicate with a native app. It will simply add more options, I'm not convinced it will enable anything new.

Note that the payment app javascript may run in a non-visual context so as far as the end-user is concerned the website is invoking a native app when the payment app javascript invokes the native payment app.

@cyberphone

This comment has been minimized.

Copy link

commented Jul 13, 2016

@adrianhopebailie You should only think of native messaging as a more powerful version of Android Intents because that's all it is claimed to be.

Then what does it have to do with the payment API? If native messaging was standardised within W3C then I'd consider messaging between the payee website and a native app in scope for us to standardize. Since it's not, I don't.

Right. This was directed to folks writing native apps who may not be entirely happy with the current solutions. That the current solutions are poor will be visible when using the payment API as well. I expect Google to eventually use something not yet published. The same goes for Samsung.

@ianbjacobs

This comment has been minimized.

Copy link
Contributor

commented Jul 18, 2016

I propose that we close this issue as a separate issue. I think the specification is going to propose some approach (whether "URL to get javascript" or "some other URL) and "other approaches" that are not part of the spec can be dealt with elsewhere.

@ianbjacobs ianbjacobs closed this Jul 18, 2016

@adrianhopebailie

This comment has been minimized.

Copy link
Collaborator

commented Jul 19, 2016

I propose that we close this issue as a separate issue

I don't think we can close this yet. The question asked is if there are alternate invocation modes to HTTP. The break-out at the F2F resolved to rather use Javascript so we should keep this open until the spec is updated and we are happy with the invocation model that is defined.

@ianbjacobs

This comment has been minimized.

Copy link
Contributor

commented Jul 19, 2016

Is this subsumed by #163?
#163

Ian

@adrianhopebailie

This comment has been minimized.

Copy link
Collaborator

commented Jul 19, 2016

I don't think so. This is a question about invocation methods and #163 is a concrete proposal.

@adrianhopebailie

This comment has been minimized.

Copy link
Collaborator

commented Aug 1, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.