Re: [w3c/payment-request] Alternative 'Pay' button wording options for Browser UI (#701)

Thanks, I missed the existing threads in my initial search.

@adrianhopebailie 
I do not have a particular use case in mind, other that currently working with a couple U.S. retail and wholesale companies that processes payments only if the order is validated for production first.

In my checkout instances, I show a "Continue" button once they provide the payment info (which is why I mentioned 'Add'), then "Submit order" for the confirmation screen. At no time, do I show a "Pay" labeled button. Even with a small aside notice mentioning that the transaction is not real-time, some people manage to assume the charge is immediate. I am concerned that a unique one-size-fit-all 'pay' verb does not help clarifying those details to the user very well. 

> One challenge with allowing custom UI is that this opens up additional attack surface so it would need to be considered carefully. If we allowed a choice of options (more secure than free text) what would those be?
I agree. I am really thinking of a small set of options with the most generic/common actions possible or a more simple 'Authorize for payment'. It needs to be defined. Happy to try and do more research.

@marcoscaceres
A possible alternative is a more arbitrary second label/qualifier such a side parenthesis next to the button, to help substantiate the `pay` action or obligation. Short of adequate context for the user, a unique pay verb button could lead to potential cart abandonment as much as it tries to alleviate it.

To the point of [discussion at the F2F](https://www.w3.org/2016/02/24-wpwg-minutes#item07). 
> <zkoch> I do think this point is largely lost on users to begin with
> <zkoch> I personally never know if I am being pre-authed or charged
> <zkoch> So my initial inkling is that from a UI perspective, nothing should really change

I would argue this premise is actually a good reason to try and start differentiating the two more clearly to the user instead of continuing leaving them in the unknown or incorrect assumptions.

I am not yet involved with wanting to implement the API. Just in the curiosity stage at the moment.
But as a dev, this point makes me pause for considering its use for non-live transactions.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/payment-request/issues/701#issuecomment-381034653