See also: IRC log
16 Nov, 23 Nov, 30 Nov, 7 Dec, 14 Dec, 4 Jan 2017
adamR: Regrets for 16 Nov
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
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
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]
16 Nov