Re: Progressing "PaymentRequest" to TR

Hi Anders,

Thanks for your input. I find it curious that you consider an interface
that depends on concrete implementations to have "no value".
That is, by definition, every standard API defined by W3C and any other
standards body.

Some corrections to a few of your statements which are not correct:

- The Basic Card Payment Method spec is here:
https://www.w3.org/TR/payment-method-basic-card/ and the WG has resolved to
publish this as a Note.
The purpose of this payment method was to bootstrap the PR API and provide
a use case for websites to use it, test it and provide feedback.
In that regard it has served its purpose well.
With the introduction of newer more secure payment methods basic-card is
becoming less useful and will likely be deprecated in favour of these other
payment methods in future.

- "there have been no reports on any major (or even minor) uptake of this
technology."
This is completely untrue. As I've pointed out to you numerous times,
Google Pay is built using this technology (whether you consider that major
or minor is a matter of opinion).
We have also done extensive testing with this API at Coil and plan to roll
out our own product features soon using this API.
A number of other WG members have demonstrated use of the API and my
assumption is that we'll see some of these in the market in due time.

- "this is also pretty much the antithesis of the open Web."
Again, I'm curious as to how you come to this conclusion?
SPC is a mechanism of combining payment initiation with secure
authentication (WebAuthn) facilitated by the browser and platform all using
open APIs and technologies.
What is it about this that is antithetical to the "Open Web"?

- "Apple have more or less set the standard for mobile payment systems in
the western hemisphere."
I'm sure my Apple colleagues will be delighted that you think so and I
would agree that the UX they have put together is excellent and something
to aspire to with open technologies

- "To put things in a slightly simpler wording: it appears to be infeasible
building something along the lines of Apple Pay using PaymentHandler."
From what I've seen of experiments within the WG there are a number of
solutions offering a very similar UX in development and now with
integrated biometric auth thanks to SPC the gap is closing to almost zero
between what is possible with open Web standards and closed vendor specific
solutions.
Obviously making all this work using open technology and standards is
harder and is taking some time to get right but I'm personally very
optimistic about the progress.

What I think you are missing in your analysis of the WG's work is the
difficult tension between the competing priorities of privacy, security and
user experience.
Finding solutions that balance all three and are not dependent on a closed
ecosystem is difficult, but not impossible.

In my opinion we're making good progress. While you may be ready to give up
on the Web, I'm not.

If you have practical suggestions for our new charter feel please do share
them but also consider that a lot of what you've said here has been clearly
false so please try to accompany your proposals with some justifications
that are founded on facts.

Thanks,
Adrian


On Sun, 15 Nov 2020 at 09:05, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> The Payment WG is in the process making the PaymentRequest API a TR.
>
> That's fine.  What's maybe somewhat less obvious is that PaymentRequest in
> itself has no value since it is just an interface that depends on concrete
> implementations, aka "payment handlers".
>
> For the latter the WG started with browser-based (built in)
> "basic-cards".  This has subsequently been deprecated and is not a part of
> any standard.
>
> After that the ServiceWorker-based PaymentHandler project was launched
> with the goal making it possible to write payment handlers using "pure" Web
> technology.  Although this mission has been running for several years,
> there have been no reports on any major (or even minor) uptake of this
> technology.
>
> In fact, it appears that the to date only "substantial" use of
> PaymentRequest is through the proprietary OS/App-level interfaces to iOS
> and Android provided by Apple/Safari and Google/Chrome respectively.
>
> Recently a new effort called Secure Payment Confirmation (SPC) using
> FIDO2/WebAuthn was launched.  Unlike PaymentHandler, it is based on
> browser-based (built-in) support for parts of a payment authorization
> including the UI.  However, this is also pretty much the antithesis of the
> open Web.
>
> The only reasonable conclusion from all of this is that supporting
> advanced payment systems through "pure" Web technology is not going
> anywhere.  To put things in a slightly simpler wording: it appears to be
> infeasible building something along the lines of Apple Pay using
> PaymentHandler.  Apple have more or less set the standard for mobile
> payment systems in the western hemisphere.
>
> The anticipated charter update ought to take the above in consideration.
>
> Sincerely,
> Anders Rundgren
>
>