<scribe> Scribe: Ian
Wiki on UX assumptions and requirements
https://github.com/w3c/src/wiki/UX-Assumptions-and-Requirements
[IJ reviews the wiki]
Tomasz: I have a few
comments
... why are we talking about BIN-to-SRC mapping?
... I think it's the job of the handler or the underlying
system to determine whether the card is enrolled into
IJ: Without BIN-to-SRC mappings publicly available, fewer parties can do the bootstrapping
Jalpesh: This mapping happens today. Some browsers start showing brand when you start typing card number.
IJ: Is that isomorphic to BIN-to-SRC
Jalpesh: Same or at worst "similar"
Tomasz: Today when user adds Basic Card to Chrome, what if user could add card to SRC system rather than SRC?
IJ: What is current chrome perspective on providing an entry point to SRC systems?
Rouslan: The current viewpoint is
that we are doing things for all payment handlers. I don't see
how this can be generalized.
... also heads-up that the Basic Card UI in Chrome is
considered to be a payment handler
... and Chrome's payment handler for Basic Card is "not the
best payment handler"
... instead we think that payment people should develop payment
handlers, not browser folks.
... in Chrome we want to delegate 100% of the interaction to
payment handlers
... if multiplexing is to happen, then, it should happen inside
the payment handler
... e.g, one payment handler can install other payment
handlers
[Requirements]
- User Must Have Path to Use a Card
- No Payment Handler / Wallet Selector
- User recognition with SRC systems
[IJ reviews previous "browser-based default payment handler]
David: Regarding typing BIN and
discovering a payment handler
... the vast majority of implementations are done with regex's
that doesn't fully capture the local branding of some cards in
some places
<stpeter> +1 to David Benoit's comment
IJ: Could you have a wallet selector to bootstrap the user's environment?
Tomasz: When you say 'having multiple wallets" you are referring to different wallets for methods, or just SRC?
Jalpesh: I'm not sure how to
react to this question.
... e.g., the browser knows about N payment handlers (from some
manifest) and the user has to choose one to start
... once the consumer selects the first one, after that they
user is off and running
Tomasz: My perspective is that it would be ok to have the user choose a first payment handler.
Jalpesh: I think it probably
still causes confusion (e.g., if there are a lot of payment
handlers)
... second point - once we give a consumer the choice and
they've used the card, are they stuck with that
experience?
... it would be important for the user to be able to make a
choice after the first choice.
... would user have to make a choice at every transaction?
Tomasz: So I think it would be confusing to the user to choose from a list.
Jalpesh: The use case is:
- Merchant requests only SRC
- User has no payment handler installed yet
- There are three payment handlers available that can do SRC.
- The user has to choose one of the three.
Tomasz: Jalpesh's question is still valid - is the selection persistent?
Ian: No. No selection is
forever.
... Does a browser behavior with a default payment handler in
the sheet satisfy the no wallet selector requirements?
Jalpesh: there could be a
comprehension problem
... if you don't want to pay with visa, the consumer doesn't
know that there are other cards to pay with
Tomasz: If you click on the arrow, then cards not presented in the master list
<rouslan> https://rsolomakhin.github.io/pr/bob-and-card/
<rouslan> https://rsolomakhin.github.io/pr/apps/src2/ - one instrument per payment handler.
IJ: Two problems:
- Bootsrapping
- No wallet selector
IJ: What are benefits / disadvantages of some third party being a payment handler discovery agenda?
https://github.com/w3c/src/wiki/UX-Assumptions-and-Requirements#src-discover
Jalpesh: If there were a common default payment handlers that would be one thing, but if there are multiple payment handlers and they have differing capabilities, then how you change it is critical functionality.
IJ: So is this an incorrect assumption: "Any SRC payment handler can enroll a card in any SRC system."
Tomasz: I think it's not an assumption but more of a requirement.
Jalpesh: I think the corollary is not true - it doesn't mean that all payment handlers MUST support all SRC systems.
IJ: I think we can't require
that.
... I need to change assumption then to say "We cannot rely on
all payment handlers enabling enrollment, display for all SRC
systems."
Jalpesh: That raises the importance of usability of making changes to payment handlers.
IJ: I hear requirements at odds - desire for distribution but centralized UX
Tomasz: Additional challenge - you could have N > 1 payment handlers in the ecosytem.
27 November