Re: [w3c/browser-payment-api] What is the extensibility mechanism for the payment request and response messages? (#146)

@adrianhopebailie,

> I would expect the browser to throw an error, no?

I don't think it does. I think it accepts the data, however, it makes a copy of it using the Web IDL defined fields, which will cause `otherThing` to be dropped.

> If so, how do we define a fully extensible message in WebIDL when its not possible to allow for extra top-level members?

You could use interfaces instead of dictionaries, but that seems like a hack to me. I think Web IDL may need an extension to cover this in a clean way. If the browser API needs Web IDL here, let's not muck up the rest of the ecosystem system because it has this bad restriction. When we have to use Web IDL, fine, but let's make sure we limit the damage.

Here's what we can do:

```js
var paymentRequestMessage = {
  acceptablePaymentMethods: [...],
  otherThing: ...
};

var pr = new PaymentRequest(
  paymentRequestMessage.acceptablePaymentMethods,
  {items: ...}, // user-agent only "details"
  {...}, // user-agent only "options"
  paymentRequestMessage);
```

This way you construct the payment request message according to the messages spec, then you feed the bits that the browser API needs broken out per Web IDL into its `PaymentRequest` constructor, and then pass the whole message into the `data` parameter (which should just become the main message parameter). This seems like it would deal with the Web IDL issue and allow the API to consume the same messages that other APIs would consume -- and pass them straight through to the Payment App.

---
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/issues/146#issuecomment-212507136