Re: [w3c/browser-payment-api] Merged PaymentRequest params and tweaked to address some issues (#133)

@adrianba I understand the motivations and agree they are valid but I don't believe they justify the inflexibility that results from this format.

Consider the following simple example. A new input parameter is defined for basic card payments. In general merchants will use the same value for all card payments. Today they would need to list out all of the card payment method identifiers they support in the `supportedMethods` array and then again list each individually in the `data` object with the same value provided under each.

So you have this:

```javascript
var request = new PaymentRequest(
  ["visa", "mastercard", "amex"], 
  details, 
  options, 
  {
    "visa" : {
      "customDataThing" : true,
    },
    "mastercard" : {
      "customDataThing" : true,
    },
    "amex" : {
      "customDataThing" : true,
    },
  }
);
```
Instead of this:
```javascript
var request = new PaymentRequest(
  options, 
  [
    "identifiers" : ["visa", "mastercard", "amex"],
    "data" : {
      "customDataThing" : true,
    }
  ]
);
```
If you multiply that out for a merchant that supports more than 3 card types and you have a horrible mess.

While I see the value in isolating data like `supportedMethods` and `options` that seldom change I would argue that a website can just as easily keep a static ("hard coded") template that contains all of this data and they will simply merge in the transaction specific data for each request. This may be as simple as adding a total and some line items.

What this proposal also addresses is the idea of "messaging" and the need to define a single JSON-serialized payment request message that is 1) not clouded with data that is only useful to the browser (like shipping options or line items) and 2) can be passed over process or network boundaries to a payment app.

I assert that it is a requirement of the API that the website has complete control over the content of the payment request that is ultimately received by the payment app. i.e.This should not be modified in any way by the user agent. This suggests that this payment request message should be passed as a single object to the API and that any other data that is only required by the user agent should be put into one or more other parameters.

---
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/133#issuecomment-211862755