Alternative 'Pay' button wording options for Browser UI (the button in the sheet)

[hexalys]

I was looking the Google intro and I see the final button description is always Pay in the Chrome context. I am unable to find any mention in the spec that this can be changed.

For cases where the payment is either not processed right away, or the payment info if provided for future charges. I think there should be a way to change this 'Pay' button to alternative wording. 'Pay' being a strong indication that the transaction is deemed immediate, which could be misleading to users.

A couple of options like 'Add' or 'Send' would be useful in this context.

[adrianhopebailie]

This was discussed previously (I can't seem to find the previous issue). It would be useful if the requirement could be described in some more detail and the motivations or use cases also provided.

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?

[ianbjacobs]

@adrianhopebailie, I believe it was #56
which refers to #19

[marcoscaceres]

What is great for merchants and end-users is that, when presented with the payment sheet, they get a consistent, predictable, localized, and highly accessible user experience. Allowing arbitrary changes to “pay” (or whatever the user agent chooses to present as the textual representation) starts to break that contract/experience.

[hexalys]

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" button. Even with a small aside notice mentioning that the transaction is not real-time, people who don't read manage to assume the charge is immediate. I am concerned that a unique one-size-fit-all "Pay" does not help clarifying this to the user very well. This can cause customer service time or incorrect assumptions about an order fulfillment on the customer's part.

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.
*e.g. if the user knows it's a authorization or else, but freaks out due to "Pay" not matching expectations.

To the point of discussion at the F2F.

I do think this point is largely lost on users to begin with
I personally never know if I am being pre-authed or charged
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 to leave buyers in the unknown or with 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.

[marcoscaceres]

It might be that a developer signals the purpose of the payment request in some way, allowing the “pay” button to be changed to something more suitable by the UA. That would retain the qualities I listed above, without explicitly handing over control of the button label.

[marcoscaceres]

I am concerned that a unique one-size-fit-all 'pay' verb does not help clarifying those details to the user very well.

Note that this is supposed to be communicated by the merchant’s UI, and by calling PaymentResponse.complete(“unknown”). Would be great to explore if that’s sufficient.

[hexalys]

Note that this is supposed to be communicated by the merchant’s UI, and by calling PaymentResponse.complete(“unknown”). Would be great to explore if that’s sufficient.

It's post-action. But that could help. Or perhaps, additionally relying on those enums as selective input, for the UA to use a button label according to the expected results. I am not too clear on what "unknown" would cover. I really think "authorized" is broad enough that it could be added, with "unknown" for other things.

e.g. Should the request sends a custom { "fail", "authorized"}; the UA can determine that this is payment authorization request and it does not expect the payment to be processed... and therefore use an "authorized" label... just a thought.

[stpeter]

@hexalys You raise a very good point. It strikes me that the current flow & API are optimized for one-time, real-time purchases by consumers - not recurring payments (e.g., subscriptions), not split payments (e.g., multiple cards), not hold-then-pay (e.g., reservations or temporary credit charges to lock in a price with payment to follow by some other means), not more complicated B2B interactions, etc. I'm not sure what to do about that (all of those scenarios add complexity), but we should be aware of the limitations...

[hexalys]

@stpeter

It strikes me that the current flow & API are optimized for one-time, real-time purchases by consumers

Nods. I am hopeful that covering additional flows can be done without being too specific like #111 or the previous transactionType shown on adrianhopebailie@e349750 were.

Maybe a fairly clear specs around a new minimal set of enums that cover all or most use cases can work. e.g.

PaymenType enum

enum PaymentType {
    "payment",
    "partial",
    "authorization",
    "capture",
    "subscription",
    "reservation",
    "validation"
};

They can be of informal value which does necessarily alter the API process beyond display context...

[adrianhopebailie]

We have also discussed "transaction types" in the past and to-date the WG has concluded that these are payment method specific.

For example, does it make sense to have a subscription if the method of payment is via Bitcoin?

To date, the approach of the WG has been that the custom data in a payment method is a great place to experiment with new request data that, if it is shown to be universally applicable/useful, could be "upgraded" to hang off the parent PaymentRequest object.

Payment methods that support different behavior based on the transaction type should define a way to express this in their request data model. If there is a consensus to add this to the core PaymentRequest then we'll do that in a future version.

As to how this impacts the UI, that is a different question. We have intentionally not imposed strong requirements on implementations with regards to UI, this is competitive space.

For example, there is no guarantee that the payment sheet (displaying the list of payment instrument/payment handler options) will even have a "Pay" button (the Chrome one does, but that is just one implementation). Mozilla may have a button per instrument labelled "Next" that, when pushed invokes the payment handler which (in the case of basic-card) may be a payment handler built-in to the browser that has a confirmation screen with a "Pay" button.

A concrete next step might be to define this list specifically for card payments and propose that it is added to the Basic Card payment method spec?

[marcoscaceres]

Based on @adrianhopebailie's feedback, I'm marking this as "Future Candidate Feature". We can come back to this after CR and as we gain more experience with payment request.

Thanks again, @hexalys, for the fruitful discussion here. I'm sure this is something we will return to sooner rather than later.

[mountainhippo]

We heard at the April F2F 2019, that the labelling of the pay button is problematic for merchants, from Dee

[gillesbouvier-qz]

This issue is still opened 5 years later. I would like to see an "intent", something like:

• pay now
• pay later
• authorize (could be used for payment method update, reservation...)

[ianbjacobs]

@gillesbouvier-qz, right now we have no active work on new features.