[w3c/payment-request] Custom .data validation during construction of PaymentRequest (Issue #975)

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](https://developer.apple.com/documentation/apple_pay_on_the_web/apple_pay_on_the_web_version_history).  Currently, we suggest that developers use [`ApplePaySession.supportsVersion`](https://developer.apple.com/documentation/apple_pay_on_the_web/applepaysession/1778014-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_

-- 
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-request/issues/975