Re: [webpayments] PROPOSAL: Pass the list of supported payment methods and the method-specific data in a single object (#77)

I do not agree with this proposal. In general we want to optimise for the develop experience. The current PaymentRequest API proposal accepts several different arguments and for a specific reason.

The four arguments are:
* *A list of payment methods accepted by the merchant*. You should think of this as a simple list of all the stickers a merchant would put in their window about payment methods accepted. This is likely to be fixed data that changes very infrequently for a merchant.
* *Payment details for this specific request* i.e. what the web site visitor is being asked to make a payment for. This value will vary for each transaction and includes the transaction amount and optionally line items.
* *An optional payment request options object*. These options alter the processing that the user agent performs for the transaction (for example whether or not shipping address should be collected). This is unlikely to vary from one transaction to the next. It may not be needed for some sites.
* *Optional payment method specific data*. In my view, we don't yet have a lot of experience for how this might be used by different payment methods. Currently the spec says that the data must match up to the payment methods accepted by the merchant but it is possible that groups of methods might want to share data. It's also entirely possible that (especially for raw PANs, for example) that this data is not needed at all for some sites. It's probably that this data won't very for each transaction.

So the design of the API is to be clear on which things are different per transaction, which are likely to be constant, and separates out things that might not be needed to keep the developer experience simpler. We also get to benefit from the built in IDL-based argument validation that most browser engines provide in an easy way (I have received feedback about the specific WebIDL that needs to improve to support this). In general, browser APIs don't try to take a huge blob of data as a single data structure - we guide developers through the experience with more structured arguments and that is our goal here. I'm not suggesting that we're done with the arguments but I don't agree with a blanket "merge everything into a large JSON-like object" is a good proposal.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webpayments/issues/77#issuecomment-179587020