IJ: Bit three requirements:
- Discovery
- No wallet selector
- Minimize auth friction
<Zakim> benoit, you wanted to discuss an alternative?
benoit: Since it is very easy to install a payment handler, is there any reason that a payment handler couldn't be an instrument?
<Zakim> rouslan, you wanted to talk about the thin PH
rouslan: For the "thin discovery
payment handler" approach, this seems to be similar to what is
shipped to users now with a popup experience.
... for SRC
... e.g., the Movember site shows a Mastercard thin payment
handler
... I tried out the demo :)
... could someone from MC speak about that experience and
whether that maps to payment handlers?
Tomasz: On Movember, the SRCI
invokes an API to connect to different SRC systems. There are
three calls to three different systems. The cards a presented.
And that's the functionality that a payment handler would need
to impelment.
... once the cards are selected, there's a redirection to the
relevant DCF
... so what I'm thinking (and what aligns with our Japan
demo)
... is a payment handler displays card metadata (from SRC
systems) and after selection, there is a redirection to a page
that is a DCF experience from that SRC system.
... the DCF performs the checkout operation, which means it
contacts the SRC system to generate the cryptogram and returns
the payload to the browser, which relays it to the merchant in
the PR API response
IJ: There's a difference between "knowing where the payment handlers are" v. "knowing how to talk to the SRC systems"
Tomasz: the component that
displays the cards needs to know how to display the
cards.
... so there is a question - who plays that role of pulling the
card information and presenting to the consumer?
... does a third party play that role, or does the browser play
that role/
Thin payment handler functionality:
- PAN capture
- Installation of relevant payment handler
- Hand PAN to that payment handler
IJ: The thin handler could have its own payment method identifier, which would allow it to appear in the sheet all the time and it could be just-in-time installed
Tomasz: I think the browser is well-positioned for that role.
Justin: Chrome would like to make
payment handlers more powerful to address more use cases.
... and this will help with interoperability with other
browsers as well (once they install payment handlres)
... I think the browsers are unlikely to do payment method
specific logic built into the browser.
[IJ describes flow]
Tomasz: Please document the flow
/ sequence diagram.
... but based on your description I think it makes sense.
... but I think we need to illustrate it
Justin: I imagine there will be
nuances we need to sort out, but at a high level it seems
feasible.
... we should have a good assertion of who that party could
be
Tomasz: I think it would be relatively easy to identify the publisher of the redirecting payment handler.
IJ: Feels to me like URL-based payment method with owner describing thin payment handler
<scribe> ACTION: Tomasz to take a first pass on sequence diagram that involves a "thin payment handler" that dispatches to SRC systems.
Tomasz: One more point - I have some security questions. How do we prevent imposters from presenting themselves as add card functionality?
Justin: This is an important
topic, and it may come down to implementation details.
... right now suppose you are a merchant and you accept Basic
Card.
... the browser will present any Basic Card payment
handlers.
... but one of them might have been installed silently by a
nefarious web site.
... although the user sees the origin of each payment handler,
there's a risk the user may overlook that.
... so we are looking into soliciting more user consent to
install a payment handler for a standardized payment
method.
... We are looking into also proposing changes to Payment
Method Manifest to not allow '*' for a URL-based payment
method.
... this will reduce risk for non-standardized payment
methods
IJ: Also whitelisting.
... for URL-based payment method
Justin: Yes, we can explore whitelisting for this URL-based payment method
Tomasz: Thanks for that info. It will be good to get into details as well.
IJ: What about the "Common default payment handlers" option? Is that something socially that people think is worth exploring?
Tomasz: Yes, I think it's worth exploring.
<scribe> ACTION: Ian to write to Jalpesh, Sophie, Fawad regarding the two ideas: (1) thin ph (2) common default payment handler to see which are of interest.
IJ: Volunteers for a demo?
<Jtoupin> I need to drop @Ian
Tomasz: I will chat internally
11 December