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

[adrianhopebailie]

Migrated from: 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]

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

[webpayments]

Is there danger that if we attempt to define these "terms" it will run
afoul of regulatory requirements? The world is wide...

On Mon, Jan 25, 2016 at 7:58 AM, Adrian Hope-Bailie <
[email protected]> wrote:

[image: 👎] 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.

—
Reply to this email directly or view it on GitHub
#66 (comment).

-Shane

[rsolomakhin]

I prefer that the browser has the control of the UI strings, including the button label. I expect Chrome's UI to always default to a single generic term, for example "Pay", "Buy", or "Authorize".

[webpayments]

+1 to Rouslan’s suggestion.

On Feb 9, 2016, at 3:17 PM, Rouslan Solomakhin [email protected] wrote:

I prefer that the browser has the control of the UI strings, including the button label. I expect Chrome's UI to always default to a single generic term, for example "Pay", "Buy", or "Authorize".

—
Reply to this email directly or view it on GitHub #66 (comment).

[msporny]

Migrated to w3c/payment-request#56.

@adrianhopebailie, this is your issue, please close it if you feel that w3c/payment-request#56 should be the new home for this issue.

[adrianhopebailie]

Have picked this up in the new thread.