Re: [paymentrequest] Consider allowing a web site to provide a label for the "Buy" or "Checkout" button (#46)

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.

Ian

---
Reply to this email directly or view it on GitHub:
https://github.com/WICG/paymentrequest/issues/46#issuecomment-173344190