-
Notifications
You must be signed in to change notification settings - Fork 49
Introduce UX guidelines documentation #311
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
e0be04f
cf6070d
e5d443e
913d318
9338ca4
22463f4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,179 @@ | ||
# Secure Payment Confirmation: Non-normative UX Guidelines | ||
|
||
Status: This is a **draft** document without consensus. | ||
|
||
A key step of the user journey for Secure Payment Confirmation (SPC) is the | ||
display of and user interaction with the [transaction confirmation UX]. This | ||
step communicates information from the caller of SPC (e.g., a merchant website, | ||
perhaps on behalf of a payment service provider or issuing bank) to the user, | ||
for the user to verify and ultimately authenticate via WebAuthn. | ||
|
||
While web specifications do not generally make recommendations about how User | ||
Agents implement UX, both integrators of SPC (e.g., financial organizations) | ||
and implementors of SPC (i.e., User Agents) have requested general guidance | ||
about what information can be provided to the API and how it is likely to be | ||
displayed to the user. The non-normative guidance in this document is based on | ||
implementor experience and payment industry feedback. | ||
|
||
## Information presented in the transaction confirmation UX | ||
|
||
### Payee information | ||
|
||
Relevant fields: [payeeName], [payeeOrigin] | ||
|
||
The payee information fields are intended to communicate to the user which | ||
entity will be the recipient of the funds. In most cases this would be the | ||
merchant (or other entity) that the user has already been interacting with in | ||
the current session (e.g., checkout flow). The `payeeName` field, if present, | ||
communicates a natural language name, such as "Big Shoe Store Inc.", whilst the | ||
`payeeOrigin`, if present, communicates the web URL at which the payee can be | ||
found, such as "https://bigshoestore.example". | ||
|
||
The specification allows for either one or both of the fields to be present. | ||
Implementors may display them separately, or may combine them into a single | ||
visual block such as `payeeName (payeeOrigin)`, for example "Big Shoe Store | ||
Inc. (https://bigshoestore.example)". | ||
|
||
Note: An implementor may truncate these fields in order to fit the text into | ||
the available UX space. See [issue | ||
#269](https://github.com/w3c/secure-payment-confirmation/issues/269) for | ||
discussions on setting normative length limits on fields. | ||
|
||
### Payment instrument information | ||
|
||
Relevant fields: [instrument.displayName], [instrument.icon], [instrument.details] | ||
|
||
The payment instrument information fields are intended to communicate to the | ||
user which payment instrument will be charged. Common payment instruments | ||
ianbjacobs marked this conversation as resolved.
Show resolved
Hide resolved
|
||
include payment cards (credit, debit, or other), bank accounts, and a number of | ||
country-specific payment methods (e.g., UPI, PIX, GiroPay, etc). SPC has no | ||
requirement or limitation on the type of payment instrument being used or | ||
displayed. | ||
|
||
The `displayName` and `details` fields are used to convey textual information | ||
about the payment instrument. As the names suggest, `displayName` should be set | ||
to the primary name for the payment instrument, while `details` can be used to | ||
add additional clarifying details to help the user differentiate or make | ||
decisions. For example, for a credit card payment instrument, `displayName` | ||
may be set to the product name for the card (e.g., "FancyBank Infinity Card"), | ||
whilst details might include the last four digits of the card and/or expiry | ||
date (e.g., "1234 01/32"). | ||
|
||
Note: An implementor may truncate the `displayName` and `details` fields in | ||
order to fit the text into the available UX space. See [issue | ||
#269](https://github.com/w3c/secure-payment-confirmation/issues/269) for | ||
discussions on setting normative length limits on fields. | ||
|
||
The `icon` field is set to the URL of an image representing the payment | ||
instrument. Implementors are expected to support common image formats such as | ||
PNG or JPG. The payment instrument icon image is intended to be a quick visual | ||
confirmation for the user, and is expected to be somewhat small on the screen. | ||
|
||
Implementation specifics: | ||
|
||
- Google Chrome's (and other Chromium-based browsers) implementation on both | ||
desktop and mobile platforms currently linearly scales the image (preserving | ||
the input aspect ratio) to fit in a 32dp x 20dp region, i.e., 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, | ||
i.e., at least 96px by 60px. | ||
- The Chrome team have stated that they are interested in hearing from | ||
partners if a 32dp x 20dp region is too small, as it may not allow for | ||
detailed icons (such as full card art for credit cards). | ||
|
||
### Payment entity logos | ||
|
||
Relevant fields: [paymentEntitiesLogos], [paymentEntitiesLogos\[x\].url], [paymentEntitiesLogos\[x\].label] | ||
|
||
The payment entity logos are intended to communicate to the user which payment | ||
companies or organizations are involved in the current transaction. This is | ||
especially helpful if the identities of these parties would not otherwise be | ||
obvious to the user. Examples include the issuing bank and/or a card network in | ||
the case of credit/debit card payments, the user's bank and a payment | ||
initiation services provider (PISP) in Open Banking, etc. | ||
|
||
The payment entity logos are expected to be displayed prominently within the | ||
SPC transaction confirmation UX, but should not significantly overshadow the | ||
other information shown. Implementors are able to support any number of logos | ||
passed within `paymentEntityLogos`, and may ignore extra logos beyond what | ||
they support displaying, but it is recommended that they support up to two | ||
logos being shown. | ||
Comment on lines
+99
to
+101
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. question: does this mean the UserAgent actually does not have to implement this part of the spec at all, and could just drop all entity data? Although we do not need to dictate how they do it, I am opinionated that this privacy context is important and we should demand a minimum bar be met. This is also conflicting with the information presented in the current spec: There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Currently by spec the user agent can drop all of the payment entity logos if it wanted, yes. See step 3 of https://w3c.github.io/secure-payment-confirmation/#sctn-steps-to-check-if-a-payment-can-be-made We made that choice to avoid restricting User Agent UX and because we foresaw browser implementors not always being happy to show logos from other entities. However I could see an argument that this is a core feature of SPC and so perhaps like you say here and below, we should change SPC to require a User Agent support at least N={0, 1, 2} logos. Wdyt @pejic and @ianbjacobs ? Note that the relying party will know which logos are shown (or not), because only the shown logos are included in the output cryptogram. So when verifying the cryptogram you know if the user saw the logos before signing. However that is post-call, of course. |
||
|
||
Each payment entity logo has two fields. | ||
|
||
The `label` field is used to convey a textual description of the payment entity | ||
to the user. This field may be displayed by the implementor, or it may be used | ||
only for accessibility purposes (e.g., for a screen reader to describe the | ||
logo). It is recommended that this text be short but descriptive to the user, | ||
e.g., "FancyBank logo". | ||
|
||
The `url` field is set to the URL of a payment entity logo image. Implementors | ||
are expected to support common image formats such as PNG or JPG. Logos should | ||
generally be "wordmark" or combination logos, which often display more clearly | ||
to users than square logos. Logos should also have transparent backgrounds, to | ||
allow them to be layered seamlessly onto implementor UX. | ||
|
||
Implementation specifics: | ||
|
||
- Google Chrome's (and other Chromium-based browsers) implementation currently | ||
supports zero, one, or two payment entity logos. If more than two logos are | ||
provided, Chrome currently discards the third logo onwards. Logos are placed | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. comment: I think silently ignoring context and proceeding is reasonable. As a counterpoint, I could also see this being a privacy concern, where partners this sensitive payment data is being shared with are not represented in the experience unbeknownst to the caller. It could be beneficial for this to fail in a noisy way and push the responsibility onto clients to understand early what the User Agent supports and give them the ability to compensate for this with alternative UX if needed, assuming we continue to have no strict requirement on number of entities supported in the API. On this topic, the easiest way to do this would be to just set an explicit number that should be met by all User Agents implementing. I.E. [0, 1, 2] is what all parties must support, and don't offer 3+ if it doesn't make sense for any User Agent to really implement that (I imagine if the chrome team didn't feel good implementing 3+, no other User Agent will). Maybe this is context you've already discussed and I am just behind 😄 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Consolidating this discussion into the other comment: https://github.com/w3c/secure-payment-confirmation/pull/311/files#r2307301608 |
||
at the top of the SPC dialog. | ||
- For `label`; Chrome currently does not display this value, but does use | ||
it as the accessibility text for the logo. | ||
- For `url` (i.e., the logo 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, i.e., | ||
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. | ||
|
||
### Transaction amount | ||
|
||
Relevant fields: [details.total.amount.currency], [details.total.amount.value] | ||
|
||
The transaction amount fields are intended to communicate to the user the value | ||
ianbjacobs marked this conversation as resolved.
Show resolved
Hide resolved
|
||
of the purchase that they are verifying. This should be the full value, | ||
inclusive of any shipping, taxes, etc. - such that it should match the value | ||
that the user later observes charged against their payment instrument. | ||
|
||
Note: The transaction amount is communicated via the top-level [Payment | ||
Request](https://w3c.github.io/payment-request) API call, instead of as part of | ||
the SPC method itself. | ||
|
||
## UX differences across different screen sizes/layouts | ||
|
||
## Appendix: Example transaction confirmation UX screens | ||
|
||
This appendix contains some example transaction confirmation UX screens from | ||
implementors. Where possible, fake entity logos are used, but any other images | ||
or trademarks are used without permission and without intending to imply any | ||
support and/or usage of SPC by those entities. | ||
|
||
**Google Chrome on Android, with "wordmark"/combination payment entity logos**: | ||
|
||
 | ||
|
||
**Google Chrome on Android, with square payment entity logos**: | ||
|
||
 | ||
|
||
[details.total.amount.currency]: https://w3c.github.io/payment-request/#dom-paymentcurrencyamount-currency | ||
[details.total.amount.value]: https://w3c.github.io/payment-request/#dom-paymentcurrencyamount-value | ||
[instrument.details]: https://w3c.github.io/secure-payment-confirmation/#dom-paymentcredentialinstrument-details | ||
[instrument.displayName]:https://w3c.github.io/secure-payment-confirmation/#dom-paymentcredentialinstrument-displayname | ||
[instrument.icon]: https://w3c.github.io/secure-payment-confirmation/#dom-paymentcredentialinstrument-icon | ||
[payeeName]: https://w3c.github.io/secure-payment-confirmation/#dom-securepaymentconfirmationrequest-payeename | ||
[payeeOrigin]: https://w3c.github.io/secure-payment-confirmation/#dom-securepaymentconfirmationrequest-payeeorigin | ||
[paymentEntitiesLogos]: https://w3c.github.io/secure-payment-confirmation/#dom-securepaymentconfirmationrequest-paymententitieslogos | ||
[paymentEntitiesLogos\[x\].label]: https://w3c.github.io/secure-payment-confirmation/#dom-paymententitylogo-label | ||
[paymentEntitiesLogos\[x\].url]: https://w3c.github.io/secure-payment-confirmation/#dom-paymententitylogo-url | ||
[transaction confirmation UX]: https://w3c.github.io/secure-payment-confirmation/#sctn-transaction-confirmation-ux |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: is this important context for the audience reading this, or just us? Might be possible to compact this down to a single sentence like:
While web specifications do not generally make recommendations about how User Agents implement UX, we wanted to offer general guidance about how the API's information will likely be displayed to the user.
or just remove it entirely.Feel free to ignore my nits if you are confidant 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's a great point - wdyt @ianbjacobs ?