We walked through the changes since the previous call.
We review the user experience topics of the SRC wiki.
Jonathan: The reason that I
thought it was interesting to have this discussion is that, of
course there are different use cases (e.g., default payment
handler)
... or a default handler provided by another topic
... or multiple payment handlers to select from
... so I want to get a clearer vision of the user
experience
... as a user, when I click the button I want to see my
card.
... I may need to enter my identity, for example.
... so seeking consistency across platforms
<Zakim> rouslan, you wanted to talk about the clicks.
rouslan: I can speak about what
Chrome is currently doing
... works on desktop, android, and IOS.
... different browser vendors might have different experiences
for their own reasons
... chrome team definitely wants to reduce clicks.
... a wallet selector should not be shown if there is a single
wallet. But even if there are multiple wallets but the browser
is configurable to go to a given wallet, agree user should go
to handler to see cards
... one approach that is technically supported by the API is to
pull in instrument-level information registered by the payment
handler and showing it in the sheet
... it's possible to implement that, but that is a lower
priority for chrome than other topics for us
... higher priorities for us:
* Access to a default payment handler for non-url based payment methods
scribe: so, e.g., for 'src' or
'basic-card', the browser could offer the user to install (just
in time) a payment handler
... from our experience, users don't car about service workers
and payment handlers. :)
... the user wants to click the button and see cards
Jonathan: I wanted to clarify meaning of "default payment handler" ... how do you know there will be one available for usage with SRC?
Rouslan: The browser would have a URL to a web-based payment handler that the browser knows about
IJ: Is it an important detail where it's hosted?
Jonathan: Somebody has do develop handler...what if no third party handler is developed?
Rouslan: Our experience from Basic Card is that Chrome would prefer third-party payment handler
Jonathan: What about when there are multiple payment handlers?
Rouslan: If there are multiple
handlers installed at the same time, it's up to UX and product
decisions. E.g., during on boarding chrome would ask the user
whether they want to use that wallet again
... and then the next time that wallet is immediately launched,
and user would have to visit settings to change default
wallet.
... so the user would see the cards of one wallet..and user
would be able to get other wallets through settings
======
If you have N wallets, you see N wallets in the sheet
scribe: will the sheet display the instruments in those wallets?
(the spec supports that, but nobody implements)
scribe: or you see zero selector and straight to the user-selected default wallet where you see instruments
Jonathan: The first reflex of the user is to see a card and click on it
<Zakim> rouslan, you wanted to ask Jonathan for more reasoning on why the instruments in the sheet are important.
rouslan: I want to ensure that
the spec allows for the UX that you want, but we won't be able
to enforce specific UX across browsers
... Jonathan, could you say more about rationale for
instruments in the sheet?
Jonathan: Remove a click in the
process.
... having an aggregated list in the sheet should speed up
checkout
Rouslan: In current
implementation of the sheet in chrome, the sheet initially
shows your topmost used card.
... you'd have to tap on that to reveal the full list of
cards.
... this seems different from your description of the full list
of cards.
Jonathan: That's ok; but I want to see all the cards when I move past the default
Rouslan: Do you envision multiple wallets for SRC payments?
Jonathan: I just want to cover
the potential use cases
... SRC discussions follow years of discussions about wallet
selection and friction
IJ: I am hearing Chrome UX ok as long as other instruments shown in the view of cards
<Zakim> rouslan, you wanted to ask about merging cards from multiple payment handlers into the same list.
rouslan: One use case (possibly
edge) I'd like to consider - merging payment instrument from
multiple handlers in a single list
... what considerations have gone into ordering,
deduplication
Jonathan: even if edge case, good
to consider.
... I think it's fine to display the origin of the payment
handler
... at least that was my reflex some time ago
Tomasz: The spec supports that. Plus there's a hint field.
IJ: We used to have a userHint in the payment handler API
Rouslan: Browser still has that information
Jonathan: I think displaying source of info should be ok
Tomasz: You may also find you have basic card in parallel with SRC
Lawrence: Let's say I'm at home on desktop ... the desktop is shared by family members ... suppose my girlfriend and I both have amazon pay wallets...what would be displayed?
Rouslan: Whoever is logged in to Amazon would see their cards.
Jonathan: Doesn't it relate to the identification of the user?
Lawrence: In this scenario each user has a different user id
[On parallel logins]
Rouslan: Up to the web site to
clear and refresh cookies.
... whether two people can be logged into an origin at the same
time is up to the site.
... e.g., gmail will allow parallel identities
<benoit> I have never been able to do that without incognito or a different "person" in chrome
IJ: I am guessing 1 payment handler per origin (e.g., amazon) and up to the payment handler to show 1 or more identities
Rouslan: +1
Tomasz: On the other hand, it
could be a requirement to allow the browser to provision
selected identity to the payment handler
... provided payment handler can trust identity provided by the
browser
IJ: Might not be inherent in payment handler but a different API
Jonathan: Let's list options for how a payment handler could get identity from the browser
<Zakim> rouslan, you wanted to ask what would be other useful features in payment handler API other than showing instruments in the sheet?
Rouslan: What features do you need from browser to build the src payment handler to get the experience you want?
Jonathan: List of payment
instruments is one of them.
... Add - can the browser facilitate the authentication of the
cardholder and also 3ds flow?
Lawrence: Back to my scenario - if my girlfriend is logged into site, but I am logged into Amazon Pay (the payment handler), what happens?
IJ: Does browser handle site space and payment handler space as one?
Rouslan: Site has power to do different things (depending on origin scope)
IJ: Seems like we should raise awareness of mismatch possibility in the PH API
https://github.com/w3c/payment-handler/issues/
<scribe> ACTION: Lawrence to raise the issue on payment handlers about merchant/handler origin split
<trackbot> Created ACTION-122 - Raise the issue on payment handlers about merchant/handler origin split [on Lawrence Cheng - due 2019-07-03].
stpeter: I think that the same
site controlling both site and handler is an edge case.
... but the broader case is something like a kiosk mode...my
wife and I use the same computer. we both have instruments. how
does the computer know which ones to invoke?
Jonathan: If there are two
different identities, then typically when I click on "buy" I
see my identity..and I can change identity.
... I think we should bind list of cards to one identity.
IJ: Question of profiles is here specific to google
Lawrence: We have three identities - identity at the merchant, identity known to the browser, identity known to the payment handler. We need to look at all the scenarios.
Tomasz: Speaking from the SRC
perspective we had similar discussions
... from API perspective we have support for all those use
cases we've discussed:
* Anonymous storage of cards
(You are using chrome, not logged into google but can use basic card)
* Single consumer identity bound to a list of cards
stpeter: clarifying question - I
heard what Jonathan said as focused on the UX initially
... are there security considerations as well?
... e.g., I've done device binding in an SRC context and that
card is registered into a DCF
... is there also a need beyond that device binding to know
this is the particular person who is authorized to use the
card
... or is this the UX
Jonathan: Very good question. I like the idea that we split the identification and the authentication.
<tomasz> +1
* Identification is "can I show this list of cards to this user"?
* Authentication is "prove you are an authorized card holder"
Jonathan: I think it's an
implementation decision whether to keep showing the list when
the user comes back
... but during the transaction you may expect the cardholder to
be authenticated.
IJ: To me those are the same: you authenticate once but read access is low risk. Write access is risky, so you authenticate.
Tomasz: Auth each time you access wallet affects UX greatly
10 July