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

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