Payment Apps Task Force

<scribe> Agenda: https://lists.w3.org/Archives/Public/public-payments-wg/2017Sep/0001.html

Recent changes

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

Testing payment handler

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)

Issue 173 - user hint

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

Issue 116: Relation between merchant order of payment methods and payment app order of instruments.

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."

Next meeting

(IJ may do a pull. request on the second bullet)

19 Sep

<alyver> +1