Should the payment request support multiple pricing options?

[msporny]

Migrating from w3c/webpayments#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)
2. The payee wants to offer different prices depending on which payment method is used.
3. The payee wants to offer multi-tender payments
4. 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 Fix typo #76

[adrianhopebailie]

The full discussion from the old thread is useful context for anyone picking this up.

The issue centers around a balance of payer privacy (can't tell the payee up front all the supported payment methods and currencies) with flexibility (the ability to request payment in a variety of currencies and to offer different prices and currencies depending on the payment method).

The pragmatic approach may be to start simple and only support a single currency and price and to let the API evolve as we get more input from stakeholders on HOW they want this to work.

[ianbjacobs]

I believe this is subsumed by:
#4

[msporny]

Migrating to #4.