Re: [webpayments] Should the payment request support multiple pricing options? (#79)

> A user (or their payment app) may want to make choices based on the available pricing options. This would be a frustrating experience if the user first had to make some choices to see those pricing options -- and then back out and try others. It would also be an inefficient (or infeasible) process for a payment app that is automating the process.

What are the other options? If we are going to support the concept of pricing options at all I only see 3 ways for this to work:

 1. Payment requests contain computational logic (can be scripted) and can adjust the pricing based on user input within the app
 1. Payment requests must contain every possible pricing option pre-calculated by the payee
 1. Payment apps are able to request an updated payment request when users make choices that may change the price they pay

It's possible that we have combination of 2 and 3 which would be my preference. Provide a good set of options that assist users in making their initial choices but still have the flexibility to fetch an updated set of prices if required.

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