Re: Review of Payment Apps Proposal

Hi all -

I'm happy to jump in and provide my perspective on this point:

Ian stated the goal well: Foster an open ecosystem for payment apps
> (including browsers-as-payment-apps but not limited to those).
>
> So, I'd like to hear what the plan is for doing this from the browser
> vendors (if they want to decouple registration from all other specs).
>

Registration has always been a core part of the web payments story for us.
It was even in my original explainer doc
<https://github.com/WICG/paymentrequest/blob/gh-pages/docs/explainer.md>.
We think it's in the best interest for our users (and the web) to give
users the ability to pay in the matter they want to pay. Not to mention
that there are many, many forms of payment out there and it's crazy to
think we could (or would want to) provide support for all of them as a
browser.

Our goal is to make it easy for users to pay for things on the web. This
includes support for the registration of payment apps. That said, our plan
has always been to approach this problem pragmatically.

We need to build a strong foundation and demonstrate value with
PaymentRequest. This means shipping experimental versions of PaymentRequest
on the web platform, getting merchants testing it, getting feedback, and
working that feedback into the spec. We have no intention of building an
API no one can use.

We also need to be cognizant that we're not developing this API in a
bubble. There's a competitive ecosystem at play with new device-level
payment apps emerging all the time. If we have a good standard for the way
these payment apps can play in the browser (even if at the beginning it's
not as open as we would like), this is still fundamentally good for the
ecosystem, especially if the opposite scenario is a variety of proprietary
payment APIs making their way into browsers.

This is why I sent an email to the public list last week emphasizing that
we need to prioritize getting answers to some of the open questions around
PaymentRequest (especially those that affect the fundamental shape of the
API and its interactions).

We strongly hope (and will push for) a registration spec to be developed in
parallel. So once we're confident in the shape of PaymentRequest, we can
quickly turn and focus our efforts to getting support for registration
built inside of the browser to do the same process again (i.e. ship
experimental versions, get feedback from payment app developers, iterate on
the spec, etc). We also think it will be easier to convince payment
providers to develop Payment Apps if we can demonstrate proof of
PaymentRequest adoption in the wild.

Thanks,

-Zach

On Fri, Apr 22, 2016 at 10:09 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 04/22/2016 12:40 PM, Dave Longley wrote:
> > On 04/22/2016 12:16 PM, David Illsley wrote:
> >> I don't think I understand how browsers can be prevented from
> >> allowing payment without supporting registration?
> >
> > They can't be prevented from doing anything (unless we're talking by
> >  force of law) -- they just won't be compliant with the spec.
>
> I agree with the statement above, but not this one:
>
> > The spec should reflect what is best for users.
>
> This is not always the reality at W3C (and other SDOs). Rather than
> getting into all the details, I'll cite:
>
> * HTML5 and the WHATWG
> * The conflict around the Fetch proposal
> * Encrypted Media Extensions
>
> Once you have two or more very large players in any market colluding (or
> agreeing to head in the same direction), what all of the other players
> think is irrelevant.
>
> The spec should reflect reality - what the browser vendors are willing
> to ship, otherwise it's a work of fiction.
>
> That said, it's in the browser vendor's best interest to avoid a
> situation where they are the gatekeepers for payment apps as things get
> nasty when folks like the EU steps in, see:
>
> * EU vs. Google - Right to be Forgotten[1]
> * Microsoft Corp v. European Commission - Browser Unbundling and the
> resulting €561 million non-compliance fine[2]
>
> Ian stated the goal well: Foster an open ecosystem for payment apps
> (including browsers-as-payment-apps but not limited to those).
>
> So, I'd like to hear what the plan is for doing this from the browser
> vendors (if they want to decouple registration from all other specs).
>
> -- manu
>
> [1]https://en.wikipedia.org/wiki/Right_to_be_forgotten
> [2]https://en.wikipedia.org/wiki/Microsoft_Corp_v_Commission
>
> --
> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: The Web Browser API Incubation Anti-Pattern
> http://manu.sporny.org/2016/browser-api-incubation-antipattern/
>
>