Re: Web Payments Demo

Hi Mike, Rouslan,

Thanks for this, it's great to be starting to get into this level of
implementation detail and sharing notes so we can validate our design
decisions.

I want to raise something that I think may be a point of misunderstanding
or maybe even disagreement but we need to all be clear about. It's been
raised before but I want to keep emphasizing this because it is important
we are all on the same page.

1. When the user agent has determined the intersection of payment methods
that can be used to handle a payment request then it must determine which
installed payments apps have one or more of those payment methods enabled.
2. The user agent then prompts the user to select a payment app from that
set to handle the payment request (NB: The user does not select a payment
method, they select a payment app).
3. If that payment app has more than one payment method enabled that can
handle the request it must determine which one to use by either prompting
the user or using some other heuristics.

Some thoughts:

   - Payment methods are an abstract concept that we shouldn't force users
   to understand. They pick a payment app from a list of apps that they
   themselves installed.
   - How the selection of a payment method is done by a payment app will
   depend on the payment method. We shouldn't assume that it always means
   selecting a payment instrument. That is a very card-centric way of seeing
   things.
   - A user might register a payment app that is just a wrapper around a
   payment instrument like a credit card. In that case the user never picks a
   payment method explicitly or implicitly because they simply choose to pay
   with that app which only has a single payment method enabled.



On 27 May 2016 at 05:21, Rouslan Solomakhin <rouslan@google.com> wrote:

> Thank you for the comments, Michael. This is indeed good food for thought
> for all browser vendors. I will pass this on to the product and UX teams in
> Chrome.
>
> On Thu, May 26, 2016 at 8:13 PM Michael[tm] Smith <mike@w3.org> wrote:
>
>> Hi Rouslan,
>>
>> Rouslan Solomakhin <rouslan@google.com>, 2016-05-26 03:20 +0000:
>> > ...
>> > I'm not sure whether the the broader community has seen this, Chrome has
>> > some demo websites as well:
>> >
>> > 💵 https://rsolomakhin.github.io/samples/paymentrequest/credit-cards/
>> - a
>> > sample that accepts credit card payments and does not request shipping
>> > information.
>> >
>> > 📬 https://rsolomakhin.github.io/samples/paymentrequest/free-shipping/
>> - a
>> > sample that accepts credit card payments and provides free shipping
>> > worldwide.
>> >
>> > 📬 📬
>> https://rsolomakhin.github.io/samples/paymentrequest/shipping-options/
>> > - a sample that accepts credit card payments and provides a couple of
>> > shipping options regardless of shipping address.
>> >
>> > <https://rsolomakhin.github.io/samples/paymentrequest/dynamic-shipping/
>> >
>> > 🏰 🗽
>> https://rsolomakhin.github.io/samples/paymentrequest/dynamic-shipping/
>> > - a sample that accepts credit card payments and varies the availability
>> > and price of shipping options depending on the shipping address.
>> > ...
>> >
>> > 👷 You can try these samples in Chrome Dev for Android:
>> > https://play.google.com/store/apps/details?id=com.chrome.dev
>> >
>> > 🇧🇷 Remember to enable the Chrome flag:
>> > chrome://flags/#enable-experimental-web-platform-features
>>
>> It is great to see this becoming real.
>>
>> Some comments I have that are outside the scope of the spec itself because
>> it’s about implementation-specific UI (but that I think are relevant for
>> other implementors putting together UI around this):
>>
>> ## Show all available payment methods in the UI at the same, on equal
>> footing
>>
>> I think the UI should not only show the one payment method that the
>> browser
>> (based on internal heuristics I guess) decides on its own should be the
>> default displayed, and bury the rest of payment-method choices in a select
>> menu or other UI that requires the user manually activate a disclosure
>> triangle or other UI widget to see what payment methods they can use.
>>
>> ## Users use different payment methods depending on which merchant they
>> use
>>
>> I think one problem with trying to choose only one default payment method
>> to show in the UI at one time is that a lot of users use different payment
>> methods depending on which merchant site they happen to be buying from. So
>> showing those users only one default is likely to be really annoying to
>> them.
>>
>> ## Suggestion: Always show all available usable payment methods in the UI
>>
>> So I think the right/optimal UI here from a user POV is to always show the
>> user all the available usable payment methods (the intersection of the
>> payment methods the merchant supports, and those the user has).
>>
>> I think that means practically the UI needs to show just the icons/logos
>> for each payment method, maybe with some minimal text (e.g., for credit-
>> cards the last 4 digits), in some kind of arrangement that fits as well as
>> it can into the limited screen real estate (e.g., the icons in rows and
>> columns)—but if they don’t all fit, it is more acceptable from a UX POV
>> for
>> the user to need to scroll a bit to see them all than it is to by default
>> suppress all of them except one and force the user to always manually
>> activate some UI widget just be able to see more than one.
>>
>> I’m not a UI designer and I realize you’re not either and you did not
>> design the UI here, but my comments are not intended to be just about this
>> particular implementation but instead that across all implementations I
>> think it is important that when users go to a particular merchant site, it
>> is very important for users to be able to very quickly and easily see all
>> the payments they can use with that merchant.
>>
>> I think otherwise the UI is actually getting in the way of the user
>> instead of helping them, and not giving the best user experience.
>>
>> And although this is a spec for a programmatic API and not for a UI, I
>> think the considerations around the UI here are highly relevant in the
>> particular case of this API, because the highest-priority goal for this
>> spec is to streamline the checkout user-experience for users, and getting
>> the UI right across implementations is essential to that.
>>
>>   —Mike
>>
>> --
>> Michael[tm] Smith https://people.w3.org/mike
>>
>

Received on Friday, 27 May 2016 13:58:04 UTC