Re: [Agenda] 31 Jan 2017 Payment Apps task force call

On 01/30/2017 07:07 PM, Adam Roach wrote:
> On 1/30/17 12:58, Ian Jacobs wrote:
>> Proposed way forward in light of recent threads
>>
>> I have endeavored to synthesize recent discussions and would like to see
>> whether we can get to agreement on a model for payment apps:
>>  https://github.com/w3c/webpayments-payment-apps-api/wiki/Proposal-20170130
>>
>> That proposal includes:
>>
>>  • A proposed way forward
>>  • Issues where we have not yet converged (and commentary on current discussion)
>>  • Suggested resolutions to issues (based on point 1.)
>>
>> Even if there is not yet agreement on those points, I hope that the proposal
>> helps frame the discussion. 
> 
> Thanks, Ian! I have some initial thoughts on this proposal; some aspects
> of it are new to me, though, and may require additional consideration.
> As my general statement regarding the priority of constituencies drew
> fire on the call last week, I have highlighted the two specific
> proposals that I believe are inverting these priorities.
> 
> *Identity*: This is a radical departure in the meaning of "payment app."
> For avoidance of doubt, I would propose ejecting the name "payment app"
> altogether (since we're basically shutting down that concept if we adopt
> this definition), and instead call these "payment web apps."  I have
> also heard non-trivial objections from people regarding the implicit
> limitation here: this would limit a single origin from appearing in the
> "list of things that users select" more than once. If we can get
> explicit payment provider buy-on in this restriction, I'm fine;
> otherwise, I have serious concerns that we're going down a path that
> will be cleaner in the sense of theoretical purity, but fail to meet
> author (merchant and/or payment provider) needs.
> 
> *Registration*: This is a bit unclear. The notion here is that a service
> worker makes itself part of a payment web app by registering for
> payment-related events?

As others have noted, it may be that "payment app" is not the best name
here. It may make sense from an end user's perspective, but is confusing
from other perspectives. I don't have an alternative name, but perhaps
thinking about them in a different way could help us come up with one.

When I hear "payment app", I start thinking that we're talking about
some container for all of the code for a particular software program.
And if the user selects it, then we'll "run that program". I think
that's wrong headed here, given the browser architecture. It creates
artificial restrictions like "only one payment app per origin", or "only
one payment app per Service Worker".

Instead, when the end user makes a selection during payment, all that
really happens is we pass some hints to an origin about what they
selected and what they want to do now. Then there's an expectation for
the origin to handle payment on that basis. We have no say in how that
origin organizes its code. The browser only understands the origin
boundary; we shouldn't be trying to force our conceptual model into the
browser model, we should be layering it on top of it.

I think we should think of "payment apps" as simply a mechanism for
origins to logically organize the entry points into various payment
experiences it offers -- and to surface those entry points to the user
in a way that can be communicated back to the origin when a selection is
made. That's it.

In order to give origins this flexibility, here is a slight tweak to
Ian's proposal:

To start, users must consent to give an origin permission to "handle
payments". This permission grants origins the ability to register as
many "payment apps" as they would like, when they would like, and to
receive payment request events when one of their payment apps has been
selected. This is the only user consent that the browser need to concern
itself with, everything else is governed by the origin itself.

These payment apps are merely used to identify different payment
experiences at the same origin. How code is organized at the origin (the
number of Service Workers, whatever else) is largely unrelated to these
logical groupings.

The origin should register an icon, title, and identifier for each
payment app, as well as a set of supported payment methods. These can be
changed granularly and as the origin sees fit. The origin may also
potentially register additional icon and title information along with
the payment methods so the browser may implement a more granular
selection screen (and reduce the number of clicks a user must make to
get through the process).

The origin may ask the user for consent to register these payment apps,
but this has nothing to do with any browser API. It's entirely up to the
origin to decide how to implement this on their site. If they provide a
good experience, the user won't revoke the origin's permission to handle
payments.

Taking this approach would enable a number of previously mentioned use
cases, such as allowing the same origin to provide a "Personal Banking"
experience and a "Business Banking" experience or allowing a service
provider/aggregator origin to provide a number of different
white-labeled payment experiences.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Tuesday, 31 January 2017 03:27:16 UTC