Payments Apps Task Force

upcoming meetings

16 Nov, 23 Nov, 30 Nov, 7 Dec, 14 Dec, 4 Jan 2017

adamR: Regrets for 16 Nov

option displays

https://www.money2020.com/sessions/part-2-one-click-buying-new-w3c-standards-for-web-payments

https://w3c.github.io/webpayments-payment-apps-api/#selectable-app-information-display

IJ: Please review.

AdamR: I think this one addresses it - "The user agent MUST display matching payment apps in an order that corresponds to the order of supported payment methods supplied by the payee, except where the user agent enables the user to override this order."

IJ: "The user agent MUST display all matching payment apps."
... that's supposed to prevent discrimination..but we may not want to be absolute (e.g., security)

AdamR: Browsers will ignore it in that case...we could say "MUST unless security"....

max: I'm not sure whether the merchant should take control of the browser
... I want to emphasize that we should allow some merchant control
... I will think about alternatives
... one question is - what is the relationship between the six bullets...are there any internal conflicts?

jnormore: I am somewhat conflicted...from merchant perspective I want total control. But from a UX perspective, and in light of conversation about detecting presence of payment methods....if detection is NOT possible, then I'd rather the browser have some flexibility
... the browser should be able to Show or Not Show based on its own ability to detect enabled payment instruments
... user experience should trump merchant preference

IJ: About the bullets

* Some are about matching payments

* Some are about recommended payment apps

https://github.com/w3c/webpayments-payment-apps-api/issues/59

https://github.com/w3c/webpayments-payment-apps-api/issues/59#issuecomment-249926853

IJ: How is Chrome on Android managing payment app order?

TommyT: I think that the current rules in there are pretty good
... I would not like to see any more hard specification that forces an implementer to let the user configure something
... I think that should be up to the implementer
... right now the text says the the user can override the merchant BY CONFIGURATION...but it would ALSO be useful to be able to present payment apps based on user behavior (e.g., most recently used app for a site)

+1

IJ: And I note that in 9.1.1. we could mention "most recently used" as well

<Zakim> rouslan, you wanted to talk about chrome's strategy for app sorting

rouslan: Chrome hasn't implemented this yet. The ordering we would like to use is a combination of frequency of usage and recent usage

<adamR> Heh. I was about to explain frecency too.

rouslan: We also plan to use as signals (but not necessarily as the rule of law) such things as the order preferred by the merchant
... which is the order in the PR API constructor

----

* Display any matching (possibly modulated by security)

* Prefer user configure (add: or behavior) over merchant

* MAY allow configuration

Ian: I will do a pull request with three changes:

1) Clarify behavior ok

2) Add security bit to first bullet

3) https://github.com/w3c/webpayments-payment-apps-api/issues/59#issuecomment-249926853

TommyT: If we like the ordering suggestion from Rouslan from chrome, that contracts bullet 5

<rouslan> Frecency

IJ: I will also add frecency to 9.1.1

<rouslan> +1

AdamR: If we mention freceny .. just as an example

<rouslan> +1 to example, not normative

filtering

https://github.com/w3c/webpayments-payment-apps-api/issues/63#issuecomment-254831097

AdamR: The only thing that works here is EITHER having an a priori means of expressing the information OR a lambda function in isolation

IJ: What does a function take? a list of PMI/filter pairs?

AdamR: Ok to send all payment method data to these functions that run in isolation?

IJ: How does the browser ensure isolation?

AdamR: Via a null origin (or unique origin)
... so same origin policy used here

IJ: Can they still make server side calls?

AdamR: No

Jason: That would satisfy the server-side performance concern

AdamR: We'd have to talk to security people about whether null origin is sufficient
... but I am confident that we can specify this (params in, boolean out)

IJ: Anybody want to take a stab?

AdamR: I will take a stab at it.

https://github.com/zkoch/zkoch.github.io/blob/master/pmi.md

http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/

IJ: My expectation is that different networks will apply for credit transfer as well

AdamR: Concerned about complexity

{

supportedMethods: ['basic-card-payment'],

data: {

supportedNetworks: ['mastercard'],

supportedTypes: ['credit']

}

===

<adamR> {

<adamR> supportedMethods: ['basic-card-payment'],

<adamR> supportedSubMethods: ['visa/debit','mastercard/credit']

<adamR> }

(Thanks!)

IJ: When might we see a proposal?

AdamR: I can probably have something by 23 Nov

web share APi

https://github.com/mgiuca/web-share/blob/master/docs/explainer.md

IJ: Should we reach out to Matt re: (e.g.,) user experience discussions?

AdamR: A colleague yesterday suggested that these look similar

<scribe> ACTION: Ian to reach out to Marcos [recorded in http://www.w3.org/2016/11/02-apps-minutes.html#action01]

Next meeting

16 Nov