Payment Apps Task Force -- 21 Feb 2017

<Zakim> AdrianHB, you wanted to suggest a change to "A payment app registers support for payment methods with the user agent, through service worker registration."

AdrianHB: I think what you are saying is "the way that a payment app registers support is by registering a service worker, and during that registration process, it has the opportunity to register support"
... We want to cater to the audience, which is developers

Jake: When we did the service worker spec
... for various events
... none of these specs defined what a web app is
... or what a push listening web app is
... I'm worried that trying to define that is causing problems
... instead we should be giving the ability for an app to handle payments

<JakeA> +1

Rouslan: +1 to spec just talking about features

IJ: +1
... FPWD is a good time to split out the info

AdrianHB: +1 to sentiment of separating spec feature definition from marketing material

<JakeA> "handler" is good

AdrianHB: e.g., the spec could be named after the feature name
... so it's less about payment apps and more about features that we are defining to let someone build a payment app

<adamR> I’m weakly +1 on renaming

<AdrianHB> Please let's not let recommended payment apps drive this design

IJ: Recommended payment apps...what are the identifier designs?

Jake: Regarding recommended payment apps, nothing better than link to a service worker

<adamR> Huge -1 to whitelists

<AdrianHB> -1 to whitelists too

IJ: Recommended may mean "merchant preference; for browser discretin"

JakeA: :Even just a URL will look like a browser recommendation since in chrome
... since just a URL it's less good than a LINK that can have title, link text
... I think it's important to keep info that is really about the landing page's content (e.g., recommendation) in the page

<Zakim> rouslan, you wanted to talk about method/app relationship

rouslan: I think the primary argument for having recommended apps is that these identifiers are different from the payment methods

<AdrianHB> +1 to JakeA flow (noting that the PaymentRequest API calls fail silently)

(IJ: Agreed app identifiers are not the same as payment method identifiers)

rouslan: E.g., multiple payment apps may support a tokenized card payment method spec
... but for proprietary payment methods, owners want to authorize payment apps to support those payment methods
... therefore we need to be able to identify apps from payment method manifest files

<AdrianHB> Suggest that payment method manifest restrict apps by origin

(That's the question: do we need a URL or just an origin?)

<AdrianHB> For permission, just an origin

Rouslan: It's useful for the merchant to suggest 2 or 3 apps that work well with their web site
... that's an argument in favor of recommended apps

JakeA: What's wrong with a link?

AdamR: I think it would be problematic if we required payment method manifests to contain a pointer to payment apps in order for them to be recommended.

<AdrianHB> @AdamR: The current payment method manifest proposal is to have a whitelist where the absence of a whitelist implies no restriction

IJ: There are two things we've talked about (1) expression of merchant preferences (2) bootstrapping the app ecosystem

Andre: -1 to whitelisting
... I think there is value to merchants providing preference information that browsers can use to highlight
... I also like the approach of linking recommendations to canMakePayment() [failure]

<AdrianHB> -1 to whitelisting by merchant BUT whitelisting by payment method manifest publisher is the current proposal

<JakeA> Why isn't the identifier the registration scope?

adamR: Reminder - there are two things we are thinking about here.
... one thing is "recommending code" a landing page that registers the app
... but there is a different use case which is merchant recommendation of payment app

(e.g., special promotino)

scribe: the identifier for that will almost necessarily be different

<JakeA> payment option weighting seems fair

<AdrianHB> I think the only way we can cater for use case 2 is recommend by origin

IJ: QUESTION: - recommend apps by origin?

AdrianHB: The merchant has no idea what options will be presented to the user; the merchant can't recommend options
... merchants know payment methods and origins of extant payment apps
... so at most they could recommend them by origin

Adam's proposal re: options

https://github.com/w3c/webpayments-payment-apps-api/pull/104/commits/dc913b844e131a5f5c3156a41328da1154f2dee8

Adam: Replaces monolithic set/get manifest with more granular
... it also incorporates to some degree our FILTERING direcion
... so we no longer have lambda functions
... this is based on filters/capabilities approach
... so we define two constructs:

* OPTIONS...for most payment methods this will resolve 1:1 to instruments like credit cards

* WALLETS...this is an additional container for use case where there is one origin that wishes to group payment options together

scribe: e.g., white list wallets, or personal/business groupings
... or Multiple instruments held with a single provider

AdamR: The current document does not go into much detail on rendering
... some ideas: if you have no wallets the browser renders payment app (e.g., manifest) info
... but if you have wallets, those override the app-level information

<AdrianHB> So wallets are just a grouping for options?

(Yes)

https://github.com/w3c/webpayments-payment-apps-api/issues/98#issuecomment-280747308

Jake: Other things that talk about service worker treat registration as a "toplevel thing"
... so "a payment handler" would be stored within a service worker registration
... so an origin can have multiple payment handlers
... the browser may group information

AdamR: To be clear, the concept is to decouple the grouping of what is shown to the user from how the web site chooses to structure handling
... the notion here is to separate "how service workers are structured" from "how to render grouping to the user"
... they may or may not be handled by different service workers

JakeA: Some concerns about complication
... with fetch events, for instance, you have one fetch event. You don't have multiple different service workers handling requests from the same URL space
... that means we don't have to manage "which service worker is this going to"

AdamR: We could add that restriction; it's orthogonal.

<Zakim> alyver, you wanted to ask adam to re-explain "options" again.

<adamR> https://dl.dropboxusercontent.com/u/53717247/amex.png

AdamR: In this proposal - wallet is container, option is instrument level
... in the above image, the wallets are "American Express" and "American Express Business"
... and the options are the individual cards
... These are like having H1 and H2 groupings of things
... it's just a rendering construct

JakeA: It feels to me like this would be stored against a payment handler that is a SW registration that knows about cards and the grouping

AdamR: That's exactly it

JakeA: Sounds great!

<Zakim> AdrianHB, you wanted to ask what happens if 2 service workers register the same walletKey

AdrianHB: Agree it mostly sounds great. We said we are decoupling the presentation from the execution which is great.
... that was the goal...BUT
... I'm not sure we've achieved it. As an example, suppose PayPal gives me some service worker code... I want a single wallet, multiple service workers to handle different methods
... so I want to group three service workers in one wallet
... how does it work?

<JakeA> Having a single wallet spread across multiple SWs, that feels complicated

AdamR: If we decide to allow multiple SW/Registrations that should work

AdrianHB: I assuming the groupings are OPTIONAL for the browser to render

AdamR: I suspect that long term it will be implemented

AdrianHB: If options are not rendered, might be issues
... if the user only sees OriginA and OriginB....if I have three service workers, what happens when user selects OriginA
... It may be that groupings are optional

QUESTION: Can we allow multiple service workers to register to handle payments?

JakeA: Many things that are built on service workers have allowed multiple things per origin (e.g., fetch listeners, background syncs)
... but the restriction is that the TOP LEVEL is a service worker registration
... a single push listener only deals with one service worker registration
... you are tied in that case to a single service worker registration

<AdrianHB> +1 that speaks to the comment I made about terminology at the beginning I think

JakeA: when you are updating code, it's updated in an atomic way
... A payment handler has a 1:1 mapping to a SW registration
... you can't have more payment app handlers per SW registration
... you can have less, but not more

AdrianHB: How would you code multiple event listeners then?

JakeA: Each SW registration has one main SW. that's where the events are fired
... if you want 2 PUSH subscribers, you need 2 active SWs

AdrianHB: Given that setting of options / wallets is done against the payment app manager (an extension of SW registration) I assume that was our intent
... if I want different service workers handling different options, then I assume I need to register each one independently
... You can code it such that what you select triggers different SW

AdamR: I agree with issue about rendering options in that case

AdrianHB: You register a SW, you have an option to set some stuff (e.g., specific to payment request handling)

Ian: How do you propagate when options not shown?

AdamR: I am not yet sold on necessity of multiple service workers
... I like the simplicity of what Jake has described in other settings

AdrianHB: You can register multiple service workers (it's not one per origin)

JakeA: I mean to say "One per registration" for each Push subscription but you can have "Many registrations per origin"
... suggesting the same for payments
... a given payment handler is a service worker registration

(Top level)

scribe: you can have multiple per origin

IJ: The UX I want is (1) if options are shown, they are active (2) if options are not shown, open the payment app

AdrianHB: I don't know whether the browser is going to render options or not. So if the event is called for all service workers, I don't know whether I was actually selected

AdamR: The event includes the pointer to the ID of the option was selected. If the option was not selected, the field was not populated

JakeA: If the browser knows what the next selection is, the browser could then ask "What card?"

AdrianHB: I think that Zach has said we should not prescribe that level of user experience

(IJ: We have not discussed previously Jake's notion of "submenu")

AdamR: Developers can make a choice to use 1 or N service workers

JakeA: You will still have the same screen space problem if you have lots of options from many origins
... but I don't think we should have a different end state than on mobile
... this is not really about specifying UX...it's up to the browser

AdamR: I see what you are saying

AdrianHB: Seems ok to leave it up to the browser when the user makes a selection...one or more event handler will be fired..if it's N > 1 then there's no option id

JakeA: I would advise against a solution of firing multiple service workers at once

AdrianHB: Imagine I am bankA and the user has in their wallet the ability to pay with PayPal and also a bank card
... I might separate event handlers ... one for PayPal and one for card
... if both options are not displayed to the user, when user picks bankA, one approach was "fastest to respond wins"
... Marcos indicated that's how fetch works

JakeA: That's not how fetch works.
... I don't think we should create a system where the browser provides a partial answer
... the whole benefit of the API is that you go through a large amount of the flow in the browser UI
... if the browser bails at some point, it becomes difficult to test
... and browsers might fail at different points

summary

- we could limit system to not have multiple payment handlers per origin

JakeA: Origin is not the top level...service worker is the top level
... if you are handling payments across multiple SW registrations...if you are racing across events, I think that's too complicated
... if a payment handler is linked to a service worker registration, you can have many of these per origins, but trying to conduct a payment across multiples of those at once seems weird

<AdrianHB> I am hearing, the solution should not allow browsers to invoke multiple handlers for a single user selection

- where options aren't rendered at top level, allow browser to render second level

<JakeA> +1

<AdrianHB> the normative req for that is, if the app registers options you MUST render them to the user

AdamR: The thing to keep in mind is that we also need to handle native apps on mobile devices
... we might be able to convince people that for SW-based apps this is the model, but I think we'll get pushback for native apps

<AdrianHB> how a browsers renders native apps in the user choices is also browser UI decision

<AdrianHB> +1 if you accept options you MUST return an option id in the event

JakeA: All the spec would have to say is that if I have provided a series of options, the user agent must provide the user's selection in the SW event

adamR: It seems reasonable
... this is workable
... as far as the spec goes
... we'll need to convince the browser makers

<AdrianHB> i.e. AdamR persuaded me that an event with an empty option id is okay then JakeR persuaded us all that it's not :)

<JakeA> :D

rouslan: We're not opposed to payment options in principle...if there is a case for them, please present the argument

JakeA: In terms of getting browsers to implement this, going for the simplest thing in a way that allows us to add it later
... take the extensible web approach.

AdrianHB: Thanks for the proposal AdamR

AdamR: I don't think today's conversation affects the proposal as such....
... I think we can probably merge what's in the current spec...but it needs more details

AdrianHB: +1 to merge now

PROPOSED: merge AdamR's PR

(IJ will update the running summary)

RESOLVED: merge AdamR's PR

Next call

28 Feb

Payment Apps Task Force

21 Feb 2017

Attendees

Contents

The model

Adam's proposal re: options

Next call

Summary of Action Items

Summary of Resolutions