See also: IRC log
30 November
Update on ACTION Ian 20161123: Look into a new meeting time based on who is participating in the call. Status: Not done yet.
IJ: Any updates since last week?
Rouslan: Samsung folks have
set/get manifest
... you can run those functions in service workers
... in Chrome Dev
... these are two functions in the payment app spec to register
a payment app
... there is a label and icon for the app, and a list of
payment options
... it's behind a flag
<rouslan> chrome://flags/#enable-experimental-web-platform-features
https://github.com/w3c/webpayments-payment-apps-api/issues/69
What does "icon" mean?
IJ: any insights since last week?
Rouslan: Web App manifest uses URLs for icons...I guess that's what we are going to do
https://www.w3.org/TR/appmanifest/#icons-member
scribe: Samsung is really pushing us forward on web-based payment apps
<rouslan> whenever possible, let's use the same primitives as elsewhere in specs, like webapp manifests.
http://caniuse.com/#search=manifest
rouslan: I have read the code for
web app manifest, which is fairly stable
... I've seen apps use it to change the color of the address
bar
(Seems Chrome implements it, but not widely implemented yet)
scribe: it's also used for adding
web sites to your home screen
... I think we should do what they do for icons (list)
<rouslan> +1 copy def
Proposed: Copy web app manifest definition for "icons" (and update the spec to make it a list)
<rouslan> +1
<TommyT> +1 to copy
+1
so RESOLVED.
<scribe> ACTION: Ian to update the payment app spec to copy web app manifest term for icon_s [recorded in http://www.w3.org/2016/11/23-apps-minutes.html#action01]
IJ: Any other observations from get/set work?
Rouslan: Not yet
IJ: See agenda for summary; next steps IMO will be UX challenges for Web-based payment apps
Can payment apps cancel payment flow?
https://github.com/w3c/webpayments-payment-apps-api/issues/37
https://github.com/w3c/webpayments/issues/128
IJ: Any new insights about cancelation?
tommy: Adam's comment seems
reasonable
... I think I raised this pre service worker
rouslan: Can we let the user
select a different app if one of their apps fails?
... there are two points of failure detection:
1) browser hands payment request to app; app comes back with failure....browser knows that payment app doesn't work and the browser could should the user other matching payment apps
scribe: this is how it works on
Android today when AndroidPay today
... or, e.g., if the user cancels CVC, the user can still pay
with another credit card
2) the other failure mode is the payment app succeeds, hands JSON to merchant who tries to use the data and then FAILS.
scribe: in this case, the
merchant calls instrumentResponse.complete('fail') at which
point the browser displays an error message that the
transaction failed
... in this case the only user interaction is to click "Close"
on the error message and then the merchant can create a new
payment request
... or fall back
https://w3c.github.io/webpayments-payment-apps-api/#sec-payment-app-response
<rouslan> +1 variety
IJ: Seems like at a minimum that
the spec needs to not prohibit "retry"
... whether we encourage it (or even require) is another
question (and premature to answer)
<TommyT> +1 to not prohibit "retry"
rouslan: +1 to variety
"The user agent receives a failure response from the payment app through rejection of the Promise. The user agent MUST use the rejection reason to reject the Promise that was created by PaymentRequest.show(). "
IJ: So let's create an issue about user agent behavior when payment app fails.
<scribe> ACTION: Ian to add a pointer from the spec to the issue of UA retrying other matching payment apps after cancelation or failure http://www.w3.org/2016/11/23-apps-minutes.html#action02]
Tommy: Now that we've discussed
this a bit, I think what would be useful would be for an app to
have a graceful way of saying "I give up"
... e.g., what if the app wants to cancel in a pretty way,
could we make it nicer than sending back "invalid data"
... maybe we should at least recommend some way to
cancel
<scribe> ACTION: Tommy to write a proposal for section 10.4 around issue 37 to consider (1) graceful failure in the case of cancelation and (2) mention of retry [recorded in http://www.w3.org/2016/11/23-apps-minutes.html#action03]
- WebIDL fix pending
- AHB commented on my edits and I'm trying to work through them with him
IJ: Any other topics?
... Frank, need any more information to play with payment
apps?
Frank: I will reach out to Rouslan separately.
Have a good week!