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

I'm not in favour of this change. The motivation for the four arguments in the current API was as follows:

* `supportedMethods` - this sequence changes infrequently (and might even be hard-coded into a site). It's possible that a payment service provider might provide this data to a site. This data depends on the commercial agreements in place and what the site can handle. It is possible that payment responses passed to a service provider might not require any other code changes to the site.
* `details` - this is the data that varies per transactions. Most commonly this data reflects the contents of a shopping cart or basket. The site will construct this data before making a payment request.
* `options` - this is data that comes from the site's business needs. Do they need a shipping address? Do they want to request an email address? Etc. This data changes very infrequently and most likely requires a code change by the site to address.
* `data` - optional additional data that a payment method might need but that is entirely optional.

As I've mentioned before, the final `data` argument is the most experimental. I don't think we have much evidence yet as to whether this data is almost always required, rarely required, or sometimes required. The goal here was to keep the API simple in the cases where this data is not needed. If we have evidence to show that it is almost always needed then changing the shape here might be useful.

In general in the web platform, we have APIs that consume domain specific data rather than one large undefined blob of data. I think it is better to keep the arguments separate and consider who will change them and when.

---
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-211604352