Payment Apps Task Force

06 Jun 2017


See also: IRC log


Ian, alyver, Ken, rouslan



Recent changes


rouslan: Makes sense

Issue 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

Implementer updates

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


<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


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.

issue 168


rouslan: +1 to that comment....gogerald is the implementer who is building this
... found a bug in the spec

Issue 166 (editorial)


<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

Issue 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

Issue 117



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]

Issue 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.

Next meeting

Proposed 20 June

rouslan: +1

IJ: Any regrets?

RESOLUTION: Next meeting 20 June

Summary of Action Items

[NEW] 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]
[NEW] 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]

Summary of Resolutions

  1. Next meeting 20 June
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/06/06 15:00:56 $