See also: IRC log
<scribe> Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Sep/0001.html
https://w3c.github.io/payment-handler/
Topic PR 208
https://github.com/w3c/payment-handler/pull/208/
https://github.com/w3c/payment-handler/pull/208/files
IJ: Should we merge this clarification?
rouslan: I have started to write
some tests for payment handler
... first tests are that IDL is implemented in the browser
https://w3c-test.org/payment-handler/ is 404....
rouslan: I would not block this PR on testing
+1 to merging this clarification
<alyver> +1
IJ: First thanks! How does it feel to write tests?
rouslan: Requires some ramp up to
learn how the harness works.
... engineers should be able to get up to speed and be
productive in a matter of a week
https://github.com/w3c/testing-how-to/blob/gh-pages/README.md#web-spec-testing-how-to
https://github.com/w3c/payment-request/blob/gh-pages/test-plan.md#test-plan--payment-request-api
IJ: Could you have a look at the last URL to add to it?
rouslan: My ramp up was longer
because I started a new test suite
... the rules for the best of class test suite have changed
slightly, so there are no concrete examples right now
... (1) https only (2) works in service worker (3) works in
regular window context
... I had to experiment to set it up correctly
IJ: Should we (some of us interested) use some of this slot for testing work moving forward?
(Not hearing uptake for that)
IJ: Any implementation experience?
rouslan: We've implemented this;
working fine. You can check it out in Canary implementation of
Chrome for Android
... the API is there but the UI will improve
https://github.com/w3c/payment-handler/pull/206
https://github.com/w3c/payment-handler/pull/206/files
IJ: Should this be attached to a different interface?
rouslan: Works fine on payment manager
Proposal: to merge this attribute (pull request 206)
<rouslan> +1
<alyver> +1
Resolved to merge PR 206
https://w3c.github.io/payment-handler/#instrument-display-ordering
https://github.com/w3c/payment-handler/issues/116#issuecomment-317890522
(now 5.1)
<Ken> • The user agent MUST favor user-side order preferences (based on user configuration) [AXP suggests DELETE…or behavior) over any other order preferences]. • AXP suggests DELETE The user agent MUST make available matching payment handlers that correspond to the supported payment methods provided by the payee. However, the user agent is NOT REQUIRED to make available payment handlers that pose security issues and SHOULD inform the user when a payment handler is[CUT]
IJ: I have another proposal - delete all the bullets
https://w3c.github.io/payment-handler/#ordering-of-payment-handlers
Bullet 1 today is: The user agent MUST favor user-side order preferences (based on user configuration or behavior) over payee-side order preferences.
Bullet 2 today is: The user agent MUST display matching payment handlers in an order that corresponds to the order of supported payment methods provided by the payee, except where overridden by user-side order preferences.
Bullet 3 today: The user agent SHOULD allow the user to configure the display of matching payment handlers to control the ordering and define preselected defaults.
Ken: We should favor user
configurations
... We support filtering but not preference expression other
than by the user
... Also want to require UA's to allow user config
<Ken> • The user agent [AXP suggests ‘MUST’ FOR ‘SHOULD’] allow the user to configure the display of matching payment handlers to control the ordering and define preselected defaults.
====
alyver: Regarding dropping "user
behavior"...I am ok with that.
... I am more curious about dropping the entire second
bullet
IJ: I am in favor of removing
bullets and letting browsers do the right thing
... I am reluctant to over constrain....there are security
issues, etc.
Ken: I think the user needs to be able to configure what payment handlers they will be using.
IJ proposed: "The user agent MUST favor user-side order preferences over any other order preferences"
IJ: I don't think we can specify "must allow user configuration"
alyver: Should we drop the bullet point on security issues...?
rouslan: I expect we will not
allow bad payment apps
... we could do through spec language or some other way
IJ: In any case we can talk about security outside section 5.1
Propose to move this text to the security considerations section: "the user agent is NOT REQUIRED to make available payment handlers that pose security issues and SHOULD inform the user when a payment handler is unavailable for use."
<rouslan> +1
(IJ: e.g., 9.4 payment app authenticity)
IJ Proposal:
- replace bullets of 5.1 with "The user agent MUST favor user-side order preferences over any other order preferences"
- Move this sentence to 9.4: "the user agent is NOT REQUIRED to make available payment handlers that pose security issues and SHOULD inform the user when a payment handler is unavailable for use."
IJ: Let's come back to this issue next week having reflected on these proposals.
Ken: Suppose a payment handler wanted to be displayed first, how would that work ?
IJ: Today third party software providers don't have a means to affect how they are displayed in my browsing environment
IJ Proposal:
- replace bullets of 5.1 with "The user agent MUST favor user-side order preferences over any other order preferences"
- Move this sentence to 9.4: "the user agent is NOT REQUIRED to make available payment handlers that pose security issues and SHOULD inform the user when a payment handler is unavailable for use."
(IJ may do a pull. request on the second bullet)
19 Sep
<alyver> +1