Re: OBJECTION: Call for Consensus to publish Payment Request API as a Proposed Recommendation - reply requested before 27 January

Hi Anders,

Your objection is noted, however almost everything you have said is
incorrect.

On behalf of the chairs I'd appreciate it if you did some more research
before passing your opinions of the WG's work off as facts which you
continue to share widely despite being regularly corrected:

1. PaymentRequest API is implemented in Chrome, Edge and Safari.

As you can see from the latest WPT results not all tests are passing yet in
all 3 browsers but this is being worked on between the spec authors and
the browser vendors:

https://wpt.fyi/results/payment-request?label=experimental&label=master&aligned

2. PaymentRequest API can be used to invoke Google Pay in the form of both
an Android app AND a Web-based payment handler using open interfaces that
can be implemented by anyone else. Google represents a single party but
their implementations can be replicated by anyone, they are not using any
proprietary interfaces to invoke Google Pay from the browser.

The purpose of the PaymentRequest API is to provide a context-specific
invocation interface for a payment flow which allows browsers to offer a
variety of handler implementation options.

The evolution of these options is naturally following behind the evolution
of the PaymentRequest API and we are already seeing increased interest in
implementing Payment Handler and other complimentary technologies as
Payment Request matures.

3. The WG, and W3C in general, has spent a great deal of effort to include
input from the wider payment industry in consultation of this work.

This includes the formation of the WPSIG (a collaborative group consisting
of members of FIDO, EMVCo and W3C), and the Merchant Business Group.

We engage with various Open Banking groups and alternative payment
providers.

4. RE: "The most obvious omission is enrollment of payment keys in native
mode payment applications."

It is not in scope for the W3C to provide solutions for native platforms.
Rather we attempt to enhance the Web platform to have the
necessary baseline capabilities to offer the same or better developer and
user experience as native platforms.

The use of WebAuthN technologies for payment confirmation is currently
being experimented with. The project (Secure Payment Confirmation) seeks to
enable the use of hardware-secured keys for confirmation of a payment
authorization by a user including the elusive goal of "Transaction
Confirmation".

All of this work hinges off Payment Request API so I struggle to see how
you can describe PR API as "redundant".

Adrian

On Tue, 19 Jan 2021 at 08:27, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> Dear WG Members,
>
> Since I am not a W3C member you are free to (probably MUST...) dismiss
> this objection.
>
> As far as I can tell, PaymentRequest has low adoption and its "companion
> specification" PaymentHandler [1] even less (in spite of being in the
> workings for several years).
>
> Although PaymentRequest is used by Google for linking the Web to their
> Android-based payment application, Google represents a single party. Other
> potential parties' [2] expectations and requirements have not been
> researched.  The most obvious omission is enrollment of payment keys in
> native mode payment applications.  Due to that "deep links" have rather
> become the norm for bridging the [mobile] Web and native worlds,
> effectively making PaymentRequest redundant.
>
> In retrospect, it is also clear that some of the core features do not work
> as once envisioned, including:
> - Browser-based payment method selection.
> - A common API.
>
> Sincerely,
> Anders Rundgren,
> Independent consultant and innovator in the payment and identity space
>
> 1] In addition to only supporting Web payments, Web security constraints
> make PaymentHandler an awkward solution compared to native mode payment
> applications.
> 2] The bulk of the payment industry do not have W3C representation.
>
>
>