[Ian frames the discussion; diagrams will be available later this week to the group]
Jonathan Grossar: This first flow assumes
a "Multiplexing" payment handler to do "add card"
functionality
... and then individual payment handlers will be installed, one
per card for each enrolled card
... in this model, each payment method manifest refers to the
same multiplexing payment handler
... the goal is that the browser only display one payment
handler (the Add Card payment handler)
Rouslan: It's already the case that chrome only shows one payment handler (not N) when N payment method manifests refer to the same payment handler
Peter: For Mozilla, this is something for us to take into consideration; +1 to the anticipated UX
Jonathan: There might be some SRC-system specific request data. The expectation is that the payment handler receives all the data for the N PMIs, which is already the case.
[Jonathan walks through the SRC identity bits]
clinton: Regarding assumptions - in steps 1-7....if the SRC system knows who the user is, how is that handled?
https://github.com/w3c/src/wiki/ProposedArchitecture
IJ: I expect that Add Card includes Retrieve card; just not shown here
Jonathan: The expected UX at the
end is that you have after N enrollments: N payment handlers
(one per card) and 1 AddCard in the sheet
... Two things happen after SRC enrollment:
- We persistently store some information for future user recognition
- We install a new payment handler specific to this card that is available for future transactions
Jonathan: We are still in transaction, so payload is built and returned to the merchant through the APIs.
[Now we walk through "Returning, recognized user ... add second card"]
Jonathan: There are also some
details about modifications to payment handlers (e.g,. removing
a card)
... Note that each origin has its own indexDB space
Manoj: Each time this happens, the card is adding to the payment sheet (in its own payment handler)
[Ian mentioned UX desires, like "Add Card" appears at the end of the list of registered handlers]
[Flow where the user chooses from a previously enrolled card]
IJ: Note that there is a "with UI" and "without UI" options.
Jonathan: Another thing not shown
- issuer authentication
... we could leverage 3ds, webauthn, etc...but not shown
here
andrey: Is the plan here to have a separate payment handler for every card?
jonathan: Initially we thought "one payment handler per SRC system" but the proposal is one per payment instrument
https://github.com/w3c/src/wiki/ProposedArchitecture
https://github.com/w3c/src/wiki/UX-Assumptions-and-Requirements
Ian: Next step is to share some questions and answers
IJ: Note that we are also working on authentication issues, and also learning about decisions in the WebAuthentication WG regarding embedded FIDO flows.
Jonathan: We'll share the diagrams we've seen today by end of week
IJ: Any other experiments going on with flows?
Clinton: We don't have any feedback currently; I'll take these flows back and verify internally
Fawad: I'm hoping to have more feedback by the next call; we are reviewing this
Manoj: From Visa's side, we are
looking to solve this as well; we'd also like to see what
happens when the card is already recognized by the DCF.
... there are also some use cases where the browser knows of
cards...how can the card list be made known to the
merchant?
IJ: Probably not. What
functionality is required specifically?
... you can use hasEnrolledCard
... Are you saying you'd like payment handlers to connect to
autofill?
Manoj: Perhaps, where merchant wants to keep form-fill to keep the user in the merchant's experience.
IJ: that has come up as an idea; glad to hear your interest in that.
IJ: One heads-up with respect to the flow diagram that was shown: browsers cannot install cross-origin service workers for security reasons. Therefore, the flow that shows the browser reading a payment method manifest on origin A and installing a payment handler from another origin will not work today. We are working on alternative approaches
18 March