Payment Apps Task Force -- 04 Jan 2017

TommyT: The spec currently says that if a payment app should use clients.OpenWindow, which makes sense since it exists.
... BUT, currently implementations of client.OpenWindow are not necessarily suitable for showing payment app UI
... I site the example of Chromium (Android) and Opera, both of which show a new tab
... two tabs is not very useful..you don't want people to jump around between tabs
... so what is the way forward?
... I remember in the earlier version of the payment app spec there was a special version of the API for opening a window

adamR: I think the text that's in there about it being contextual and implementation-specific.
... I'm not necessarily opposed to adding a new API call.
... the rationale for going to client.OpenWindow...that spec in service workers is pretty complicated and we didn't want to replicate it.
... we shifted to using that function to avoid complicating our own spec

<Zakim> AdrianHB, you wanted to ask how implementors see this being implemented by rich web apps on mobile?

AdrianHB: What's the issue exactly? Is it that developers are expecting consistent behavior from clients.OpenWindow?

<conorhwp> Progressive Web App ?

<AdrianHB> yes, progressive web app

yes

rouslan: You could show them full screen without browser UI....
... it makes them look like native apps
... I wonder if we can somehow launch apps as "progressive" web apps
... where is this specified?

[We talk about App Manifest here]

<AdrianHB> https://github.com/w3c/manifest/

https://www.youtube.com/watch?v=MyQ8mtR9WxI

<scribe> ACTION: Rouslan to look into how progressive web apps could help us address issue 73 [recorded in http://www.w3.org/2017/01/04-apps-minutes.html#action01]

<AdrianHB> http://caniuse.com/#feat=web-app-manifest

https://github.com/w3c/webpayments-payment-apps-api/pull/78/commits/855790ae19152678a2f8f1695b1563ccb84fbd2e

Propose we merge this text (which had been deleted by mistake)

<AdrianHB> +1

<rouslan> +1

<jnormore> +1

Recommended payment apps

https://github.com/w3c/webpayments-payment-apps-api/issues/74

IJ: Rouslan, what were the requirements or wishes you heard from people?

Rouslan: we talked with some payment app developers that said that they plan to get their payment apps installed by making agreements with merchants
... instead of putting buttons on pages, payment app providers will say how to do things with recommended payments apps using PR API
... so the question is how do we suggest apps for the user to install
... it depends on how we identify apps or methods
... I think that issue is not entirely resolved...one way to identify apps is by service worker scope: origin + subpath
... but from service worker scope you can't get the JS file to install it
... unless that page, e.g., has a link to it
... another way of suggesting a payment app or identifying a payment piece of information is to point to the actual service worker JS file
... and in that file, there's a manifest...so you can install the service worker, and that installed the payment app using JS calls
... but that's kind of ugly in terms of how to identify things...even if it's flexible
... so the questions are:

* how to identify a recommended payment app

scribe: if the merchant accepts a payment method that has multiple apps, then the payment method (manifest) will need to identify also apps...and from there the browser could find out what apps to recommend to the user

Rouslan: Suggest we start with experimentation. Also, Ian also commented on the thread and I agreed with them

adamR: Regarding the first bullet points - if you point at the JS you don't have enough information. In registration you register the SW, and SUBSEQUENT to that you register a payment app manifest
... I think the first bullet wouldn't work. I think that the second option is the best of the three that Rouslan listed

jnormore: I have similar comments...the ugly URL can be prettied up by the payment provider
... doesn't require app.js extension at the end
... I think that the merchant should be able to provide human-readable name and icon
... I think that third bullet is not practical
... I think the merchant should provide the icon/name instead of relying on the browser getting it

rouslan: Sounds like there's some consensus about second point - merchant-provided information
... this is not necessarily a blocker...I think recommended payment apps are great but we can also do them in a later version of the payment app API

<jnormore> +q

jnormore: In terms of "recommended" payment apps, this is definitely very important.

<Zakim> Ian, you wanted to talk about questions

https://w3c.github.io/webpayments-payment-apps-api/#selectable-app-information-display

IJ:

Q. Should merchant provide metadata or should that be the payment app manifest?

Q. How does registration work when the user selects a recommended payment app (e.g., it's an option)

<Zakim> AdrianHB, you wanted to mention existing discussion between manifest and serviceworker devs

AdrianHB: In the manifest group, JakeA and a number of people started speaking about how manifest relates to service workers..they came up against the same issue - the need to register a service worker before the service worker can tell you about itself
... manifests are just static files that the browser can just fetch
... so I think this is another conversation we should have with Marcos and Jake
... we should list our requirements clearly
... I think I agree with Ian that it feels awkward for the merchant to label apps that are not theirs.
... but I agree we don't want to show the user a service workers JS file URL

<jnormore> +1

<jnormore> +1 adam

IJ: Is registration needed when user selects a recommended payment app?

AdamR: I can easily see merchants wanting to provide their own text like "Save 5% with bob pay"...so I think there are use cases for merchant-provided metadata

Jason: +1

AdrianHB: Does it make sense for merchants to be able to supplement payment app metadata?
... e.g., a brand would not want a merchant to use an old logo or, worse, provide their own icon for my brand
... so I think naming the app or icons should be out of scope for the merchant but the merchant should provide supplemental info

jnormore: That's how it is today....merchants have to comply with branding requirements as part of relationships with payment providers
... I think there are too many cons to restricting the merchant's ability to provide information that is displayed to the customer from the merchant standpoint
... not just to indicate discount information, but if I have an agreement with a provider to show a different or better icon for my store, I need to be able to do that

I hear some consensus around a combination of merchant-provided information about a recommended payment app + more details in a payment app manifest

IJ: what's the impact on the spec? Is there merchant-provided name/icon and a link to SW JS?

adamR: So far we have not required an external payment app manifest....
... I hesitate to require it since so much will be redundant with registration data
... on the question of whether we would need to instantiate a service worker in order to use the payment app, I think the answer is "yes"
... due to execution environment of the service worker.

IJ: I am hearing that registration is a pre-requisite for web-based payment apps (in a service worker sense)

Jason: There are multiple concepts:

<adamR> Can we limit the use of the word “register” in this context to the formal definition here, please? https://www.w3.org/TR/service-workers/#register-algorithm

a) Information sufficient to display a payment app for selection. For recommended payment apps, this comes from the merchant.

b) Service worker registration

c) user relationship to payment provider (e.g., getting a paypal account)

(That only is about the web based payment app case....for native apps there's some other way the browser knows about the payment apps)

IJ: Please clarify the relationship between the payment app manifest and the service worker

<AdrianHB> My favourite topic... The difference between a manifest and a manifest file

adamR: In service worker spec, there is an object called a "manifest" that has icons, options, etc.; it's a data structure that's instantiated by the script that registers the service worker; it's not a separate addressable file
... a "manifest" can only be accessed by the thing accessing the service worker.
... sequentially you cannot get the information in the manifest until after the SW has been registered

IJ: So the browser overrides the payment app manifest when the merchant provides icon/name?

<AdrianHB> -1 for merchant taking prec. As a user I don't expect the icon of something I installed to change

IJ: I am hearing that the merchant data overrides any registered data..and that registration of an unregistered recommended payment app happens upon selection by the user

rouslan: There was a point about recommended payment app information overriding registered payment app info. I think that's too complex. If the payment app is registered already, the user agent should use that information.

<AdrianHB> +1 rouslan

Jason: +1 to rouslan

(Comment about user confusion if icon changes)

Jason: I feel we are coupling the "implementation" of a payment app (service worker) from the "definition" of a payment app (which is merchant-provided)

IJ: Simplest model for me is that "recommended" is simply "Show icon+logo, and register then run on user select"
... Do we need to specify behavior for non-web recommended payment apps?

Rouslan: No

<Zakim> AdrianHB, you wanted to say that this still doesn't address the merchant wanting to incentivize use of an app

AdrianHB: If I don't have a payment app installed and the merchant recommends one, then they provide a name/icon. In the dialog is a set of recommended payment apps "Use Bobpay for 5%"
... if I have bobpay installed, how does the merchant convey that information if the user can't override the label/icon?
... so I think we need to balance merchant-provided info with user interface consistency and payment app registration-provided information

<AdrianHB> FYI re the manifest vs manifest file terminology: https://github.com/w3c/webpayments-payment-apps-api/issues/48#issuecomment-261474539

<scribe> ACTION: Ian to summarize discussion on issue 74 thread and mention merchant-provided info when app already registered as a thing that needs to be addressed [recorded in http://www.w3.org/2017/01/04-apps-minutes.html#action02]

Payment Apps Task Force

04 Jan 2017

Attendees

Contents

Next meeting

Filters

Developer call

Clients.openWindow

Recommended payment apps

Summary of Action Items

Summary of Resolutions