Re: [w3c/browser-payment-api] editorial: clarify that payment handler data is converted (#536)

@marcoscaceres and @domenic this was discussed at some length on a WG call a few weeks ago and has been a niggling issue since pretty much the first payment method spec was written.

My understanding from @rsolomakhin and @zkoch was that the data is treated as an opaque object and no validation is done against the IDL in the payment method spec.

The browser passes the opaque data onto the payment handler which then parses it and uses it. If it is invalid then the response from the handler will indicate this.

The `basic-card` payment method is "special" because the handler is internal to the browser but the implementation of how the data is validated shouldn't be exposed in the Payment Request spec.

Before you say: "But we need to look at the filters like `supportedTypes` before the data is passed to the handler". I know.

In an ideal world each `PaymentMethodData` would have:
1. A set of identifiers it applies to
2. A blob of opaque data that the browser ignores and simply passes to the handler
3. A set of filters used to filter handlers based on their capabilities

The proposal to add a new member `filters` was rejected on the basis that Chrome have already deployed this and moving `supportedTypes` from `data` to `filters` is too disruptive.

Another way to solve this is that we are revisiting the idea of handlers defining a function which is presented with the opaque `data` and can respond `true`/`false` if they will be able to handle the payment.

-- 
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/browser-payment-api/pull/536#issuecomment-303963184