Behavior for multiple modifiers for the same payment method is not defined

[nickjshearer]

Currently the specification defines a PaymentDetailsModifier sequence which can be used to apply modifications to the total and display items as appropriate for the currently selected payment method:

https://w3c.github.io/browser-payment-api/#dom-paymentdetailsmodifier

However, the specification does not define the user agent behavior in the case where this sequence contains multiple PaymentDetailsModifier objects for the same payment method. This needs to be defined, otherwise user agents risk implementing differing behaviors that could result in incorrect amounts being charged.

I would suggest since this is a sequence stating the first entry to match a payment method will be used as its modifier.

Alternatively, we could say supplying multiple modifiers for a single payment instrument is not allowed and throw a TypeError.

[tommythorsen]

I would vote for the last one, throwing a TypeError for the case where there are multiple modifiers for one payment method. It seems to be the simplest way avoid confusion and to get correct and consistent behavior.

[rsolomakhin]

I'm OK either way.

[ianbjacobs]

How does the spec address similar questions of "multiple instances"? In discussion about basic card filters (cf Zach's proposal [1], which is partially implemented, the expectation is set taht
the mediator will take a "first match wins" approach.

Ian

[1] https://github.com/w3c/webpayments/blob/gh-pages/proposals/zach-pmi.md

[zkoch]

I would prefer we don't throw. @domenic is it conventional to take the first match or the last match?

[domenic]

I can't find too many precedents, but I think first match wins is reasonable.

Most precedents I can find (e.g. referrer policy headers, CSS) are about "last supported value" semantics. See e.g. https://w3c.github.io/webappsec-referrer-policy/#unknown-policy-values. But that doesn't apply here; the problem is differently structured.