Payment Apps Task Force

14 Dec 2016


See also: IRC log


Rouslan, Ian, AdamR, Andre, Max
Conor, Frank


Review Adam's lambda proposal



<adamR> https://adamroach.github.io/webpayments-payment-apps-api/


AdamR: If canHandle is absent then you are expected to handle all payment methods declared in the manifest
... if present then expected to take in method data and details, and to iterate over them and return an object
... the object has keys of options it can handle
... the values are modifiers to the option (and -1 if no modifier)
... a bit strange if "-1" is a common response (which I expect it will be)
... a description for canHandle is somewhat informal (in 7.3
... in section 8 it will be more formal.
... we also probably want an extension point in PR API on determining what is an accepted method
... the way that we do that will be based on this registered function
... I think in PR API we need a clean extension point "Here is where you run the steps of payment apps"

rouslan: I noticed the callback function returns an object instead of interface/list of interfaces/dictionary/list of dictionaries

adamR: This is the best I could figure out based on your proposal.
... with a dictionary you need to define the keys in the spec
... if you think it should be a list we can spec it out that way as well

rouslan: we could change the proposed syntax to return a sequence of dictionaries
... where each dictionary has two keys

AdamR: One key would be an id, the other would be an index

Rouslan: Yes
... This also lets us add another value

AdamR: +1

IJ: You could also replace -1 with nothing, so that makes the common case easier

<adamR> [ { “id”: “ABC” }, { “id”: “DEF”, “modifier”: “2” } ]

AdamR: +1

IJ: What about the more formal definition?

AdamR: There are 16 baroque steps not worth reviewing here...but I want to highlight step 10


scribe: apparently this is relatively easy to implement
... people are doing something like this (step 10) with “pac” files
... we may want some W3C-defined terms to define this "almost null" operating environment...but I would prefer to point to existing specs

IJ: Let's review offline...what should we pay close attention to?

AdamR: Focus on 7.3 (which will become sequence of dictionaries) and 8
... I'd like people to review before we merge

IJ: any links to the issue?

AdamR: There was a link that's still there

IJ: Proposed is 2 thumbs up means we can merge

(Ian will look at the IPR issue in github)

Issue 73: Need to specify behavior for Clients.openWindow #73


Rouslan: Want to be able to open a window in a browser to authorize a payment
... so when the browser invokes the service worker with the payment request event, at this point the app will want to call clients.openWindow to show a window to the user
... the issue is that we need to make sure that this function call does not fail.
... it's not clear whether the payment request is a user gesture.
... to avoid inconsistencies in implementations we should specify in web payment app api that payment request handler in the service worker should be able to use clients.openWindow

AdamR: Yes, I think that's the intention
... we did say previously that payment request show() should require some user interaction

rouslan; That's not specified explicitly. In Chrome, show() does not require user action; but user action is required to approve payments

scribe: BorisZ raised the question about ambiguity
... one thing that I noticed that's not specified is that clients.openWindow needs to be supported

AdamR: My strong preference would be to require user gesture requirement on invoking PR API

<scribe> ACTION: AdamR to raise an issue on PR API [recorded in http://www.w3.org/2016/12/14-apps-minutes.html#action01]

alyver: Two things
... first agree that user action should be required on invocation of PR API
... the button has to be clicked in order to show the payment sheet
... I have a question on clients.openWeb....is that a separate application window? Is this just desktop?

AdamR: The notion is that it will be implementation dependent.
... in Firefox I expect that we will have a slide-down sheet that is used to select the payment app itself (and pick billing address, etc.)
... and then as soon as the user submits that, we'll replace the contents of that space with something like a spinner
... if the payment app calls openWindow, the construct will become the window.
... but we should not constrain how other UAs do this

<rouslan> +1


IJ: How much do we need to specify here? Where are security aspects covered?

AdamR: I think security aspects we care about handled by service workers


"Payment Apps that require user input can open a payment window using the clients.openWindow() method defined in [SERVICE-WORKERS]. "

Proposed change to something like:

"User agents MUST support clients.openWindow() method defined in [SERVICE-WORKERS] so that payment apps that require user input can open a window."

"User agents MUST support clients.openWindow() method defined in [SERVICE-WORKERS] so that payment apps that require user input can open a window to collect input."

AdamR: +1

IJ: what is the relationship of the rest of the first para of 10.3 to this new requirement?
... I think we should put the selection bits in 9, and leave the display bits in 10, so the first para of 10.3 might be shrunk


1) Browsers must allow payment apps to invoke clients.OpenWindow()

<adamR> “Because the user must interact with the browser to trigger a payment request, the user agent MUST treat a paymentrequest event as user interaction for the purposes of determining whether the service worker is allowed to open a window.“

AdamR: In service worker spec, it says "you must not open a window unless there's been an associated user interaction event"
... Originally the expectation was that this would be at "selection of the payment app"
... but we also want to optimize in some cases (no payment app selection) in which case the user interaction event has to go upstream to clicking the buy button.
... currently PR API does not have a user interaction requirement (so we'll address that in a WPWG issue)
... the use case I had in mind here was, e.g., micropayments

rouslan: remember about user gestures that the way they are implemented, once they start there is a 200ms window, and there's an assumption of invocation by user
... if the browser shows a UI to the user to review shopping cart before invoking payment app, then invoking the payment app will not be the user interaction
... what AdamR writes above works.

alyver: Rouslan said what I wanted to say...distinguish 2 user interactions (1) open payment request (2) open the payment app selected by the user
... the second sentence is ambiguous; needs to specify the second interaction

<Zakim> Ian, you wanted to talk about payment app opening window v. payment app display

IJ: so clients.openWindow is not just for gathering user data; it's also for displaying yourself (to the extent you need to)

let's write scenarios:

* payment app needs no display, e.g., after first authentication within the same session

* payment app never needs display; just returns data

IJ: Can browser suppress display?

AdamR: Should be the payment app that does that on config

* payment app always has some user interaction

IJ: notes:

- service worker requires user interaction

- in some cases user will interact directly with payment app in a window invoked by the payment app

- but in some configurations (to streamline payments) the user may not have explicit user interact, and for the purposes of service workers requirement this specification considers invocation of payment request API to be the user interaction

IJ: this last bit feels like a note for readers

<Zakim> rouslan, you wanted to suggest Boris or Dominic to craft the exact language

<scribe> ACTION: Ian to take a stab at rewriting the first paragraph of 10.3 [recorded in http://www.w3.org/2016/12/14-apps-minutes.html#action02]

(Question of whether "invocation of PR API" requires user interaction)

<Zakim> alyver, you wanted to give an example of where launching payment app with only the PR user interaction is necessary

alyver: One scenario where you might rely only on PR API invocation ... if a merchant specifies 2 payment methods and the user only has one payment app....shoudl that be launched automatically?

IJ: Yes!

(We have explicitly suggested that.)


IJ: Is user configuration a user action?
... I will leave in a note on our wonderings about what constitute user gesture when we want automatic behavior


Adam: I think I want to drop my action on PR API


* People are going to review AdamR's lambda proposal

* Ian is going to look at 10.3 (Payment App Display) intro text with use cases, a requirement on UAs, and some notes on user gestures

Next call

4 Jan 2017 at 9am ET

Summary of Action Items

[NEW] ACTION: Ian to take a stab at rewriting the first paragraph of 10.3 [recorded in http://www.w3.org/2016/12/14-apps-minutes.html#action02]

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2016/12/14 17:18:50 $