Payment Apps Task Force

Next meeting: 8 August

=> https://lists.w3.org/Archives/Public/public-payments-wg/2017Jul/0049.html

Removing wallets proposal

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]

Default Instrument

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

Pull request 170 (re: canMakePaymentEvent and abortPaymentEvent). Are we ready to merge?

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

Issue 116

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