Non-normative UX guidelines for implementors and integrators

[stephenmcgruer]

We've touched on this from time to time, but as more partners investigate SPC as a potential solution for payment authentication, it would likely be useful for the Working Group to develop some guidelines/best practices for SPC UX and UX-related data members. This would of course be non-normative as the specification cannot restrict implementations, but we believe it could be useful for other implementors as well to know what is being done in practice.

Potential topics to consider for the guidelines:

• SecurePaymentConfirmationRequest
  • payeeName - probably not much required here, maybe max/min length? (see also Limitations for showing transaction data #269 for adding normative requirements on that)
  • payeeOrigin - we could give recommendations on how the combination of either-or-both of payeeName and payeeOrigin are rendered.
  • paymentEntitiesLogos - recommended min/max number of logos, where/how they should be displayed on the transaction sheet, examples on what are considered "payment entity" in various payment systems, etc
• PaymentCredentialInstrument
  • displayName - examples on what might be considered a "displayName" across different payment instrument types (see also Limitations for showing transaction data #269 for adding normative requirements on max/min-length)
  • icon - recommended aspect ratio, minimum resolution, how detailed instrument icons should/shouldn't be, etc. Probably based around a concept of 'what is this for'.
  • details - examples on which might be considered "details" across different payment instrument types (see also Limitations for showing transaction data #269 for adding normative requirements on max/min-length)
• PaymentEntityLogo
  • url - recommended aspect ratio, minimum resolution, how detailed payment entity logos should/shouldn't be, etc.
  • label - recommended content for accessibility users
• PaymentCurrencyAmount (total) - may already be sufficiently documented by the struct already, but we could repeat or make clear the recommended way to display this?

Some of these (particularly icons) might want to be specified across different screen sizes, e.g. one for mobile layouts, one for desktop.

We (Google Chrome) intend to follow up 'soon' (tbd, a few days?) with some initial recommendations of our own based on our implementation, but are interested to discuss the in the WG!

[stephenmcgruer]

Hey folks,

Following up on my initial post with some thoughts from ourselves. These are largely drawn from our own current implementation and experience, and we are looking to hear input from others on how well they do or don't map to your expectations/requirements. They are not meant to be a final say, but hopefully can act as a starting point for discussion.

SecurePaymentConfirmationRequest fields

Payee Information

Fields: payeeName, payeeOrigin

No strong guidance here yet. Currently Chrome renders the information in one of the three following ways, depending on which fields were provided:

• payeeName (e.g., Merchant Shop)
• payeeOrigin (e.g., merchant.example)
• payeeName (payeeOrigin) (e.g., Merchant Shop (merchant.example))

Chrome will truncate these strings to fit in available screen space, but we do not currently have specific length restrictions, nor do we do anything 'smart' about truncating them (for example, in the payeeName+payeeOrigin case, we create the full string first and then truncate it, rather than e.g. specifically truncating the name to fit in the origin or vice versa).

See also issue #269 for the discussion on setting normative limits.

Payment instrument information

Fields: displayName, icon, details

No strong guidance on displayName or details yet, other than generally that displayName should be standalone (recognizable without any other content) while details can rely on the context of displayName. Chrome's implementation will show the two fields stacked vertically, with displayName above details. If details is not present, only displayName will be shown (aligned with the icon).

For icon, Chrome's implementations on both desktop and mobile platforms currently linearly scales the image (preserving the input aspect ratio) to fit in a 32dp x 20dp region, e.g. the display region has an aspect ratio of 1.6:1 . Given current average screen densities, we would recommend that integrators pass in a logo with physical pixel size at least 3x of that, e.g. minimal 96px by 60px.

Note: We are aware that modern payment instrument icons are often full card art, and that for such cases 32dp x 20dp may not be enough space. We are actively exploring whether this should be a larger space, and are interested in your input!

Payment entity logos

Fields: PaymentEntityLogo.url, PaymentEntityLogo.label

Chrome currently supports showing 0-2 logos, inclusive. Logos are placed at the top of the SPC dialog, and are sized to be visible and prominent but deliberately not to be significantly overweighted (e.g., they are slightly less tall than the title text that is below them). If only one logo is shown (or only one of two logos can be downloaded) then it is shown centered alone at the top, otherwise two logos are shown side by side with a divider between them, centered around the divider. If more than two logos are provided, Chrome currently discards the third logo onwards.

For label; Chrome currently does not display this value, but does use it as the accessibility text for the logo. It is recommended that this text be short but descriptive to the user, e.g. "EntityName logo".

For url (i.e., the icon itself), Chrome's implementation currently linearly scales the image (preserving the input aspect ratio) to fit in a 104dp x 24dp region on mobile and a planned 188dp x 43dp on desktop, e.g. the display region has an aspect ratio of 4.333:1. We recommend treating this as the upper-bound for aspect-ratio; images that have to be scaled to fit the height look better than images that have to be scaled to fit the width.

Given current average screen densities, we recommend that integrators pass in a logo with at least pixel size 3x of the device-pixel sizes mentioned above. For example, an image with ideal aspect ratio of 4.333:1 should be at least 563px x 130px. If the image instead was narrower with an aspect ratio of 2.7:1, it should be at least 350px x 130px.

We have some recommendations in mind for payment entity logos:

• Logos should generally be "wordmark" or combination logos, as these are often more horizontally-rectangular and thus fit better into the SPC surfaces. Simple logo icons are often square and do not show up well in the dialog (they become very small).
• We strongly recommend that logos have transparent backgrounds.
• Avoid overly wide logos (i.e. aspect ratios above 4.333:1) as they will be vertically shrunk to fit.

Note: We are very interested to hear how well (or not) the space and aspect ratio currently defined here fits against logos for the payments ecosystem.

On mobile versus desktop

While mobile and desktop UXes operate under significantly different constraints, we prefer consistency between the two. Given that mobile is the more constrained space, we have designed around that and then plan to make desktop match the same decisions (e.g., same aspect ratio for icon regions).

[stephenmcgruer]

To help with visualization, here is an example of what we consider to be a 'good' use of logos for SPC, using horizontal wordmark/combo logos.

The two logos are mockups and any overlap with any actual entities is purely accidental and not deliberate.

[stephenmcgruer]

And an example of square combo logos that would render poorly: