This was discussed at the F2F.

The question is whether it should be possible to request different amounts depending on payment method selected and if so how to supply the amounts. During the discussion there was some desire to support this use case but also a desire to keep the case where amounts do not vary simple.

This is a very common use case, certainly in the UK; for example it is common for debit cards to attract no additional fees from the merchant, whereas credit cards often do.

Also some payment methods may support specific currencies, e.g. BitCoins, so a different amount is required in those cases. I guess I could conceive of this being true for other more traditional payment methods also that might support specific currencies.

I've no answer, but..

I think many merchants have traditionally used this to attract customers to their own Credit Card brand.

There are definitely European merchants that give the user a choice of being billed in EUR or GBP when paying with a UK bank card, certainly ATMs and several budget airlines. It's very hard for users to figure out the optimal decision with such systems, certainly I never figured out if it was good or bad.

Conversely, there are now some legal restrictions on charging different fees based upon the payment method in some jurisdictions. One could imagine some choices here leading to merchants violating laws, although that landscape appears complicated.

Yes, the landscape is complicated,,, I don't think we should be trying to code legislative restrictions into the API, the legislations moves with time and region.

As a further complication, the charging that certain merchants apply goes to a lower level than brand. For example a Visa Debit card can attract different changes from the Visa Credit. Currently the Payment Method identifiers don't specify a subbrand, but I've submitted PR #95 to show a reasonable example of how these split down. The PR shows a hierarchy and matching of PMIs could be done at multiple levels, so a merchant may say they accept "Visa" meaning any type of visa or be more specific if they only want to accept sub-brands, e.g. "Electron"

Just to provide a concrete (though definitely unusual) example, different rates for different cards are laid out in legislation for card payment of taxes in the UK: http://www.legislation.gov.uk/uksi/2016/333/pdfs/uksi_20160333_en.pdf

@davidillsley thanks for that, this shows an even greater granularity that the debit/credit split that I've shown. I agree it can get very complex, though I haven't personally experienced a merchant applying charges at this granularity, usually the merchant gives a blended via that covers any discrepancy as far as I can tell.

Let's keep the API simple for now, unless the merchants come back clamoring for this feature. The merchant can show a single price to the user and absorb the fees themselves.

Let's keep the API simple for now, unless the merchants come back clamoring for this feature. The merchant can show a single price to the user and absorb the fees themselves.

-1 This makes it difficult for merchants to incentivize users toward preferred payment methods. We want to enable more competition, not less.

We want to enable more competition, not less.

I am not sure I would see it that way - if anything it makes it harder for small players to compete with larger ones who can afford to subsidize merchants - but I agree it's desirable. It's very common in Europe for some verticals to surcharge some payment methods over others. There may be some middle ground here, where we initially provide the ability to vary the amount by brand/instrument and then have a future action item to look at supporting merchants who require further fidelity.

I agree with @nickjshearer

I think everyone is in favour of as much felxibility as we can offer to all stakeholders to allow them to innovate and differentiate BUT we must balance that with keeping the API simple (especially to start) and our need to produce something concrete very soon.

In short, I'm on the question being asked (yes it should be possible) but I'm not convinced we MUST offer this in the FPWD if we have an issue marker asking if it's a requirement and also how much fidelity the community feels is desirable.

In short, I'm on the question being asked (yes it should be possible) but I'm not convinced we MUST offer this in the FPWD if we have an issue marker asking if it's a requirement and also how much fidelity the community feels is desirable.

+1 to @adrianhopebailie's position

I'm happy that this is not in FPWD, that is not the question for me.

On behalf of the community, this is needed, so Im a -1 to leaving it out. The issue should say that we need different pricing per PMI IMO.

I think it makes sense to allow items to be optionally present in the payment-method specific data. What do you think?

var paymentRequest = new PaymentRequest(
    ["foo", "visa"],
    {"items": [{
        "id": "total",
        "label": "Total amount",
        "amount": {"currencyCode": "USD", "value": "1.00"}
    }]},
    {"requestShipping": false},
    {"foo": {
        "bar": "baz",
        "items": [{
            "id": "original",
            "label": "Original price",
            "amount": {"currencyCode": "USD", "value": "1.00"}
        }, {
            "id": "foodiscount",
            "label": "Foo payment method discount",
            "amount": {"currencyCode": "USD", "value": "-0.30"}
        }, {
            "id": "total",
            "label": "Total amount",
            "amount": {"currencyCode": "USD", "value": "0.70"}
        }]
    }});

I've thought of a better way to accomplish payment method specific discounts: have two "Buy" buttons on the webpage. This lets us keep the API simple in v1 and still accommodate the use case. What do you think? Example:

<button onClick="discountPrice();">Use Foo to buy for $0.70</button>
<button onClick="fullPrice();">Buy for $1.00</button>
<script>
function discountPrice() {
    new PaymentRequest(
        ["foo"],
        {"items": [{
                "id": "original",
                "label": "Original price",
                "amount": {"currencyCode": "USD", "value": "1.00"}
            }, {
                "id": "foodiscount",
                "label": "Foo payment method discount",
                "amount": {"currencyCode": "USD", "value": "-0.30"}
            }, {
                "id": "total",
                "label": "Total amount",
                "amount": {"currencyCode": "USD", "value": "0.70"}
            }]}).show().then(chargeDiscountPrice).catch(handleError);
}
function fullPrice() {
    new PaymentRequest(
        ["visa", "mastercard", "amex"],
        {"items": [{
                "id": "total",
                "label": "Total amount",
                "amount": {"currencyCode": "USD", "value": "1.00"}
            }]}).show().then(chargeFullPrice).catch(handleError);
}
</script>

It would work. It wouldn't scale super well. Also it presumes that the merchant knows all of the payment methods that the customer has in their wallet. I thought we weren't supporting that sort of interrogation? If we are not, then the merchant might be offering a buy button that would immediately fail. That doesn't feel super user friendly.

it presumes that the merchant knows all of the payment methods that the customer has in their wallet.

Good point. Multiple buttons would not work.

In TAG review @triblondon said:

#23 and #4 discuss the ability for merchants to express a payment method preference and to charge differently for different payment methods. Merchant preference seems basically meaningless unless there is a charge element - the user has no reason to choose a particular payment method simply because the merchant wants them to, but they would certainly be swayed if using one method added a surcharge. Perhaps the simplest way to model that would be to have the merchant pre-calculate a supplement charge to attach to the payment method at the PaymentRequest level, rather than polluting the PaymentDetails items dictionary with multiple additional charges per item (this is suggested in w3c/browser-payment-api#4 (comment), which I agree with). I'm concerned that any potential desire to add granularity to the cost of an individual item will get multi-dimensional very quickly - eg supporting different charges based on payment method, and also expressing pricing in different currencies, you would need a value for each intersection of that possibility space.

Merchant preference seems basically meaningless unless there is a charge element

The merchant preference may be that they can process them easier/cheaper, even if they do not want (or are compelled not) to charge the consumer differently.

FYI -- I verified with a small merchant -- they ARE paying higher fees because of the mismatch and confusion at the bank over the "billing" v "home" v "mailing" which failed. So the merchant DOES care. A tailor I used asked me about it because he paid a higher interchange due to "zip mismatch" and "address mismatch".

Yes, there are many reasons for the merchant to express a preference, Quite how we might reconcile this with the user preference may well be up to the user agent, but I think the API must support the semantics for the merchant to express their preference.

By separating the options and details of the PaymentRequest PR #133 would allow for this to be easily solved and an issue marker has been included to reflect this.

The solution is simply to allow an amount for each PaymentMethod (in exactly the same format as the amount specified in details.amount).

A sample details object might look like:

{
  "amount" : [{
    "currency" : "USD",
    "value" : "55.00"
  }],
  "supportedMethods" : [
    {
      "identifers" : ["visa", "mastercard"],
      "data" : {}
    },
    {
      "identifers" : ["bobpay.com"],
      "data" : {
        "merchantIdentifier" : "XXXX",
        "bobPaySpecificField" : true
      },
      "amount" : [{
        "currency" : "USD",
        "value" : "55.00"}],
      },
    {
      "identifiers" : ["bitcoin"],
      "data" : {
        "address" : "XXXX"
      }
      "amount" : [{
        "currency" : "XBT",
        "value" : "0.000123"}],
      },
    }
  }