Support different amounts per payment method.

[adrianba]

This is a proposal for issue #4: Should it be possible to vary amounts depending on payment method.

The goal of this change is to make it simple for web developers in the majority case
when price does not vary by payment method. If a developer wishes to have a different
price for specific payment methods then they include a PaymentDetailsModifier that
includes the new total amount and optionally additional display items that are appended
to the main payment details display items for display. This allows the developer to
explain why the price is different due to a discount or surcharge, for example.

[rsolomakhin]

I am overall positive about this change because it gives us the ability to specify surcharges and discounts for things like debit cards and credit cards. It does not handle different currency for a payment method, but the currency manipulations can happen inside of the payment app if necessary, IMHO.

[ianbjacobs]

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 total amount for the selected payment method 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 payment method identifier appears more than once in the methodData or details.modififiers sequences, then throw a TypeError."

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

[dlongley]

@ianbjacobs,

-1 to PaymentMethodsChange or any more interactive imperative mechanisms than are absolutely necessary. Declarative mechanisms are better (Rule of Least Power) and allow for more interesting, smarter, innovative systems to be built.

Furthermore, if we're going to start allowing payment instruments to be selected in browser, we will need to consider the ability to select more than one for a particular payment request -- and all the UI and details and complexity that that entails. I think that this should be the domain of Payment Apps, particularly in version 1. Let's get some implementation experience with something simpler before pushing all of the complexity into the user agent.

[ianbjacobs]

@dlongley wrote:

"if we're going to start allowing payment instruments to be selected in browser, we will need to consider the ability to select more than one for a particular payment request -- and all the UI and details and complexity that that entails. I think that this should be the domain of Payment Apps, particularly in version 1."

Strong -1 to requirement that browsers or payment apps handle multi-tender payments in v1.

Furthermore, payment apps MAY still do multi-tender payments if they want, and send back the relevant data to the merchant.

I suggest that if we want to talk more about multi-tender payments, we start a different thread.

Ian

[rsolomakhin]

-1 to PaymentMethodsChange or any more interactive imperative mechanisms than are absolutely necessary. Declarative mechanisms are better (Rule of Least Power) and allow for more interesting, smarter, innovative systems to be built.

I have come around and agree that PaymentMethodsChange is not necessary. This pull requests works with without it.

EDIT: s/works with it/works without it/

[adrianba]

@ianbjacobs, the spec does say that the user agent should update UX based on changes from the update algorithm but I specifically stayed away from describing how an implementation should display the total as payment methods are selected. There are many different ways to do this especially as related to the different ways that payment apps might be implemented. I think it is implicit that a wise implementation would find some way to indicate to the user the different prices per payment method but friendly amendments to make this more explicit welcome.

On the topic of matching payment request identifiers, my position is that we should deal with simple matching in v1, which is what is currently specified. Should a proposal for more complex matching semantics be adopted in the group then any requirements dealing with matching payment methods would need amending. Such a proposal would need to include a comprehensive solution to this issue.

[ianbjacobs]

@adrianba wrote:

"Should a proposal for more complex matching semantics be adopted in the group then any requirements dealing with matching payment methods would need amending. Such a proposal would need to include a comprehensive solution to this issue."

We (AHB, MattS, and I) took an action to look into grouping/subclassing based on 26 May discussion. I would like to have a proposal by FTF meeting time. If that proposal does not get traction, I have no problem keeping simple matching semantics in v1.

[1] https://www.w3.org/2016/05/26-wpwg-minutes.html#item04

[adrianba]

Merged as 67f4f25.

Closes #4.