Re: Review of Payment Apps Proposal

I don't think I understand how browsers can be prevented from allowing
payment without supporting registration?

On 22 April 2016 at 01:42, Adam Roach <> wrote:

> On 4/21/16 15:14, Shane McCarron wrote:
> On Thu, Apr 21, 2016 at 2:50 PM, Adrian Bateman < <>
>> wrote:
>> No, in fact I've argued for the opposite. It's entirely reasonable for us
>> to develop v2 of a registration API without having to go back and change
>> a dependency in the Payment Request API. They should be independent so
>> that they can proceed independently.
> Huh?  I really don't understand.  Payment App registration is a
> fundamental requirement of this ecosystem.  The browser payment request API
> would have nothing to communicate with if there are no payment apps
> registered.  Certainly the test environment (as I am designing it)
> registers a payment app with the implementation under test so that we can
> process messages from and to the user agent just as we will model those
> messages from the "payee".  A normative reference in a W3C spec says "this
> spec requires that this other spec be in the environment too, as it DEPENDS
> upon this other spec".  Surely you are not proposing that we push out a
> version of the browser payment api that does not require support for
> payment app registration?
> I'm still coming up to speed on the specifics of the existing proposals;
> however, with the high-level understanding of the basic purpose of the
> payment functions and the registration functions that I do have, I find
> proposals not to make the payment functions strictly dependent on the
> registration functions troublesome.
> I'll reiterate the point that Manu has made: the only way unlinking these
> makes sense is in a world where we envision some implementations that do
> one without the other. Allowing registration without payment is clearly
> nonsense; and allowing payment without registration implies that we're
> going out of our way to accommodate browsers with non-extensible, baked-in
> payment providers.
> And that would be very bad for users.
> --
> Adam Roach
> Principal Platform Engineer
> Office of the CTO, Mozilla

Received on Friday, 22 April 2016 16:17:08 UTC