Should it be possible to vary amounts depending on payment method

[adrianba]

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.

[mattsaxon]

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.

[burdges]

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.

[mattsaxon]

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.

[mattsaxon]

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"

[davidillsley]

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

[mattsaxon]

@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.

[rsolomakhin]

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.

[dlongley]

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.

[nickjshearer]

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.

[adrianhopebailie]

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 :+1: 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.

[dlongley]

In short, I'm :+1: 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

[mattsaxon]

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.

[rsolomakhin]

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"}
        }]
    }});

[rsolomakhin]

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>

[halindrome]

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.

[rsolomakhin]

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.

[adrianhopebailie]

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.

[mattsaxon]

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.

[djackso3]

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".

[mattsaxon]

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.

[adrianhopebailie]

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"}],
      },
    }
  }

[jnormore]

What's the goal of providing the different amounts up front (on init) like the proposals here? Is it to give user agents the ability to display the amounts alongside each payment option before any are selected by the user? If not, then reducing the complexity of the initialization params would be preferable IMO and give the merchant flexibility to control price dynamically at payment app selection, for example just a callback similar to what is possible with shippingoptionchange where they can change the price however they want and we aren't putting any restrictions on that logic.

[adamroach]

Is it to give user agents the ability to display the amounts alongside each payment option before any are selected by the user?

That's certainly something I (in my role as a consumer) would want. When I'm selecting a payment method, if the amount I'm paying varies based on that method, that's going to frequently be far more important to me than the affiliation of the payment provider.

[msporny]

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

One of the hard lessons we learned from the RDFa and Microdata standardization effort was that people (developers) have a hard time keeping state information in their head. Yes, I know that seems obvious, but you tend to forget about this when you're designing specs. If your data structure requires the developer to understand some sort of state machine (and the transitions that the state machine can go through), that can lead to errors.

Your proposal, @adrianhopebailie, has a light-touch state machine in it. That is, read the amount at the top level, and then override if a particular payment method has an amount field. While that seems simple, it's more complexity than may be necessary. We could just specify the amount on a per-payment method basis. The downside to this approach is that you repeat the amount. That said, I don't think that repetition is that terrible and it removes the need to understand that the data structure is is interpreted by a state machine.

So, -0.5 for specifying amount at the top of the data structure and overriding it in each payment method set.

+0.5 for repeating the amount information in each payment method block.

[adamroach]

I do like this approach, particularly because it solves the "different amounts for different methods" issue at the same time as providing an obvious solution for having different currencies available (i.e., it can be trivially used to address issue #3)

[rsolomakhin]

The approach by @adrianhopebailie is good. Keep in mind that the merchant will need to know the type of method currently selected when the user changes their shipping address and option, because the merchant needs to update the total price using e.updateWith() call. Therefore, we should place methodName property into PaymentRequest interface.

[adrianhopebailie]

@msporny are you suggesting that we drop the total from the PaymentDetails object completely and move it to PaymentMethodData?

So the example in the spec becomes:

var req = new PaymentRequest(
[
  {
    supportedMethods: ["visa","bitcoin"],
    total:  {
      label: "Total due",
      amount: { currency: "USD", value : "60.00" }, // US$60.00
    }
  },
  {
    supportedMethods: ["bobpay.com"],
    total:  {
      label: "Total due",
      amount: { currency: "USD", value : "59.00" }, // US$59.00
    },
    data: {
      merchantIdentifier: "XXXX",
      bobPaySpecificField: true
    }
  }
],
{
  displayItems: [
    {
      label: "Sub-total",
      amount: { currency: "USD", value : "55.00" }, // US$55.00
    },
    {
      label: "Sales Tax",
      amount: { currency: "USD", value : "5.00" }, // US$5.00
    }
  ]
},
{
  requestShipping: true
});

[tommythorsen]

Is it to give user agents the ability to display the amounts alongside each payment option before any are selected by the user?

That's certainly something I (in my role as a consumer) would want. When I'm selecting a payment method, if the amount I'm paying varies based on that method, that's going to frequently be far more important to me than the affiliation of the payment provider.

Bear in mind, though, that the user agent may not be able to present these amounts to the user. The choice between payment methods may have to happen inside of the payment app. The reason for that is that as per the current spec proposals, the user picks the payment app, not the payment method in the user agent. If we consider Adrian's example above, the user could have installed a single payment app that supported visa, bitcoin and bobpay.com.

As an aside, I think it is weird to have items that don't add up to the total. As a payer, this would totally put me off. Would we need to have additional display items for each payment method, in order to show what the difference in total amount is caused by?

[adrianhopebailie]

the user picks the payment app, not the payment method

Correct! Maybe the selector can show a range next to each app?

• Pay with App1 ($49 - $50)
• Pay with App2 ($52)
• Pay with App3 ($49 - $50)

[jnormore]

At the risk of repeating some of my original comment, as a customer I've never experienced the behaviour of a merchant site showing me different prices based on which payment options I have. I'm aware I have a very limited view from a customer perspective but is this really common enough to add this kind of complexity to the spec and to the requirements on the UI (showing prices for each app)? If it's a discount on a merchant branded payment option then that can be communicated to the customer in another way before payment is initiated.

[adrianhopebailie]

If it's a discount on a merchant branded payment option then that can be communicated to the customer in another way before payment is initiated.

Fair point. I guess this question is one of scope. This could be achieved in different ways and we need to get feedback on whether the complexity is justified to do it in the API.

An interesting consideration is that if you put the price in the payment method specific data you are left with nothing else in the request. In other words, a payment request is actually a set of payment requests for different payment methods.

[webpayments-specs]

@adrianhopebailie wrote:

An interesting consideration is that if you put the price in the payment method specific data you are left with nothing else in the request. In other words, a payment request is actually a set of payment requests for different payment methods.

That strikes me as a reasonable way to think about it. The API could offer a finer-grain override of the "default" amount/currency.

Ian

[adrianba]

Closed by #211.