Should the payment request support multiple pricing options?

[adrianhopebailie]

Originally raised in the comments at https://github.com/WICG/paymentrequest/issues/41#issuecomment-178356991

There a number of reasons why a payment request may carry multiple pricing options:

1. The payee wants to explicitly accept payment in multiple currencies (USD and XBT for example)
2. The payee wants to offer different prices depending on which payment method is used.
3. The payee wants to offer multi-tender payments
4. The payee wants to offer discounted pricing under special circumstances (loyalty, coupons etc)

These use cases could be addressed in different ways:

• A protocol like the Interledger Protocol would make matching the currency of the payer and payee unnecessary as the protocol would allow the payee to receive payment in the currency of their choice even if the payer pays using a different asset. The same could be said for many card based payments where currency conversion is handled by the network. i.e. For some use cases the payee simply provides a price and the payment app takes responsibility for making the payment at that price and in that currency.
• Each payment method could specify a price, or there could be a base price and any methods with a variation on that price would specify their unique price.
• The payment request can specify a guide price and the payment app can request updated pricing from the payee based on user input (coupon, currency selection, loyalty program login etc). This is related to the question at Should we standardise a callback mechanism for payment apps to communicate to 3rd parties? #76

[dlongley]

The payment request can specify a guide price and the payment app can request updated pricing from the payee based on user input (coupon, currency selection, loyalty program login etc).

A user (or their payment app) may want to make choices based on the available pricing options. This would be a frustrating experience if the user first had to make some choices to see those pricing options -- and then back out and try others. It would also be an inefficient (or infeasible) process for a payment app that is automating the process.

[adrianhopebailie]

A user (or their payment app) may want to make choices based on the available pricing options. This would be a frustrating experience if the user first had to make some choices to see those pricing options -- and then back out and try others. It would also be an inefficient (or infeasible) process for a payment app that is automating the process.

What are the other options? If we are going to support the concept of pricing options at all I only see 3 ways for this to work:

1. Payment requests contain computational logic (can be scripted) and can adjust the pricing based on user input within the app
2. Payment requests must contain every possible pricing option pre-calculated by the payee
3. Payment apps are able to request an updated payment request when users make choices that may change the price they pay

It's possible that we have combination of 2 and 3 which would be my preference. Provide a good set of options that assist users in making their initial choices but still have the flexibility to fetch an updated set of prices if required.

[dlongley]

It's possible that we have combination of 2 and 3 which would be my preference. Provide a good set of options that assist users in making their initial choices but still have the flexibility to fetch an updated set of prices if required.

This sounds fine (and preferable) to me. Ideally, most of the information will be available via 2, but we could allow for cases when 3 is necessary.

[alexdown]

I'm for 2.

The payment app tells the payee's website which payment methods are supported... it is on the payee to add additional items (e.g. "fees") to the payment request's detail for the specific payment method.

[msporny]

@alexdown said:

The payment app tells the payee's website which payment methods are supported

That's a violation of the customer's privacy. The current design is for the payee site to say which payment methods it accepts and for the payer's software to expose the available methods to the payer for selection.

Welcome to the group, @alexdown :)

[rsolomakhin]

I think it's a good idea to have pricing options for loyalty cards, for example. I don't think it's necessary for version 1 of the API, in the interest of building the most common and simple API for now. Perhaps in version 2 would be better.

That being said, I would prefer option 3 ("Payment apps are able to request an updated payment request when users make choices that may change the price they pay"), because I want to avoid computational logic and exhaustive pre-calculation. Also, option 3 fits the "paymentRequest.setAddressChangeListener()" paradigm nicely. I'm thinking about perhaps "paymentRequest.setPaymentInstrumentTypeListener()", for example.

[halindrome]

Here are a handful of use cases from our base use case document that I feel are related to this feature:

6.1.3 (application or marketing elements) supports this directly in that it talks about loyalty cards and coupons. However, at least in the latest draft these are not in any Roadmap "phase".

6.2.1 (discovery of accepted schemes) talks to having multiple accepted payment schemes. If that's the case, it should be possible for different schemes to have different payment amounts (e.g., if you pay with Visa it is this much, in Bitcoin it is this much).

6.2.2 (selection of payment instruments) also goes to this case. The user (or their automated agent) needs a way to intelligently decide which payment instrument or combination of instruments will be used.

[adrianba]

We've discussed the idea of having the user agent indicate to the web page what payment method has been selected as a way of accomplishing what @alexdown suggests. This still has privacy implications, which is one reason we haven't made a more formal proposal yet. This topic also is something we can add support for later. It's not clear that merchants necessarily want to advertise all the different pricing options they might want to offer right up front.

[adrianhopebailie]

Another consideration is the user experience for picking a payment app.

Is price an important factor in making the decision? If the payee is prepared to accept different amounts depending on the payment method should the user be able to see that when making their choice of payment app. i.e. Should each payment app choice also show the price the user will pay if they select that app?

If not, there is no incentive for merchants to price different payment methods differently which begs the question of what incentive a merchant has for using the API over a payment flow they have more control over that allows them more influence on the payment method.

[webpayments]

On Thu, Feb 11, 2016 at 7:06 AM, Adrian Hope-Bailie <
[email protected]> wrote:

Another consideration is the user experience for picking a payment app.

Is price an important factor in making the decision? If the payee is
prepared to accept different amounts depending on the payment method should
the user be able to see that when making their choice of payment app. i.e.
Should each payment app choice also show the price the user will pay if
they select that app?

Well - I think at least we should not prevent a merchant from doing this.
Consider the case where a merchant has a private branded payment method
(e.g., Amaco used to have their own credit card) and if the consumer uses
that method, it is less expensive / error prone for the merchant. The
merchant should be able to pass some of that savings onto the consumer as
an incentive. Target Stores do this today with their self-branded debit
card, for example.

-Shane

[dlongley]

@adrianhopebailie,

Should each payment app choice also show the price the user will pay if they select that app?

JFYI - the web-payments.io demo has been updated to show a price on the payment app selection screen now.

[msporny]

Migrated to w3c/payment-request#54.

@adrianhopebailie, please close the issue if you feel that w3c/payment-request#54 is the right home for this issue.

[adrianhopebailie]

I am closing this but think the history here is important for anyone picking up the issue on the other thread.

We also discussed this at the F2F and I don't believe came to consensus so this is still an important point of discussion.