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

> @@ -284,16 +284,77 @@
>            payment app.
>          </div>
>          <div class="note">
> -          <p>The <code>supportedMethods</code> sequence contains the <a>payment method identifiers</a>
> -          for the <a>payment methods</a> that the merchant web site accepts.</p>
> +
> +          <p>The <code>details</code> contains the core payment request data that will be passed on to the user selected
> +            <a>payment app</a>.</p>
> +
> +          <p>The <code>amount</code> sequence contains the amount (possibly in different currencies) that the website

Hmm, I see. I'd prefer the ability to override amount on a per method basis, but am concerned about the complexity for the developer (they will need to know that amounts in a payment method override the top-level amount - just one more thing for them to know/understand). 

The other alternative is to have an amount per supported payment method set, the downside here being that the same amount might be repeated. The downside, though, might not be that terrible as maybe most prices would in fact be different per payment method set?

The core problem is in duplication. Do we get more duplication with a top-level "amount" w/ overrides or a per supportedMethod amount w/ no top-level "amount"? My gut is telling me we get less duplication w/ the latter, but I admit to not having put a tremendous amount of thought into it.

---
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/files/38f22264a20bbe3dcaaa3d47036d9c08c07237fc#r59235836