Section 3.3 item 10.

Just a note that there are more places in the spec that speak to order than 3.3 item 10.

i would strongly caution against doing this. my reasons:

1. PR api is designed to serve merchants and users, and not allowing a merchant to provide a preference would be a disservice to them.
2. It feels like the main beneficiary of this might be, indirectly, a credit card processing network. The PR api is designed for use cases beyond just credit card processing, and it is unclear why we should use the interests of one particular use case to change the generic spec.
3. If merchants don't have the basic control of selecting the order of instruments they prefer, it would create a disincentive (however small) for them to use the PR api.
4. Not allowing specifying an order would encourage probing by merchants.

@weksler - just to be clear, the current language doesn't require user agents to respect the ordering:

The user agent may show payment methods in the order given by supportedMethods, but should prioritize the preference of the user when presenting payment methods and applications.

..."may" here per RFC 2119 meaning it is truly optional - user agents have no obligation to respect the ordering preference of merchants as it stands.

fair enough.

should we clarify the nature of the request, in that case? it was my understanding (i might have misunderstood) that the original request that prompted this issue made the assumption that the browser was mandated to respect the list provided by the merchant.

I think the original request understood that it wasn't required, but that even the explicit suggestion of it created problems.

I encourage discussion on this thread. (That is: let's not close too quickly.)

I noted another statement in the spec to look at as part of this issue: "The methodData supplied to the PaymentRequest constructor SHOULD be in the order of preference of the caller. "

@ianbjacobs, were the changes made in #518 sufficient to close this?

Assuming yes, please reopen if not.