Re: [w3c/payment-handler] Edits regarding ordering based on 7 Dec WG teleconf (#242)

@ianbjacobs wrote:
> I believe the specification has always been silent on payment instrument ordering within a payment application. 

Yes agreed, but I'm not talking about *inside* a payment application. I'm talking about when the instrument is displayed to the user. See the diagram in Section 2.2:

https://www.w3.org/TR/payment-handler/#structure-of-a-web-payment-app

Payment Instruments are registered with the Payment Handler and exposed via the `instruments` attribute. A browser will introspect into the Service Worker and pull `instruments` from it, possibly changing the order to prefer their organization's payment instruments over the competition. Due to the ability to introspect, desire to reduce clicks, and order payment instruments on the screen... Payment Instrument ordering can and will be done outside of the PaymentApp as a browser optimization, right?

I get the argument that this text may be better placed in the Payment Request API (I don't care where it goes, as long as it goes somewhere). The approach taken in this spec could easily be mirrored in Payment Request.

> Payment Request API does not define a mechanism for merchants to express preferences to the user agent. Therefore, I do not think we should mention merchant preferences in Payment Handler API.

There are at least 3 ways that I can envision Payment Request API will evolve based on pressure from merchants:

1. The ordering of `methodData` may be used by browsers as a signal for merchant preference (this is probably already how it works in most browsers).
2. Features may be added to `data` that are hints to browsers for merchant preferences.
3. A new payment method may be created that enables merchants to express discounts when certain payment methods are used, which are then used by browsers to sort lowest price first.

I find it highly unlikely that at least one of these won't happen if the API is successful and therefore it is worth mentioning in the specification regarding the expectations that the group has discussed. Again, maybe the better place to put this text is in Payment Request, and I'm fine with that. The reason the discussion is happening here is because there is text about display ordering in this specification and some of us in the WG believe that pointing these things out to implementers or other readers of the specification is important.

> Merchants have no way to express preferences through Payment Request API. 

I've just pointed out how this will probably not true now, and even if it is true now, will not hold true over time, possibly even by the time the spec hits REC. Do we know what each browser implementation does with the array of `methodData`? I expect most process it in order... I doubt it's randomized.

> It is always the case that defaults are last for any similar algorithm. 

When expressing an expected order of operations, it helps to be exhaustive so you don't make the reader guess if there are items that were not included because they were obvious to the author.

> It would not make sense for a user agent to override a manual configuration with an automatic configuration unless there were some need to do so (e.g., security) in which case the user agent will do it anyway. 

That assumes that the user agent provides a mechanism to set an automatic configuration for ordering of instruments, or prefers their instruments over usage. Again, I don't think anyone in the group believes that the order should be 1) user agent preferred instruments, 2) usage based instruments, 3) defaults. The group has discussed this. Let's be explicit about the expected order of constituencies. Requesting this is not new territory for W3C... we already have a W3C Priority of Constituencies:

https://www.w3.org/TR/html-design-principles/#priority-of-constituencies

We should have an equivalent for the Payments work.

> Therefore, without the "merchant preferences" part the remaining algorithm the rest is essentially "by definition" and would not add materially to the specification.

Except that then we don't say anything and assume the reader has gone through the same thought process that we have (which they most likely will not have done) and therefore they don't glean the insight that we'd like them to glean by reading the text.

> I don't mind changing this sentence ..
> "User experience details are left to implementers."
> to:
> "User experience details (such as optimizations based on usage patterns) are left to implementers."

I'll try to reframe the above in a concrete set of changes to the text you have proposed in your PR (which does not address my, and possibly others, concerns):

_When ordering Payment Handlers and Payment Instruments, the user agent is expected to honor user preferences over other preferences. User agents are expected to permit manual configuration options, such as as setting a preferred Payment Handler display order for a site, or for all sites. When determining display preference priorities, implementers are urged to consider user preferences, then usage patterns, then merchant preferences, and finally user agent defaults._

_User experience details are left to implementers._


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-handler/pull/242#issuecomment-351599849