See also: IRC log
Proposal (summary of where we are on key issues):
https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
Issues list:
https://github.com/w3c/webpayments-payment-apps-api/issues
<adamR> Changes: https://github.com/w3c/webpayments-payment-apps-api/pull/104/commits/dc913b844e131a5f5c3156a41328da1154f2dee8
<adamR> To see the changes rendered in situ, see https://adamroach.github.io/webpayments-payment-apps-api/ — section 7
https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
https://github.com/w3c/webpayments-payment-apps-api/issues/98#issuecomment-280652989
=> https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
"A payment app is a Web application that manages payment requests on behalf of the user by supporting one or more payment methods. "
Lots of things we need to sew together:
* relation to web app
* relation to options
* relation to service workers
* relation to origin
* location of code
* identifiers for matching
* registration
<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: 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
+1
(IJ will update the running summary)
RESOLVED: merge AdamR's PR
28 Feb