8 January
Marcos: Regrets for the 8th
https://github.com/w3c/payment-handler/issues/239#issuecomment-348980177
Rouslan: Marcos, what are your
plans re: requestPermission?
... will it be used to pop up a UX on Firefox?
Marcos: I need to think about it more
https://github.com/w3c/payment-handler/issues/239#issuecomment-348987397
Marcos: In FF, there's a kiosk mode
IJ: Would standard calls be used here so nothing to do?
Marcos: We could mention this in Privacy and Security
<scribe> ACTION: Ian to write a paragraph for security and privacy considerations about private browsing / kiosk mode and mention not storing data
Rouslan: We plan to do
just-in-time installs
... we might show, e.g., PayPal URL in the sheet, and the user
can install it
... we'll open window for PayPal to install service worker, and
once installed we'll fire payment request into PayPal service
worker
... how much just-in-time install should go into Payment
Handler? I think all of it.
AdrianHB: I think "none of it"
needs to go in payment handler
... it sounds to me like an optimization around
registration
... it's not an interop feature
Marcos: It depends on whether it starts to create objects or credentials store
AdrianHB: Agreed
... but as proposed now, it's just using the registration
flow
... I don't think (if I recall) that it changes the API
surface
rouslan: Agreed that the existing
API surface does not change.
... the question is whether Marcos is interested in
implementing in Firefox .. in which case we should figure out
how to implement interoperably.
<AdrianHB> I think that "implementing this" is mostly UI right?
IJ: How does the dev do something?
Rouslan: Devs need to put
something in their payment method manifest, namely URL that is
used to trigger implementation
... the second thing that is needed is how to pass any params
into the page (e.g., hash tags in URLS)
... the third is how are errors reported
<AdrianHB> Sounds like something to put in the manifest spec (if anywhere)
Rouslan: the reason we want to
change hash tag is that changing it does not cause a server
round trip but it can be detected in the browser.
... and we could change it to indicate success of
installation.
... so those are a few bits we could spec out.
IJ: +1 for a system where payment methods can participate in this ecosystem at their own initiative.
<AdrianHB> +1 for specifying JIT install URL in manifest (and specifying this behaviour in the manifest spec)
IJ: Is there really a diff between JIT install and a regular registration.
Rouslan: We want flexibility to
take into account new payment methods.
... regarding input parameters... there aren't any in terms of
Javascript (compared to registration)
... one thing that we have considered is this: suppose
evilshop.com wants to use goodpayments.com
... but goodpayments.com does not want to be associated with
evilshop...we were thinking that in hashtag we might warn
payment app about pending registration...we think we need to
pass canmakepayment params into installation page.
<Zakim> rouslan, you wanted to talk about payment method privilege
rouslan: since all the information is fired after in payment request, do we think we should wait for it?
IJ: I suggest we treat it like before - let the payment handler tell the user what happened.
Rouslan: Makes sense.
... Regarding hash tags, before it is registered, hash tag is
"#install". And the page shows a spinner
... after registration, we would like the handler to let the
browser know about the completion of JIT installation; we were
thinking of doing that in the URL hash tag (e.g., #success,
#fail)
IJ: Why is this different from regular registration?
Rouslan: It's not "during a
transaction" so there are opportunities to communicate with the
browser
... but here the browser wants to fire PR API right aftern.
Marcos: Maybe this is HTTP
... e.g., 500 or 200 code
... it's getting close to "foreign fetch"
... but basically, the page makes a request, the other service
worker wakes up; synthesizes the response and can fail in a
particular way
... we could try to use status codes
... feels cleaner than using fragment IDs
... If you are on site A and look for a resource on site B, SW
wakes up to handle it
... but that has issues and kind of died on the vine
<marcosc> https://developers.google.com/web/updates/2016/09/foreign-fetch
Rouslan: Ok, that means that the bit to change is "default installation page"
Marcos: You can also look diversity among 500 response codes
https://github.com/w3c/payment-handler/issues/242
IJ: (Ian summarizes state of the pull request; there is editor agreement on the state of the pull request and not adding more explicit information on different ecosystem stakeholders.)
https://github.com/w3c/payment-handler/issues/243
https://github.com/w3c/payment-handler/issues/243#issuecomment-352039493
"At the most I think we can say that order of priority for the instruments from a single payment handler is inferred b y the order they are registered by the handler but beyond that, how that order is mixed in with other preferences, is UX space and not in scope for us."
IJ: Any thoughts on this?
<AdrianHB> +1 - don't think there is a need to change the spec
rouslan: I don't think we need to change the spec. can use registration order and frecency
https://w3c.github.io/payment-handler/#instruments-attribute
IJ: Should instruments be an ordered list?
Marcos: It's an ordered hash
map
... I'll have a pull request for this soon
... insertion order will be maintained
alyver: The instruments
themselves are related to the handlers
... if the same instrument is contained in two payment
apps...how does that affect frecency?
rouslan: They are unique from a browser perspective.
Marcos: We don't need to say anything else regarding display....we have ability to do everything from available information.
IJ: Can we say in PR 242 "and instruments"?
<rouslan> +1
<marcosc> +1
<IJ> +1
<AdrianHB> +1
<scribe> ACTION: Ian to amend pull request 242 to mention instruments.
<scribe> ACTION: Ian to indicate on 242 the editor consensus and point to amended 242
https://github.com/w3c/payment-method-manifest/issues/11
IJ: Please confirm that in case of error, default promiscuity is "only payment handlers from the same payment method origin"
Rouslan: Yes
... how do we specify "open" without requiring hosting of a
payment method manifest
AdrianHB: I think rouslan's
response is fine, but brings us back to the conversation in the
Wg of what constitutes acceptable pre-work for a WG to take up
a payment method ?
... we don't have a quality gate
Marcos: We can incubate ...
IJ: Regarding issue 11 for
manifest
... not having to host a manifest?
... we will return to this question
rouslan: Right not canMakePayment pull request is under consideration...and we've written tests.
https://github.com/w3c/payment-handler/pull/170
Marcos: Generally tests and PR land at the same time
Rouslan: I've addressed marcos' comments...
Ian: Go for it
... what's the quickie summary of how this works?
Marcos: We should be clear in commit messages
IJ: Is it written down anywhere that "if standardized then X, if URL then Y"
https://github.com/w3c/payment-request-info/wiki/FAQ#general-payment-app-questions
PROPOSED:
* Rouslan to land tests and PR for canMakePayment with a commit message describing the algorithm and summary of changes
* Ian to port the "how it works" to the FAQ
+1
<scribe> ACTION: Rouslan to land tests and PR for canMakePayment
Ian: ENJOY!