See also: IRC log
[Joseph Xu]
scribe: first time on the call.
<ConorH> Welcome Joseph :)
https://w3c.github.io/webpayments-payment-handler/
* Updated short name / URL
* Add support for topLevelOrigin and paymentRequestOrigin
* Added 2 diagrams (worked on with MattS). (Can we close 49?)
* Issue markers
* Many markup fixes, tidy (please tidy edits henceforth!)
AdrianHb: My edits were primarily
editorial
... the main thrust of what I was getting at was making it
clear that what the spec defines is this new event
handler
... we are defining a way to response to a particular payment
event
... there's a new feature in the platform (payment handlers)
that handle this new event
... then you build on that - how do I instruct a browser to
raise the event when payment events that I can handle are being
processed?
... that's when you bring in the term PaymentManager
https://github.com/w3c/webpayments-payment-handler/issues/127
https://github.com/w3c/webpayments-payment-handler/issues/127#issuecomment-294713131
Payment App? Handler? Manager?
AdrianHB:
1) Key thing we are defining in the platform is the payment handler. It stand on its own as a feature
scribe: it allows you to process
payment requests. It makes no assumptions about where those
requests originate; they don't HAVE to come through the payment
request API
... the focus is on payment handlers..pieces of code that are
invoked when an event is raised.
2) Another piece of the spec is how we manage metadata about the handlers - methods, instruments, wallets
scribe: I see the PaymentManager
as layering on the handler but not essential to the handler
functionality
... so the PaymentManager is a feature we are adding (to
service worker registration) that qualifies the payment
handler
... I think PaymentManager but we could call it something like
PaymentMethodManager or PaymentInstrumentManager
<MattS> +1 to PaymentInstrumentManager, much more explicit
<MattS> or in fact if thats a mouthful, InstrumentManager
3) A payment app is a specialization of a Web App that uses these features
<adamR> The problem with “InstrumentManager” is that this is going in to the top-level ServiceWorker scope. It needs to make sense in the context of the broader web platform.
<MattS> ok
MattS: I appreciate AHB's
description and Ian's scribing. I think the spec does not
reflect that yet
... the first point is that the spec is called
PaymentHandler...from what you said, the spec should be called
Payment App
IJ: Rationale against Payment App was "too broad"
MattS: Make sense but now too narrow, IMO
<AdrianHb> +1 to PaymentHandlerRequest
MattS: Maybe we need to change
PaymentAppRequest/PaymentAppResponse =>
PaymentHandlerRequest/PaymentAppResponse
... The reason I wanted the diagram was to clarify the entities
etc....the diagrams are missing PaymentManager
adrianHB: PaymentManager exists under service worker...you use it to register to register instruments and wallets
MattS: I suggest we leave 127
open for FPWD...but would be nice to have some consistency for
FPWD
... at a minimum, I suggest we represent PaymentManager in the
diagram (instead of PaymentHandler)
... I will continue to review
IJ: Why not say "one or more payment handler" (cf my proposal)?
https://github.com/w3c/webpayments-payment-handler/pull/138/files
"Payment apps make use of service workers to register their payment handling capabilities with the user agent. This is done through one or more payment handlers, which listen to PaymentRequestEvents raised through the Payment Request API."
IJ: My point is don't say "one"
<MattS> why not say payment apps must each use a service worker
Payment apps make use of (one or more) service workers, each of which defines...
Rouslan: I read the document. I
update the android spec as well.
... I had one small issue, which I will put on github
(IJ has read it)
MattS: I will review the updated
doc
... will review changes by Thursday
[Example updates?]
AdamR: I think one of the
examples is incorrect. There are also stylistic
differences...
... e.g., "await" instead of "then" could be an
improvement...
... I think Marco's improves would probably help a lot
Rouslan: I will look at AHB's javascript
IJ: I would like to start a CfC
around 1 May (for 1 week)
... if all goes well, FPWD week of 8 May
PROPOSED: The task force recommends the Chairs start a CFC for Payment Handler (after last round of edits) around 1 May
<rouslan> +1
<AdrianHb> +1
+1
<ConorH> +1
<adamR> +1
IJ: What are the opportunities implementers will have to play with this?
Rouslan: Chromium has a near
complete implementation of this API.
... we'd like to start experimentation after FPWD
IJ: Any firefox updates?
AdamR: Marcos and Matt have been doing some work...no specific update on progress for today
IJ: Can we institute an implementation focused semi-regular call after FPWD so that user agents and app developers can work together
Conor: +1`
<adamR> Ian: https://github.com/marcoscaceres/web-payments-proto/
<adamR> Ian: and https://marcoscaceres.github.io/web-payments-proto/
2 May
<rouslan> +1