See also: IRC log
<scribe> Meeting: Payment Apps Task Force
<scribe> Scribe: Ian
https://www.w3.org/2002/09/wbs/35125/TPAC2017/
175: Fix to PaymentRequestEvent.total in light of WebIDL rules
168: PaymentRequestEvent.openWindow should check origin before navigation instead of after navigation
https://w3c.github.io/payment-handler/
https://w3c.github.io/payment-handler/#windows
IJ: Should we close 169, 115, 97?
rouslan: I think that someone from Samsung is planning to reconcile the algorithms between this spec and service workers
<scribe> ACTION: Ian to reach out to @romandev to see about reconciliation of open window algorithms [recorded in http://www.w3.org/2017/06/20-apps-minutes.html#action01]
https://github.com/w3c/payment-handler/issues/169
https://github.com/w3c/payment-handler/issues/97
<rouslan> +1
RESOLUTION: Close 97 in favor of 115
rouslan: We are still behind a
flag in Canary. You can experiment with it. We have implemented
the open window algorithm.
... it's looking good...there is a chrome custom tab with a
reduced number of menu items
... some functionality was removed (e.g., can't open in regular
browser frame)
... one thing that would not be possible to PREVENT is
navigation around
... that would terminate connection to the service worker
... we don't know how to solve this issue; we don't consider it
to be a big issue.
... page can also change its own URL (through JS) which would
terminate connection to SW
... the samsung folks are implementing the permission
request
... the spec is not clear on how it should work.
... they are using other permission request examples from other
spec
... I have encouraged a PR for our spec
https://github.com/w3c/payment-handler/issues/94
(Rouslan has already cc'd @romandev)
<Zakim> AdrianHB, you wanted to mention interledger implementation work
AdrianHB: We are working on an
implementation of Payment Handler API with interledger
... ILPKit
<AdrianHB> https://github.com/interledgerjs/ilp-kit
AdrianHB: hope to have a demo by
early next week
... we are working with Canara.
IJ: How easy is it to do?
AdrianHB: The android payment app was easy (done by Shopify); we are moving on to Web based; I'll let you know.
IJ: Please bring feedback; thanks!
IJ: How is that going?
rouslan: I haven't starting
implementing it; thanks for comments so far.
... but I do think it's the correct approach.
https://github.com/w3c/payment-handler/issues/179
RESOLUTION: to change PaymentRequestEvent.total to type PaymentCurrencyAmount
<scribe> ACTION: Rouslan will do a pull request to make the type change for issue 179 [recorded in http://www.w3.org/2017/06/20-apps-minutes.html#action02]
https://github.com/w3c/payment-handler/issues/178
This API defines mechanisms to specify icons and labels for the display of instruments. Other Web technology (e.g., Web app manifest) enables user agents to fetch icons, labels, and other "higher level" information about the payment handler.
IJ: The idea of the proposal was "we don't specify it here"
rouslan: What happens if a
payment handler does NOT have a web app manifest?
... I think the answer should be left to browsers
... e.g., Chrome will always use the web app manifest
... what happens if (1) doesn't exist (2) don't specify icons
(3) icons can't be fetched.
... I think what we will do is to not show the payment handler
in the list
... this is contentious because one way to view this behavior
is that payment handler cannot predict UI behavior, which is
subpar
IJ: How do implementations handle web app manifest errors?
rouslan: We have been printing
console warning messages
... e.g., if a page does not have a fav icon and uses payment
request; we show a message that user experience will be subpar
but we do show something
... we could show console warning to developers (in case of
payment handler) and still not show payment app in the list
<Zakim> AdrianHB, you wanted to ask if a default icon is okay?
AdrianHB: Couldn't we follow
similar behavior to favicon?
... Seems extreme to me to not show payment handler if you
can't find the icon
rouslan: I guess we are already
showing origin of payment handler underneath
... so maybe if we don't find label/icon we show origin
... and we put that lower in the list of matching payment
apps
<jnormore> +1 to leaving it up to browsers to handle failure/degraded modes for this
<AdrianHB> +1 to not excluding but leave with browsers to decide how to best serve UI
https://www.w3.org/TR/appmanifest/
https://www.w3.org/TR/appmanifest/#example-manifests
===
<!-- Startup configuration -->
<link rel="manifest" href="manifest.webmanifest">
<!-- Fallback application metadata for legacy browsers -->
<meta name="application-name" content="Racer3K">
<link rel="icon" sizes="16x16 32x32 48x48" href="lo_def.ico">
<link rel="icon" sizes="512x512" href="hi_def.png">
====
<rouslan> +1
Summary of spec text:
* State that other web technologies are used for app-level info
* A statement about browser behavior in the absence of icons/labels
* Preferable for user agents to degrade the experience, and how browsers do so is up to the browser
* Browsers should not omit payment apps entirely when there is no specified app-level display info
<rouslan> +1
IJ: What about falling back to favicon in some cases?
(Rouslan: +1)
<scribe> ACTION: Rouslan to noodle on proposal in GitHub thread for issue 178 [recorded in http://www.w3.org/2017/06/20-apps-minutes.html#action03]
Ability to set default instrument for given handler.
https://github.com/w3c/payment-handler/issues/173
Two parts:
1) Is there a need for payment handlers to know when an instrument has been selected "as a default" v. "alongside a full list"?
2) User experience that combines (1) ease of selecting a default with (2) ease of accessing a full list
https://github.com/w3c/payment-handler/issues/173#issuecomment-308508202
(IJ thinks Tommy's proposal is to launch payment app, not show a submenu of instruments)
jnormore: My suggestion is to
determine defaults.
... is to let the user agent determine defaults
... I am not against defaultKey concept
... rather instrumentKey concept
<jnormore> I am against defaultKey concept*
<jnormore> not against instrumentKey
AdrianHB: What I am worried
about...as a payment handler, I like the idea of skipping
instrument selection within my app
... I want users to be able to click once to pick the
instrument and my app
... as soon as I tell the browser that one is a default, then
every time that instrument comes through, I don't know whether
the user
... was presented with all the options, or not.
... if the user does not want to use their default, they have
no way of doing so unless the browser gives them the option for
"all"
... I think it's a separate issue of "how we implement this
concept"
... every instrument has an instrumentKey
... I can nominate one as a default for the payment
handler
... when I get the payment request event, the browser tells me,
e.g., "how many were presented" or "that was the only one
presented.
rouslan: Currently in Chrome, when the merchant requests shipping address and does not provide shipping options, that indicates "I need shipping address first before I can compute total"
<rouslan> "Shipping address [SELECT]"
rouslan: so that's what we used
to present
... we found that UI to be sub-optimal...so we changed it
... the improvement is:
... we add preview of addresses the user has
<rouslan> "Shipping addresss (123 Main st... and 2 others) [SELECT]"
rouslan: we found that type of
user interface improves user engagement
... if we apply the same idea to payment handler
<rouslan> "BobPay [icon]"
rouslan: we might do something like this:
* BobPay (Visa ***4132 and 5 others)
rouslan: So one question is "what
should the default be"?
... it's not obvious for browser to determine usage since we
don't parse the response data
... so the payment app can specify a default
IJ: I am hearing that:
1) Some payment apps may WANT to provide a default service and
2) User agents don't really have "frequency" information since they may not (or do not) parse response data to know what instruments have been selected.
IJ: For shipping address, what's the UI for getting the whole list?
rouslan: you get the default OR
select to get the full list
... For Bobpay, I don't think we will display the list of
instruments, we will just launch the payment app
jnormore: If the browser doesn't have access to the data about user experience, and browser is ok to launch the app, then my point is moot
Summarizing:
1) We should give payment handlers the ability to specify a default instrument (and the handler gets the info about instrumentKey when selected as default)
<AdrianHB> If the browsers shows an option like: * BobPay (Visa ***4132 and 5 others) then they shouldn't pass an instrumentKey in the event
<jnormore> +1
<rouslan> +1
Three cases:
1) Default shown and selected
2) Default shown but not selected
3) All shown and an instrument is selected (which MIGHT be the "default")
AdrianHB: I understood rouslan's proposal to say "which label to show in the display; but it does NOT mean that instrument is selected when I pick bob pay."....it's just a hint
<rouslan> +1
IJ: How do you manage the default?
AdrianHB: +1 to leaving this to
the browsers to display, but as long as we have enough
information so that payment app is aware of what
happened.
... so "Visa 4321" is clear to mean "Pick Bob pay AND Visa
4321"...payment handler needs ability to know what happened in
the UI
jnormore: Unless the browser
provides a list of instruments or explicitly selected
instrument, it's hard to pass that to the payment
handler....but if the browser displays instruments, it can pass
the individual keys
... so one problem is browser capturing data, and allowing
payment handlers to provide a default instrument key
<alyver> Jason and I can certainly noodle on this.
<scribe> ACTION: jnormore to write up some notes on handling the three cases in Github [recorded in http://www.w3.org/2017/06/20-apps-minutes.html#action04]
11 July
<rouslan> +1
<jnormore> +1
IJ: Feel free to do work on GitHub or meet by phone if you self-organize
RESOLUTION: Next phone call 11 July
AdrianHB: I can chair a call if needed; let's play it by ear