Skip to content

Commit 9dce038

Browse files
Introduce UX guidelines documentation
See #309
1 parent 21f92dd commit 9dce038

File tree

3 files changed

+178
-0
lines changed

3 files changed

+178
-0
lines changed
96.5 KB
Loading
99.7 KB
Loading

ux-guidelines.md

Lines changed: 178 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,178 @@
1+
# Secure Payment Confirmation: Non-normative UX Guidelines
2+
3+
Status: This is a **draft** document without consensus.
4+
5+
A key step of the user journey for Secure Payment Confirmation (SPC) is the
6+
display of and user interaction with the [transaction confirmation UX]. This
7+
step communicates information from the caller of SPC (e.g., a merchant website,
8+
perhaps on behalf of a payment service provider or issuing bank) to the user,
9+
for the user to verify and ultimately sign via WebAuthn.
10+
11+
While web specifications do not generally make recommendations about how User
12+
Agents implement UX, it can be useful for both integrators of SPC (e.g.,
13+
financial organizations) and implementors of SPC (i.e., User Agents) to have
14+
some general guidelines about the information that can be provided and will be
15+
shown. This file aims to document those guidelines, based on implementor
16+
experience and payment industry feedback.
17+
18+
## Information presented in the transaction confirmation UX
19+
20+
### Payee information
21+
22+
Relevant fields: [payeeName], [payeeOrigin]
23+
24+
The payee information fields are intended to communicate to the user who will
25+
be the recipient of the funds. In most cases this would be the merchant (or
26+
other entity) that the user has already been interacting with in the current
27+
session. The `payeeName` field, if present, communicates a natural language
28+
name, such as "Big Shoe Store Inc.", whilst the `payeeOrigin`, if present,
29+
communicates the web URL at which the payee can be found, such as
30+
"https://bigshoestore.example".
31+
32+
The specification allows for either one or both of the fields to be present.
33+
Implementors may display them separately, or may combine them into a single
34+
visual block such as `payeeName (payeeOrigin)`, for example "Big Shoe Store
35+
Inc. (https://bigshoestore.example)".
36+
37+
Note: An implementor may truncate these fields in order to fit the text into
38+
the available UX space. See issue #269 for discussions on setting normative
39+
length limits on fields including payeeName and payeeOrigin.
40+
41+
### Payment instrument information
42+
43+
Relevant fields: [instrument.displayName], [instrument.icon], [instrument.details]
44+
45+
The payment instrument information fields are intended to communicate to the
46+
user which payment instrument will be charged. Common payment instruments
47+
include payment cards (credit, debit, or other), bank accounts, and a number of
48+
country-specific payment methods (e.g., UPI, PIX, GiroPay, etc). SPC has no
49+
requirement or limitation on the type of payment instrument being used or
50+
displayed.
51+
52+
The `displayName` and `details` fields are used to convey textual information
53+
about the payment instrument. As the names suggest, `displayName` should be set
54+
to the primary name for the payment instrument, while `details` can be used to
55+
add additional clarifying details to help the user differentiate or make
56+
decisions. For example, for a credit card payment instrument, `displayName`
57+
may be set to the product name for the card (e.g., "FancyBank Infinity Card"),
58+
whilst details might include the last four digits of the card and/or expiry
59+
date (e.g., "1234 01/32).
60+
61+
Note: An implementor may truncate the `displayName` and `details` fields in
62+
order to fit the text into the available UX space. See issue #269 for
63+
discussions on setting normative length limits on fields including payeeName
64+
and payeeOrigin.
65+
66+
The `icon` field is set to the URL of an image representing the payment
67+
instrument. Implementors are expected to support common image formats such as
68+
PNG or JPG. The payment instrument icon image is intended to be a quick visual
69+
confirmation for the user, and is expected to be displayed fairly small.
70+
71+
Implementation specifics:
72+
73+
- Google Chrome's (and other Chromium-based browsers) implementation on both
74+
desktop and mobile platforms currently linearly scales the image (preserving
75+
the input aspect ratio) to fit in a 32dp x 20dp region, e.g. the display
76+
region has an aspect ratio of 1.6:1.
77+
- Given current average screen densities, we would recommend that
78+
integrators pass in a logo with physical pixel size at least 3x of that,
79+
e.g. minimal 96px by 60px.
80+
- The Chrome team have stated that they are interested in hearing from
81+
partners if a 32dp x 20dp region is too small, as it may not allow for
82+
detailed icons (such as full card art for credit cards).
83+
84+
### Payment entity logos
85+
86+
Relevant fields: [paymentEntitiesLogos], [paymentEntitiesLogos\[x\].url], [paymentEntitiesLogos\[x\].label]a
87+
88+
The payment entity logos are intended to communicate to the user the identity
89+
of payment companies or organizations that are involved in the current
90+
transaction, who might otherwise not be clear to the user. Examples include the
91+
issuing bank and/or a card network in the case of credit/debit card payments,
92+
the user's bank and a payment initiation services provider (PISP) in Open
93+
Banking, etc.
94+
95+
The payment entity logos are expected to be displayed prominently within the
96+
SPC transaction confirmation UX, but should not significantly overweight the
97+
other information shown. Implementors are able to support any number of logos
98+
passed within `paymentEntityLogos`, and may ignore 'extra' logos beyond what
99+
they support displaying, but it is recommended that they support up to two
100+
logos being shown.
101+
102+
Each payment entity logo has two fields.
103+
104+
The `label` field is used to convey a textual description of the payment entity
105+
to the user. This field may be displayed by the implementor, or it may be used
106+
only for accessibility purposes (e.g., for a screen reader to describe the
107+
logo). It is recommended that this text be short but descriptive to the user,
108+
e.g. "FancyBank logo".
109+
110+
The `url` field is set to the URL of a payment entity logo image. Implementors
111+
are expected to support common image formats such as PNG or JPG. Logos should
112+
generally be "wordmark" or combination logos, which often display more clearly
113+
to users than 'simple' square logos. Logos should also have transparent
114+
backgrounds, to allow them to be layered seamlessly onto implementor UX.
115+
116+
Implementation specifics:
117+
118+
- Google Chrome's (and other Chromium-based browsers) implementation currently
119+
supports 0-2 payment entity logos, inclusive. If more than two logos are
120+
provided, Chrome currently discards the third logo onwards. Logos are placed
121+
at the top of the SPC dialog.
122+
- For `label`; Chrome currently does not display this value, but does use
123+
it as the accessibility text for the logo.
124+
- For `url` (i.e., the logo itself), Chrome's implementation currently
125+
linearly scales the image (preserving the input aspect ratio) to fit in a
126+
104dp x 24dp region on mobile and a planned 188dp x 43dp on desktop, e.g.
127+
the display region has an aspect ratio of 4.333:1.
128+
- We recommend treating this as the upper-bound for aspect-ratio;
129+
images that have to be scaled to fit the height look better than
130+
images that have to be scaled to fit the width.
131+
- Given current average screen densities, we recommend that integrators
132+
pass in a logo with at least pixel size 3x of the device-pixel sizes
133+
mentioned above. For example, an image with ideal aspect ratio of
134+
4.333:1 should be at least 563px x 130px. If the image instead was
135+
narrower with an aspect ratio of 2.7:1, it should be at least
136+
350px x 130px.
137+
138+
### Transaction amount
139+
140+
Relevant fields: [details.total.amount.currency], [details.total.amount.value]
141+
142+
The transaction amount fields are intended to communicate to the user the value
143+
of the purchase that they are verifying. This should be the full value,
144+
inclusive of any shipping, taxes, etc. - such that it should match the value
145+
that the user later observes charged against their payment instrument.
146+
147+
Note: The transaction amount is communicated via the top-level [Payment
148+
Request](https://w3c.github.io/payment-request) API call, instead of as part of
149+
the SPC method itself.
150+
151+
## UX differences across different screen sizes/layouts
152+
153+
## Appendix: Example transaction confirmation UX screens
154+
155+
This appendix contains some example transaction confirmation UX screens from
156+
implementors. Where possible, fake entity logos are used, but any other images
157+
or trademarks are used without permission and without intending to imply any
158+
support and/or usage of SPC by those entities.
159+
160+
**Google Chrome on Android, with "wordmark"/combination payment entity logos**:
161+
162+
![Screenshot of the transaction confirmation UX for SPC in Google Chrome for Android. The transaction UX shows two wordmark logos for "Moon Bank" and "Chillipay", followed by the text "Verify its you". Below, the transaction details show that the payee is "The Design Store" at designstore.com, the payment instrument is a "Chase Freedom Flex Card" with last-four digits 1234, and the amount is $120 USD.](/images/ux-guidelines-google-chrome-android.png)
163+
164+
**Google Chrome on Android, with square payment entity logos**:
165+
166+
![Screenshot of the transaction confirmation UX for SPC in Google Chrome for Android. The image is identical to the one proceeding it, but has square logos for "Moon Bank" and "Chillipay" which are much harder to read.](/images/ux-guidelines-google-chrome-android-square-logos.png)
167+
168+
[details.total.amount.currency]: https://w3c.github.io/payment-request/#dom-paymentcurrencyamount-currency
169+
[details.total.amount.value]: https://w3c.github.io/payment-request/#dom-paymentcurrencyamount-value
170+
[instrument.details]: https://w3c.github.io/secure-payment-confirmation/#dom-paymentcredentialinstrument-details
171+
[instrument.displayName]:https://w3c.github.io/secure-payment-confirmation/#dom-paymentcredentialinstrument-displayname
172+
[instrument.icon]: https://w3c.github.io/secure-payment-confirmation/#dom-paymentcredentialinstrument-icon
173+
[payeeName]: https://w3c.github.io/secure-payment-confirmation/#dom-securepaymentconfirmationrequest-payeename
174+
[payeeOrigin]: https://w3c.github.io/secure-payment-confirmation/#dom-securepaymentconfirmationrequest-payeeorigin
175+
[paymentEntitiesLogos]: https://w3c.github.io/secure-payment-confirmation/#dom-securepaymentconfirmationrequest-paymententitieslogos
176+
[paymentEntitiesLogos\[x\].label]: https://w3c.github.io/secure-payment-confirmation/#dom-paymententitylogo-label
177+
[paymentEntitiesLogos\[x\].url]: https://w3c.github.io/secure-payment-confirmation/#dom-paymententitylogo-url
178+
[transaction confirmation UX]: https://w3c.github.io/secure-payment-confirmation/#sctn-transaction-confirmation-ux

0 commit comments

Comments
 (0)