|
| 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 | + |
| 163 | + |
| 164 | +**Google Chrome on Android, with square payment entity logos**: |
| 165 | + |
| 166 | + |
| 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