Previous SRC summary at 15 Nov WPWG call
scribe: expectation is there will be a blog post soon based on Nick Telford-Reed / Matt Saxon / Danny Russell evaluation. I have created a pseudo-flow diagram based on the analysis for discussion. Caveat: it could be wrong, or one of many possible flows. The goal was to show a relationship between Payment Request API and SRC ecosystems, and where the protocols are invoked.
<Zakim> rouslan, you wanted to say that I support making changes to Payment Handler for a more complete complete().
rouslan: +1 if we need to create
a more complete complete() on the payment handler side
... currently our implementation can kill the payment handler
after the payment handler returns the response.
... but we could also wake up the payment handler and give it
more data
IJ: May involve a payment request
update (e.g., updateWith())
... that is also propagated to the Payment Handler)
... see also digital receipt use case
Tony: From what I recall, doesn't SRC initiator initiate the payment, not the merchant?
IJ: Maybe...but trying to find a way to translate
Tony: The SRC-I is the merchant front door.
lte: When you look at the portion of the flow based on showing cards, there may be options for payment that are not SRC-based
Please review this https://github.com/w3c/webpayments/wiki/prapi-deployment-faq
lte: Second issue is prioritization of options
IJ: Browser sorts payment
handlers. What a payment handler does is up to it. Tricky
scenario is when browser is SRC initiator implementer
directly
... Browser sorts payment handlers
lte: SRC spec could dictate prioritization
<Zakim> rouslan, you wanted to ask what are the SRC requirements for ordering of cards?
rouslan: I am hearing that SRC has requirements for card order display...is that correct?
Tony: Yes, there is an algorithm
in the spec
... but if you have multiple SRC-I, then that raises some
issues
... e.g., private label card v. card network card
... merchants would want private label card at the top
IJ: See SRC spec 2.5.1 SRC Candidate List
Tony: The spec does not speak to the concept of a default list
lte: If there are multiple SRC-I
(merchants may use multiple processors for various
reasons)
... you may have the same card as a user with a merchant as a
primary that would be processed through 2 different SRC-I
IJ: Theme in PR/PH is "move
functionality to the user side'
... maybe "consider user defaults' should be feedback to
SRC
Tony: We can send that kind of feedback during the public comment period.
lte: Also merchant choice
IJ: The question is "How does the protocol need to change to do this?"
<Zakim> rouslan, you wanted to say we are interested in SRC
rouslan: Thanks for the flow
diagram; helped a lot.
... Google is interested in SRC, and in working with partners
to improve the ecosystem.
(IJ will add diagram thing to minutes, even if flawed)
IJ: Any initial thoughts on SRC-I capabilities in the browser?
Rouslan: To explore; but currently we are more focused on payment handlers as SRC initiators
IJ: Any other useful resources we might consult?
lte: Would be helpful if networks were to share more about implementation plans.
Tony: They definitely have
decks
... agree would be helpful to share them
... one note I want to share is about the DCF
... some of the things they list imply a UX
... also may handle enrollment
... they also talked about then DFC handling UX for
programme
... a critical thing done by the DCF is the binding
... to streamline checkout, the DCF does the binding requests
so that the next time you use it, it should work better
... I think the DCF plays a bigger role than you show in your
diagram
... we need to dig deeper
Manoj: I share the same
understanding...the DCF plays a role in SRC with a UX
... it does the binding as Tony said between card and
device
... my understanding is that it is like a payment handler
... I think the DCF performs the consumer interactions
lte: I don't know how it could
conflict or support, but within the SRC spec, it does allow
enrollment during checkout
... from a merchant stand point, we we are pushing hard that
how enrollment occurs is a merchant choice
... also another question about SRC is how the consumer can
unbind
... e.g., as users change devices
Tony: I have not seen unbinding in the specifications anywhere; definitely something we'd need to find out from the networks
IJ: PR API will support
hasEnrolledCard() (in v1 or right after)
... so from PR API perspective, browser will delegate to
payment handler that will answer "yes" or "no" (if they can do
so per SRC)
12 December
ACTION: Ian to turn the image into a more formal flow diagram
<scribe> ACTION: Ian to turn the image into a more formal flow diagram
Ian: No meeting on 26 Dec
... following meeting 9 January 2019
IJ: I think deliverable #1 should be a flow diagram people agree with.