- From: ianbjacobs <notifications@github.com>
- Date: Wed, 08 Jun 2016 12:21:34 -0700
- To: w3c/browser-payment-api <browser-payment-api@noreply.github.com>
- Cc:
- Message-ID: <w3c/browser-payment-api/pull/211/c224699386@github.com>
Hi @adrianba, Compared to the proposal that Jason, Andre, Rouslan, and I were working on [1]: * Both proposals have per-payment-method total (which allows for both price and currency changes per payment method). In addition, your proposal alllows for "local" display items, which makes sense, so +1. * Our proposal suggests a PaymentMethodsChange event when the user chooses (in the browser) a payment instrument from a given payment method. Your proposal does not include that. Is the expectation that the browser will update the total based on user selection? I see this sentence and want to be sure that it refers to the display of total-after-user-selection: "This field is commonly used to add a discount or surcharge line item indicating the reason for the different <code>total</code> amount for the selected <a>payment method</a> that the browser MAY display." Or do we need additional language recommending the user agent SHOULD display the updated information based on user selection? Finally, your change includes this: "If a <a>payment method identifier</a> appears more than once in the <code>methodData</code> or <code>details.modififiers</code> sequences, then <a>throw</a> a <a><code>TypeError</code></a>." In a separate discussion we are talking about how to manage subclassing of payment methods (with constraints) and we might propose an approach where PMIs are repeated but with a different set of constraints. If we do this, and if we express the constraints within the same URL, then the above language will be ok. But if we express the constraints in JSON alongside the URL, then I may request a change to the above to support the additional semantics. No change for now, but I wanted to flag this as something we may come back to. Summary: I am supportive of the change proposal, which I believe addresses use cases like: * surcharges and discounts per payment method * "We accept this amount in USD and this amount in bitcoin." As we concluded in our proposal, I do not think we should do "multiple currencies for same payment method" as that can be handled separately (see [1]). Ian [1] https://github.com/w3c/webpayments/wiki/Support-for-multi-price-and-currency --- 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/211#issuecomment-224699386
Received on Wednesday, 8 June 2016 19:22:29 UTC