Relation between merchant order of payment methods and payment app order of instruments

[ianbjacobs]

See discussion from 23 March FTF meeting:
http://www.w3.org/2017/03/23-wpwg-minutes.html

How does merchant payment method order interact with registration order from the payment app? There was some agreement at the meeting we need an algorithm to answer this.

[ianbjacobs]

Some notes on this topic:

• Related PR API discussion about ordering of payment methods
  Consider removing merchant preference language payment-request#481

• If PR API does not define payment method order, then we can probably close this issue but we need to edit 6.1 in the spec (on Ordering of Payment Handlers).

• There is currently no discussion in Payment Handler about ordering of wallet/instrument information based on registration data.

[kmealey]

My suggested revisions to the 6.1 sections for consideration...

• The user agent must favor user-side order preferences (based on user configuration or behavior) over any other order preferences.
• The user agent must display matching payment handlers that corresponds to the supported payment methods provided by the payee by user-side order preferences.
• The user agent should allow the user to configure the display of matching payment handlers to control the ordering and define preselected defaults.

[adrianhopebailie]

Given https://github.com/w3c/browser-payment-api/pull/518/files I suggest we come to a close on this.

I have spoken with a number of stakeholders lately who are very concerned about the payee having no control over the ordering of payment handlers presented to the user.

This is especially relevant in the mobile context where an additional interaction is often required to even display the additional options.

However, rather than re-hash the debate I suggest we adopt @kmealey 's proposal with a small amendment to say nothing re-ordering in bullet 2.

• The user agent MUST favor user-side order preferences (based on user configuration or behavior) over any other order preferences.
• The user agent MUST display matching payment handlers that correspond to the supported payment methods provided by the payee.
• The user agent SHOULD allow the user to configure the display of matching payment handlers to control the ordering and define preselected defaults.

[ianbjacobs]

Hi @adrianhopebailie,

I am ok with the first bullet's "over any other order preferences." which is broader than
the original language ("over payee-side order preferences") and I think is consistent with the
spirit of discussions and feedback.

However, the rewrite of the second bullet muddies the waters. Here's a counter-proposal:

"After that, the user agent MUST display matching payment handlers that correspond to the supported payment methods provided by the payee."

Ian

[adrianhopebailie]

@ianbjacobs I prefer yours but I don't think it is consistent with the changes we made to Payment Request

[mattsaxon]

I think the intention of this wording is to state the behavior of the user agent for all payment apps (e.g. native too), not just (Web) Payment Handlers, so this text should be in Payment Request (in addition)

[ianbjacobs]

Noting that we discussed at the 25 July payment apps call:
https://www.w3.org/2017/07/25-apps-minutes#item05

(I will be proposing some language based on discussion.)

[ianbjacobs]

PROPOSED:

• The user agent MUST favor user-side order preferences (based on user configuration or behavior) over any other order preferences.
• 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 unavailable for use.

Notes:

• In the second bullet, changed "display" to "make available." This bullet is about access, not
  simultaneous display. We have been discussing user experiences such as "show a default and a way to access the full list of instruments"; that would be supported by this bullet.
• I have added a sentence to take into account security as a reason not to make available a matching app.
• In this proposal, I have dropped this bullet: "The user agent SHOULD allow the user to configure the display of matching payment handlers to control the ordering and define preselected defaults.". The functionality of "defaults" is being discussed in a separate issue.

Ian

[rsolomakhin]

👍

[kmealey]

PROPOSED:

5.1 Ordering of Payment Handlers
(Sentence one, modified) The user agent MUST favor user-side order preferences over any other order preferences.

(Sentence two, delete in its entirety) 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.

(Sentence three, modified) The user agent MUST allow the user to configure the display order of payment handlers. This display order applies for all calls to Payment Request API.

Thank you for your consideration of this input

[ianbjacobs]

Thanks, Ken!

Ian

[ianbjacobs]

We can close this issue with the merger of PR #242.
Ian