See also: IRC log
=> https://lists.w3.org/Archives/Public/public-payments-wg/2017Jul/0049.html
IJ: I reviewed, Marcos reviewed
Rouslan: I have not reviewed
IJ: Not clear to me that we should pursue this if there are no implementations of containers
rouslan: Here's how we are
rendering service workers todya.
... a payment app can have multiple service workers. We would
show each one.
... so technically we would support multiple containers
(through multiple service workers)
... technically our API supports these containers
inherently.
IJ: In the case of multiple
service workers, how do you handle events?
... how does it work? Does the spec need to say anything?
rouslan: I think that is out of
scope for the spec.
... the browser has a list of service workers and sends the
events to each, collects the responses, and shows UI.
IJ: In the case of multiple service workers, does only one get the event on user selection?
Rouslan: Yes.
... there may be some internal code that needs to figure things
out based on the data received
IJ: Should we add a Note like "Some payment app providers may wish to offer users multiple "wallets" for the same domain. This specification does not define features to do so, but developers may use subweb origins or multiple service worker scopes."
<rouslan> +1
IJ: Anyone else want to review the PR?>
[Silence]
Proposed: To merge AHB's pull request ( https://github.com/w3c/payment-handler/pull/188) then add a sentence about achieving wallets through other means.
<rouslan> +1
SO RESOLVED
<scribe> ACTION: Ian to write a PR to add a sentence about wallets [recorded in http://www.w3.org/2017/07/25-apps-minutes.html#action01]
Adrian wrote a proposal:
https://github.com/w3c/payment-handler/issues/173#issuecomment-316978011
Adrian and I discussed, then I fleshed out the user scenarios and how they work
with the proposal:
https://github.com/w3c/payment-handler/issues/173#issuecomment-317497373
This also relates to issue 178, and where information comes from for icons and labels:
https://github.com/w3c/payment-handler/issues/178
IJ: Did anyone review AHB's proposal?
https://github.com/w3c/payment-handler/issues/173#issuecomment-317497373
IJ: I think AHB wanted to ensure the payment app has context and selected instruments.
rouslan: I have some concerns about sending displayed instruments to the payment app
https://github.com/w3c/payment-handler/issues/173#issuecomment-316978011
https://github.com/w3c/payment-handler/issues/173#issuecomment-317497373
IJ: AHB's proposal also talks about defaults, and needs more work on interaction between browser and payment app defaults
rouslan: I think the proposal needs more work; I don't think passing displayed instruments will be valuable. I suggest we take to github
IJ: +1 that we need more input on github
https://github.com/w3c/payment-handler/pull/170
IJ: Are we ready to merge this?
Rouslan: I am satisfied with the
proposal except it needs to be tidied and links fixed.
... other than that, I think the patch looks good. We have
started implementation and have defined the 2 events
https://github.com/w3c/payment-handler/blob/gh-pages/tidyconfig.txt
IJ: In a directory with index.html you would do this: tidy -config tidyconfig.txt -o index.html index.html
(I am using tidy 5.4.0)
rouslan: I will work on this on Friday
IJ: Once merged I think that lets us close issues 157, 117
https://github.com/w3c/payment-handler/issues/157
https://github.com/w3c/payment-handler/issues/117
IJ: Is the "turning off" feature implemented as well?
rouslan: Yes, for android payment
apps.
... we plan to implement for web apps
IJ: You have a picture of the user experience?
rouslan: In Chrome's incognito
(private browsing) mode, the payment events don't go to the
apps, they immediately return TRUE
... once user confirms payment, before going into the payment
app, we show a standard chrome dialog that says "by invoking
this payment app you are exiting private browsing mode, please
confirm this action"
... this is the same way we handle launch of, say, youtube app,
when invoked from incognito mode
https://github.com/w3c/payment-handler/issues/116#issuecomment-292183832
https://github.com/w3c/payment-handler/issues/116#issuecomment-316971765
( The user agent MUST favor user-side order preferences (based on user configuration or behavior) over any other order preferences.
Second proposal: "The user agent MUST display matching payment handlers that correspond to the supported payment methods provided by the payee."
IJ: "display" is too strong
... previously we said something like "make available"
<rouslan> +1
IJ: counter proposal is: "The
user agent MUST make available to the user matching payment
handlers that correspond to the supported payment methods
provided by the payee.
... What can the user do today?
rouslan: Currently we respect
user preferences and the user preferences are based on
behavior
... we sort payment apps by how recently the payment app was
used or installed
... and how many times the payment app has been used. We
combine the two bits of information ("frecency")
... beyond that, we don't really take merchant-preferred
ordering into account, except when it comes to basic card
... when the user needs to add a new card (through our UI) we
show a list of icons of networks, and that list we show in the
order specified by the merchant since we have no other signals
of user preferences
... we also take into account the "quality" of the payment app,
e.g., if the payment app does not have an icon, we sort it
lower
... in the case of service-worker based payment apps, we must
display the origin of the service worker (the only reliable way
to identify where web-based payment apps come from)
... we have made a decision that if a payment app does not have
a label or icon, we will (1) sort it lower and (2) display the
app's origin
... in case of Android apps, they don't inherently have an
origin
... nobody on mobile devices knows package names of apps
... indeed, if you look at package names of widely used payment
apps, you would see they are not well-suited for display to the
user
... what we do for those apps, we allow "no icon", but if there
is also "no label" then we don't show the app at all. That
might contradict the three bullets
https://w3c.github.io/payment-handler/#instrument-display-ordering
IJ: I thought we had language
saying that security issues could affect the display
... I don't see it and think it needs to be added back.
<rouslan> +1
IJ: that the user agent has some
flexibility to take into account security.
... but should inform the user
... should the security check mostly happen "at registration"
or could it be relevant at any time?
rouslan: I wouldn't overly restrict since we don't know
Summary:
- Adopt mostly Ken's proposal
- But change "display" to "make available"
- Add back security mention.
IJ: I will add proposal to the GitHub list
Ken: Please add to next agenda
IJ: That's in 2 weeks
<Zakim> MattS, you wanted to ask about how this wording gets
MattS: My question is not related
to the wording but to the placement of the wording in the
spec.
... at the moment this is going into the payment handler
spec...but it doesn't tell the user agent what to do around
payment methods
... my understanding about the chrome implementation is that
they have a situation where the Android Pay application appears
at the top of the list
... that's not strictly speaking a "payment handler"
... I think the intention of our wording is that it be at the
level of payment request API (not payment handler)
IJ: Please add that to the issue => https://github.com/w3c/payment-handler/issues/116
rouslan: I agree with Matt's
observation
... I note that Android pay is "before" browser-stored cards
(for security reasons)
mattS: Is that true, even if user always chooses card?
rouslan: Yes, good point. We have several categories of sorting preference. We essentially prioritize them. We prioritize security more than repeated usage of a repeated payment method
MattS: I can see a rationale for that between card payments ... but when we have more payment methods trying to distinguish themselves on security, I think we won't necessarily have the same obvious situation
<rouslan> frecency
<rouslan> https://en.wikipedia.org/wiki/Frecency
<rouslan> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/Places/Frecency_algorithm