Payment Apps Task Force

18 Apr 2017

See also: IRC log


ConorH, Ian, alyver, jnormore, rouslan, AdrianHB, Christian, Joseph, MattS, adamR, Ken



[Joseph Xu]

scribe: first time on the call.

<ConorH> Welcome Joseph :)


Recent changes to Payment Handler API


* 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!)

Adrian's edits


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



Payment App? Handler? Manager?


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)?


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

Seeking additional reviewer

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

Status wrt FPWD

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


<ConorH> +1

<adamR> +1

Implementer update

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/

Next meeting

2 May

<rouslan> +1

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2017/04/18 14:50:00 $