Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app?

[msporny]

Migrated from w3c/webpayments#66 and https://github.com/WICG/paymentrequest/issues/46:

@adrianba:

It may help users understand what they are accepting if the web site is able to label the "accept" button. For example, if a user is about to "Buy" something, "Reserve" something, "Subscribe" to something, etc.

@mattsaxon:

This is linked to the comment I just made on issue #65
+1 to distinctions as suggested by @adrianba

@ianbjacobs:

It seems there are several topics here:

1. The API may be used in a variety of user interactions, and the entity that displays the relevant payment apps may need a label to communicate the interaction to the user. Note that these labels may not be in English, and that the specification probably cannot prevent misuse of labels.
2. The API may be used in a variety of flows, such as "pay", "register", or "reserve". There may be hacky ways to implement the different scenarios, like using amount=0 to imply "register". However, we should consider whether we want to define a small number of verbs that become part of the data exchanged with the payment application. We will not be able to address every possible scenario, but I have now heard three that sound like it could be useful for the merchant to be able to pass on to the payment application.

Furthermore, it seems there is a relationship between this topic and a topic we discussed previously that translated in the following charter language: "The Working Group will consider support for deferred payment execution to enable use cases where the actual execution of a payment requires steps that are out-of-band with respect to the message flows and APIs defined by the Working Group." That was a use case where the user chose a push payment instrument, but the merchant did not want the payment to be completed before the merchant regained control of the flow.

Please let me know if this makes sense:

• The distinction between "what the user sees" (label) and "what the merchant wants to accomplish"
• We may wish to define a set of verbs so the merchant can communicate what they want to accomplish.

[adrianhopebailie]

My original response to this issue was the following:

👎 unless we have a pre-defined set of verbs the payee can choose from or these are automatically inferred by the payment app based on the terms of the request.

The ability for the entity requesting payment to manipulate the user interface presented to the payer should be considered VERY carefully. This is heavily locked down in many existing payment systems today for good reason.

EXAMPLE: A developer writing custom firmware for physical card acceptance devices is unable to use custom prompts when the device is requesting input from the user. The reasoning is that the developer could publish a malicious application that prompts a user to input their PIN when the data is not being captured securely and the developer is therefor able to steal the user's PIN.

This is a well-understood attack vector in a very mature payments system. Allowing payee's to control the input/prompts presented to users in our far more open and flexible system may expose the user to attacks we can't even imagine today.

I would suggest 3 alternatives (with preference for the first):

1. Allow the payment app to display an appropriate verb based on whatever logic they choose. The payment app is the payer's agent and so is not likely to be malicious or defraud the payer. Example: If the payer is tricked into making a payment or signing up for a subscription by their payment agent it's far more likely they can pursue legal action against the publisher of the payment app than the payee.
2. Always use the verb "Authorise" (which can be easily translated) and allow the payee to provide an appropriate product description:
   1. "Buy 15 widgets" - Authorize
   2. "Reserve $120 for your rental car" - Authorize
   3. "Subscribe to a weekly newsletter for $15 per week" - Authorize
3. Define a set of verbs which are not provided by the payee but selected by the payment app or mediator (browser) based on the terms of the payment being requested. The algorithm used to select these could be well-defined as part of our standard.

[adrianhopebailie]

I also heard support for the browser having control over this and not the website from @rsolomakhin amongst others.

There was some discussion on this topic at the face to face and an interesting point was made by @mattsaxon and @vkuntz about the need for a user to confirm exactly what they are authorizing.

So, it was suggested that the payee be able to provide a string that is always used to prompt the user and the user's acknowledgement is tied to that string.

Examples:

• "Pay $50 to XYZ Store for invoice ABC123"
• "Reserve $300 for payment to ABC Car Rental"
• "Create a new recurring payment to Bob's DIY Magazine for $25 per month"

It was also suggested that the payee be able to provide a link to some T&Cs and request that the user click a check-box to acknowledge that they have read these.

I would suggest we think this through very carefully and consider all of the regulatory and liability implications for how we address this requirement.

[halindrome]

The T&Cs concept raises an interesting point. There are many merchants that have specific return policies, restocking fees, conditions, etc. Today the user experience is very much one where you are often forced to acknowledge these. Merchants are not going to want to lose that ability - even though the legality and enforceability of it is suspect in many jurisdictions Regardless, we either need to have a hook for this, or we need to provide guidance that says "merchants who want to ensure adherence to site-specific terms and conditions must obtain that acknowledgement from the purchaser prior to requesting payment through this API". Or something to that effect.

[mountainhippo]

@halindrome it would be nice to allow T&Cs to be explicitly accepted in the "checkout" experience but your suggestion of pre-emptive acceptance of the T&Cs before invocation of the API is certainly a practical first step

[rsolomakhin]

Should a website be able to provide a label for the "Buy" or "Checkout" button displayed in the payment app?

The primary use cases for this (IMHO) are subscriptions, reservations, and 0-dollar authorizations. I think this can be accomplished via lines items instead. Line items strings are controlled by the merchant.

Standard purchase code snippet:

var paymentDetails = {"items": [{
    "id": "total",
    "label": "Sweater",
    "amount": {"currencyCode": "USD", "value": "30.00"}}]}

Standard purchase UI mock up:

Sweater .... $30.00
[Pay]

Subscription code snippet:

var paymentDetails = {"items": [{
    "id": "total",
    "label": "Monthly subscription (charged monthly)",
    "amount": {"currencyCode": "USD", "value": "7.00"}}]}

Subscription UI mock up:

Monthly subscription (charged monthly) .... $7.00
[Pay]

Reservation code snippet:

var paymentDetails = {"items": [{
    "id": "total",
    "label": "Reserve room (charged at checkout)",
    "amount": {"currencyCode": "USD", "value": "100.00"}}]}

Reservation UI mock up:

Reserve room (charged at checkout).... $100.00
[Pay]

0-dollar auth code snippet:

var paymentDetails = {"items": [{
    "id": "total",
    "label": "Authorization (no charge)",
    "amount": {"currencyCode": "USD", "value": "0.00"}}]}

0-dollar auth UI mock up:

Authorization (no charge) .... $0.00
[Pay]

(OK, the last one is a bit cringy.)

[davidillsley]

I don't think it makes a lot of sense to worry too much about the specific word on a button which may or may not exist in the payment app.

On the other hand, I think it does make sense to indicate to the payment app what kind of user journey its in the middle of, and where in that journey it might be.

For example, if building a basic card payment app, knowing whether or not there's a 'confirm' page after the card details are returned to the merchant allows me to choose how defensive my UI is, and whether I want to have a confirm step for this payment request within the app.

So it feels to me like its probably useful to enumerate the different journeys and allow a hint to be passed into the payment app which can then do the best thing for the user.

[mattsaxonwp]

+1 to enumeration of the journey types

[ianbjacobs]

This relates to issue #19 as well. We have identified a number of scenarios: enrollment, payment, reservation, recurring payment, ... At a high level I like for the merchant to be able to send a clear signal plus hints for how to communicate to the user. (We need a concrete proposal. :)

Ian

[adrianhopebailie]

👍 on enumerating journeys and the link to #19

I am thinking that the request needs to have a "transaction type" which is defined somewhere as a fixed enumerated list and the decision of how the user agent and payment app render their UI based on this is up to them.

Another idea is to encapsulate this in the payment method identifier...
Eg: visa-credit-preauth, visa-credit-purchase, visa-credit-subscription

[ianbjacobs]

I suggest that we not encode more information the URI, especially if orthogonal to the payment method.

Ian

[adrianhopebailie]

Based on some of the observations in #19 I would like to propose that unless there is a need for the user agent to display the confirmation button (as opposed to the payment app) this is a non-issue.

Thus I want to re-state my proposal that we:

Allow the payment app to display an appropriate verb based on whatever logic they choose. The payment app is the payer's agent and so is not likely to be malicious or defraud the payer.

All of the logic about what type of payment processing is being requested should be understood by the payment app (which has claimed explicit support for the requested payment methods) so the payment app should be capable, based on the payment details and payment method data, of indicating to the user what they are accepting.

I propose that we close this issue and open a separate discussion to address the request from @mattsaxon and @vkuntz for a standard way to exchange the agreed payment obligation between payer and payee.

@rsolomakhin has suggested that the label on the "total" (last) line item is the appropriate string but I don't think we should conflate the two. One is a clean user readable string explaining the total of the transaction the other is a legal obligation passed from the payee and acknowledged by payer.

[mattsaxon]

I'd like to leave open until the API has the hint that is needed for it to display the appropriate message.

+1 to obligation being a separate issue

[rsolomakhin]

Agree with @adrianhopebailie to let the payment app display an appropriate verb based on their logic.

[adrianhopebailie]

@mattsaxon My suggestion is that the hint is not needed because the payment app should be able to infer enough from the payment method data to display the appropriate UI.

The only component that requires "hints" is the user agent because it's not expected to understand anything about payment method data.

[sideshowbarker]

from @adrianhopebailie

The only component that requires "hints" is the user agent because it's not expected to understand anything about payment method data.

Based on some of the observations in #19 I would like to propose that unless there is a need for the user agent to display the confirmation button (as opposed to the payment app) this is a non-issue.

I propose that we close this issue and open a separate discussion to address the request from @mattsaxon and @vkuntz for a standard way to exchange the agreed payment obligation between payer and payee.

Nobody has objected to opening up a separate new issue for that, so I wonder if you will be going ahead with opening it, or whether you’d prefer for @mattsaxon and @vkuntz to open it. IMHO it seems like @mattsaxon ought to be the one to open it, since it’s his request.

from @mattsaxon

I'd like to leave open until the API has the hint that is needed for it to display the appropriate message.

Are you willing to open a separate new issue for “standard way to exchange the agreed payment obligation between payer and payee”, and if so, once it’s open, would you then agree that this issue should be closed as @adrianhopebailie has proposed? Or is there something else this covers that would not be covered by the “standard way to exchange the agreed payment obligation between payer and payee” proposal?

At least as far as what @adrianhopebailie has asserted, in the comments cited above, he’s said that there seems to be no need for a hint to the UA. Do you disagree?

[sideshowbarker]

Nobody has objected to opening up a separate new issue for that, so I wonder if you will be going ahead with opening it, or whether you’d prefer for @mattsaxon and @vkuntz to open it. IMHO it seems like @mattsaxon ought to be the one to open it, since it’s his request.

Wait, I guess #113 (raised by @adrianhopebailie yesterday) is actually that new issue?

[mattsaxon]

At least as far as what @adrianhopebailie has asserted, in the comments cited above, he’s said that there seems to be no need for a hint to the UA. Do you disagree?

I believe this is covered by #19 and there is now #113 to cover obligations, I think this issue is no longer needed.

[adrianhopebailie]

Closed in favor of #19 and #113