Custom .data validation during construction of PaymentRequest

WebKit is interested in adding something along these lines.

For Apple Pay specifically, we require that a unsigned long version is provided as part of the object data in PaymentMethodData that corresponds to the desired supported Apple Pay version. Currently, we suggest that developers use ApplePaySession.supportsVersion to check if the desired feature (more specifically the related first version to include that feature) is supported before attempting to do anything with payments (including showing UI). We'd love for there to be a standardized approach for this :)

Along these lines, would hasEnrolledInstrument just result in false or reject with an explanatory error if the value provided for object data in PaymentMethodData (or a PaymentDetailsModifier) has issues? As an example, if a developer specified a total with a negative value in its amount and then called hasEnrolledInstrument, what would happen? What about if, using the Apple Pay example above, a developer specified version: 999? I ask because it would be nice to have some way of distinguishing between the data provided being invalid (e.g. the Promise is rejected with something like "total cannot be negative") and the data provided being unsupported (e.g. the Promise resolves with false).

Originally posted by @dcrousso in https://github.com/w3c/payment-request/issues/931#issuecomment-966549619

w3c / payment-request

Custom .data validation during construction of PaymentRequest #975