See also: IRC log
https://github.com/w3c/payment-handler/commit/624cb43deb81db326523b9afa6836f34c8871f95
rouslan: Makes sense
https://github.com/w3c/payment-handler/issues/163
rouslan: client.OpenWindow can
return null window if the SW tries to open a URL that is from a
different origin
... e.g., PayPal could not open a mastercard.com page
... this is not an issue because we have defined our open
window backend to be restricted to the origin of the service
worker
... the service worker gets a security error instead of a null
value
... so the user never sees a window
... we noticed this discrepancy and wondered what to do with
the spec
... the problem in the spec is that there is some text that
talks about returning null and checking the origin; seems like
a copy/paste error for the SW spec
... so we have someone from samsung to do a PR to clean up the
spec
... so that it's clear everywhere that SW from origin A can
only open pages to the user that also come from origin A
... note that our openWindow algo is not exactly same (by
design) as the SW algo
... my expectation is that Samsung engineers are working on
this for Blink
rouslan: Going great!
<rouslan> chrome://flags/#enable-experimental-web-platform-features and
<rouslan> chrome://flags/#service_worker_payment_apps flags
rouslan: we have implemented
openWindow in Chrome behind 2 flags
... in the next Canary (day or two) on Android you should be
able to flip the 2 flags and get the full flow of payment
handler
... a few things are still missing - icons
... still figuring out caching, icon sizes, etc.
... once the spec is finalized we'll update the implementation
based on the spec before shipping to the public
https://w3c.github.io/payment-handler/
<rouslan> https://play.google.com/store/apps/details?id=com.chrome.canary&hl=en
IJ: How is display of wallet granularity going?
rouslan: We are striving to show
one line per app in Chrome on Android
... have not yet figured out how to do this on desktop
... we are working to ship PR API in milestone 60 on
desktop
... we are not yet at the stage of implementing payment handler
on desktop
https://github.com/w3c/payment-handler/issues/129
IJ: Have you seen maplike in the wild?
Rouslan: I have not. I understand
Marcos' point that it will be easier for spec authors to
reference those objects, but I'm not aware of any
impelmentations.
... from the standpoint of web developers, nothing should
change payment handler API functionality
IJ: Agreed.
https://github.com/w3c/payment-handler/issues/168
rouslan: +1 to that
comment....gogerald is the implementer who is building
this
... found a bug in the spec
https://github.com/w3c/payment-handler/issues/166
<scribe> ACTION: Ian to do a pull request to remove out of date URL from the example [recorded in http://www.w3.org/2017/06/06-apps-minutes.html#action01]
IJ: the out of date URL is https://w3c.github.io/webpayments-payment-apps-api/#sec-app-response
https://github.com/w3c/payment-handler/issues/169
IJ: This is in section 8
rouslan: I think that the engineers who fix up the open window algo text will also encounter this and should incorporate this in the algo
https://github.com/w3c/payment-handler/issues/117
https://github.com/w3c/payment-handler/issues/117#issuecomment-289162845
IJ: summary - pass on an abort()
event from the merchant to the payment app, to be handled as
appropriate for the payment method and status
... I wanted to review Matt's comment here
rouslan: Let's not introduce new
states that are payment app specific. They are private to the
payment app and may not align with the browser's state
machine
... I think the simplest / cleanest API would be to give the
abort event to the payment app service worker, that replies
true or false and it's up to the service worker implementation
to decide whether true or false
IJ: IS there a place for a status
code or message?
... e.g., "payment has already been processed"
alyver: How far do we want to go
with this? I agree with Rouslan that the response should be
true/false
... what about case where payment method is push, and the
payment app immediately refunds the transaction
... user might see a "pending" thing that has not yet been
resolved.
... so there MIGHT be a case for a message, but it feels like
an edge case, and I think that a simple true/false is
sufficient for most use cases
rouslan: I think true/false is
sufficient; no need for code.
... it wouldn't make sense from the user interaction
standpoint
... if the site tries to abort a payment request in progress
(e.g., because concert tickets no longer available)
... I don't think more information from the payment app will be
useful from the user interaction standpoint.
IJ: What does true mean?
rouslan: It means that the
payment has been ABORTED as requested by the web site
... that means that the show() promise will not be
resolved
... whereas false means the payment was not aborted (per the
site's wishes) for some unknown reason
IJ: Are there any changes to PR API required if we support abort() in payment handler?
rouslan: No.
IJ: Does this user experience
happen in the world today in any transactions?
... can this happen on the web today?
alyver: This concept of abort
doesn't really exist on the web today
... or maybe the equivalent is during a redirect to something
like paypal
IJ: Could we highlight a new benefit of payment apps like "can do immediate refunds"?
alyver: I'm not sure we should
recommend that functionality.
... the goal of payment request is making capture easier...but
not focused on voids and refunds
... if a transaction has already been done, there are other
implications to the merchant that they would need to be aware
of
... e.g., there might be fees charged on the transaction..opens
up a can of worms
IJ: Rouslan, would you be interested in adding an abort() event to the spec in a pull request
rouslan: I think it should be optional; don't want to initiate the pull request. Happy to review it.
rouslan: Canary on Android will be available soon with near full functionality and so please experiment and get back to us!
<alyver> Thanks Rouslan - will try to get the team here to experiment.
<scribe> ACTION: Ian to alert the WPWG to this and try to muster some implementation experience [recorded in http://www.w3.org/2017/06/06-apps-minutes.html#action02]
https://github.com/w3c/payment-handler/issues/157
IJ: Is that part of your implementation experience?
rouslan: Not yet...we need to
clear up in the spec first
... I will do a PR for this
IJ: What is your expectation
about implementing before putting text in the spec?
... what if you do a pull request and then say you are going to
implement and may update the PR (and not to merge until you
have)?
rouslan: +1
For each resulting payment handler, if payment method specific capabilities supplied by the payment handler match those provided by data, the payment handler matches.
Proposed 20 June
rouslan: +1
IJ: Any regrets?
RESOLUTION: Next meeting 20 June