W3C home > Mailing lists > Public > public-payments-wg@w3.org > July 2018

Re: [w3c/webpayments] Visual Identity for Web Payments (#250)

From: Marcos Cáceres <notifications@github.com>
Date: Mon, 16 Jul 2018 13:03:28 -0700
To: w3c/webpayments <webpayments@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <w3c/webpayments/issues/250/405364182@github.com>
Cc’ing Mozilla folks that are interested in being part of the discussion: @sharonbautista, @e-pang, @jeanygong, and @chsiang. 

>From Mozilla’s perspective, there are essentially 3 options for the working group that we would like to discuss: 

1. **Do nothing:** encourage merchants to show the credit card network icons to stand for “basic card” payments. Allow merchants to rely on granular `canMakePayment()` to detect what payment handlers are installed (e.g., to detect “Basic Card”, “Apple Pay”, “Android Pay”, etc.) - and allow display of those specific icons. 
2. **Create a “Web Payment” icon**: when pressed, presents the payment handler options: Basic-Card, and whatever else may be installed. 
3. **Create browser-specific icon:** like Apple Pay does via CSS -  so could be, “Pay with Firefox”, “Pay with Chrome”, etc  for “Basic Card”.

Each has their pros and cons - and happy to discuss those in detail. 

### If we choose options 1 or 2, what should the icon do?
**User:** know what to expect when they activate the button. It should be accessible. 
**Merchant:** can distinguish web payments from their standard flow and put it places that make the most sense to their business.

User agent and merchant should be able to customize to a degree so only the meaningful UI is displayed. Additionally, the button should be responsive/adaptive to layout.

An example would be social buttons – users know what to expect after clicking the button, websites choose the placement and design that makes the most sense, and they’re not overwhelming.  

There might need to be a lot of educating users if we create a new button. 

### What should it NOT do?
 * Make assumptions about the available space in which it will be displayed.
 * Display confusing and irrelevant information

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Received on Monday, 16 July 2018 20:03:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:29 UTC