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

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?

-- 
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-384582307