Rouslan: We are going to have
ad-hoc installation with user prompts
... e.g., going to a bank site to install a handler; user
gesture will be required
... second use case will be just-in-time installation
... what we are are planning is not defined in the spec; it's
an optimization
... chrome will look at the accepted payment methods, as well
as manifests, and determine whether the handler can be
registered
... this will address google pay use case
... user would not visit site first in this case
... the user gesture occurs when the user selects the payment
app
... prior to that the service worker would not have user
information
Ian: Define "register" v. "install"?
<Zakim> alyver, you wanted to understand the google pay use case better, please.
alyver: I'd like to understand the Google Pay use case a bit better
rouslan: The main point is to be
able to install a handler for origin A without the user having
to visit A by making use of manifest information
... the payment method manifest has a "default application"
possibility; if there's a link (to a service worker) that can
be crawled
... expectation right now is to only install one payment
handler per origin for just-in-time install
alyver: In that use case, the fact that the user selected the payment method, then there's no additional prompt to install the service worker?
rouslan: I don't think so, but we may see the words "install and pay"
https://w3c.github.io/payment-handler/#model
IJ: Should we mention use case
2?
... do you think use case #2 will be the predominant use
case?
rouslan: I don't think so
... For now, Chrome may be the only browser to do this
https://github.com/w3c/payment-handler/issues/240
IJ: do you want to review the issue to decide whether to close it?
rouslan: I will do that.
For this issue, is this just for JIT install? => https://github.com/w3c/payment-handler/issues/239
rouslan: I think that was
separate initially
... I will review that one as well
Marcos: Current focus is PR
API
... I need to look at canmakepayment tests
https://github.com/w3c/payment-request/issues/476#issuecomment-359672926
marcos: postpone!
... do you see any need for hooks in PR API?
https://w3c.github.io/payment-request/#user-accepts-the-payment-request-algorithm
marcos: Are there any (more)
hooks needed?
... the UA is "like" the service worker...not sure we need
hooks; just need to make sure the text works fine
rouslan: basic card can be done
nearly instantaneously (for card in browser) but payment
handler may need to be done more asynchronously
... the main issue we found was due to name reuse between
function call and event for canMakePayment
https://w3c.github.io/payment-request/#user-accepts-the-payment-request-algorithm
IJ: Do abort() and canMakePayment() need to be updated?
https://github.com/w3c/payment-handler/pull/207
https://w3c.github.io/payment-request/#dfn-abort-the-update
IJ: does there need to be a call
out to the payment handler spec?
... How does abort request get handed to the handler? Does PR
API need to say something?
rouslan: see:
https://w3c.github.io/payment-request/#abort-method
"Try to abort the current user interaction and close down any remaining user interface. "
rouslan: That could say, for example, "possibly notifying any handler the user may be interacting with"
Marcos: Yes, we could clarify 5
to add mention of payment handler
... e.g., "Try to abort the current user interaction with the
payment handler and close down any remaining user interface.
"
https://w3c.github.io/payment-request/#canmakepayment-method
IJ: should we mention handlers in step 6?
https://w3c.github.io/payment-request/#payment-handler-matching
Does 3.5 mention or refer to 18.2?
There are also other possible algorithms we might invoke to reduce the overall set of matched things (e.g., payment method manifest authorized payment handlers)
Rouslan: Payment method specs define the filters
IJ: I think 3DS will affect matching algo also (e.g., "I only accept 3DS flows as a merchant")
[We review 3DS briefly]
<AdrianHB> There is no relation between basic-card and 3DS
In 3.5: If methodData.supportedMethods is a supported payment method identifier (including its payment method specific capabilities), resolve promise with true, and abort this algorithm.
<AdrianHB> Key phrase is: "including its payment method specific capabilities"
IJ: the question is whether we need to say "Other specs may define how reducing set of payment method identifiers" takes place
Marcos: We could include a note on what "supported" means, e.g., it will be defined in each other spec from the WG
IJ: I am happy to take an action on thread with Matt re: abort() and "still looking at" canMakePayment()
marcos: Yes, algos don't change; we just need clarification
IJ: i am hearing to make minor change
marcos: I don't think we're quite there yet for some things; so keep it small
12 February
Thanks!