Re: [w3c/payment-method-basic-card] WIP: Last wins (#71)

@danyao, @rsolomakhin... been thinking a lot about @danyao's comment about treating missing as meaning "all networks". After spec'ing this out and thinking of possible test cases, I think what @danyao was suggesting makes a lot of sense. 

Consider the following cases. The first will be quite common, and I think browsers already support this:

```JS
// Semantically, these are all the same:  
[{ paymentMethod: "basic-card" }]
[{ paymentMethod: "basic-card", data: {} }]
[{ paymentMethod: "basic-card", data: { supportedNetworks: [] }}]
```

So to get that to mean "all the networks" we need to give `supportedNetworks` a default value` = []` in the IDL. 

Consider in particular the second case (`data: {}`)... passing that today would mean "I don't support any cards at all", which doesn't make sense for a "basic-card" request, right? Why say, "I support basic card... but I don't support any networks, lol."   

Additionally, for the case where a payment request is constructed with `[{ paymentMethod: "basic-card"}]`, we need to pretend that MethodData `.data` member is defaulting to a newly created `BasicCardPayment` dictionary. I've added prose to deal with that (the `restrictions` variable).

The same rules then need to apply to modifiers too. Consider:

```JS
// What does this mean when it's missing .data? 
const modifiers = [
  {
    supportedMethods: "basic-card",
    total: {
      label: "Total due",
      amount: { currency: "USD", value: "68.00" },
    },
  },
];
```

If we follow the same rules as I described above, then missing `.data` implies a `BasicCardRequest` whose `supportedNetworks = []`. 


-- 
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-method-basic-card/pull/71#issuecomment-474745628