[browser-payment-api] Should the payment request support multiple pricing options? (#54)

Migrating from https://github.com/w3c/webpayments/issues/79:

Originally raised in the comments at https://github.com/WICG/paymentrequest/issues/41#issuecomment-178356991 and reflected in the issue above by @adrianhopebailie:

There a number of reasons why a payment request may carry multiple pricing options:
 1. The payee wants to explicitly accept payment in multiple currencies (USD and XBT for example)
 1. The payee wants to offer different prices depending on which payment method is used.
 1. The payee wants to offer multi-tender payments
 1. The payee wants to offer discounted pricing under special circumstances (loyalty, coupons etc)

These use cases could be addressed in different ways:

* A protocol like the Interledger Protocol would make matching the currency of the payer and payee unnecessary as the protocol would allow the payee to receive payment in the currency of their choice even if the payer pays using a different asset. The same could be said for many card based payments where currency conversion is handled by the network. i.e. For some use cases the payee simply provides a price and the payment app takes responsibility for making the payment at that price and in that currency.

* Each payment method could specify a price, or there could be a base price and any methods with a variation on that price would specify their unique price.

* The payment request can specify a guide price and the payment app can request updated pricing from the payee based on user input (coupon, currency selection, loyalty program login etc). This is related to the question at #76 

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/browser-payment-api/issues/54