Re: PaymentRequest traction. Re: [Minutes] 27 June 2019 WPWG teleconference

On 2019-06-28 16:40, Danyao Wang wrote:
> Hi Anders,
> 
> I agree with you very much that we also need to work with payment apps to bootstrap the ecosystem. My current mental model is that Payment Handler API [1] is the extension point to bring on more payment apps.

Thanx Danyao,

Since nobody has chimed in on this issue I guess the WG members are not particularly interested in this topic.

I believe a very simple market research effort would reveal that the payment industry in general (which to 99.99% is not represented in the W3C), indeed put their money on native payment apps.  These apps also target P2P payments so it seems rather unlikely that this trend will change anytime soon, if ever.

Using PaymentHandlers as interfaces ("glue") to native apps may be technically possible but they also introduce "unwanted side effects" which makes the current *widely deployed* QR solutions a better choice although they cannot really use PaymentRequest in a meaningful way.  Adding an open ended solution like Web Bluetooth to the plot would add yet another level of fuzziness.

As I wrote in the GitHub issue most of the work has already been done by the FIDO Alliance and Google. PaymentRequest should (famous last words...) not be fundamentally different to U2F with respect to messaging and UX considerations.

Best regards,
Anders

> 
> Your earlier idea about a bluetooth payment app [2] is very interesting. What do you think about prototyping it by creating a web-based payment handler (i.e. a service worker) that handles the communication with a phone payment app via bluetooth? It feels possible given things like Web Bluetooth API [3]. It'll be interesting to learn what are the challenges of this approach before we attempt to standardize browser/OS/device communication.
> 
> [1] https://w3c.github.io/payment-handler/
> [2] https://github.com/w3c/payment-request/issues/865
> [3] https://developer.mozilla.org/en-US/docs/Web/API/Web_Bluetooth_API
> 
> Best regards,
> Danyao
> 
> 
> On Fri, Jun 28, 2019 at 2:21 AM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
> 
>     On 2019-06-27 22:38, Ian Jacobs wrote:
>      > Dear Web Payments Working Group,
>      >
>      > Minutes from today’s call:
>      > https://www.w3.org/2019/06/27-wpwg-minutes
> 
>     Dear Payment WG,
> 
>     I understand that you see Merchants as the primary "driver" for PaymentRequest.
> 
>     However, Merchants cannot really do that much outside what PSPs and Banks support.
>     The latter continue investing in [native mode] Mobile payment systems because it does in their opinion not make sense to have specific solutions for the Web.  In fact, most of them are targeting the entire spectrum of consumer payments, including P2P.
> 
>     A noteworthy characteristic of Mobile payment applications is that they come with *built-in security solutions*.  This presumable also has implications with respect to FIDO2/WebAuthn for payments.
> 
>     If you want PaymentRequest to get more traction your best option may be creating a "bridge" between the PC/Web and the mentioned Mobile payment systems like outlined here:
>     https://github.com/w3c/payment-request/issues/865
> 
>     If you can achieve a working bridge using another method that's fine; but whatever scheme you come up with it has to be *much* better than the existing solutions in order to motivate a conversion.
> 
>     Sincerely,
>     Anders Rundgren
> 
> 
>      >
>      > Next call 11 July:
>      > https://github.com/w3c/webpayments/wiki/Agenda-20190711
>      >
>      > Ian
>      >
>      > --
>      > Ian Jacobs <ij@w3.org <mailto:ij@w3.org>>
>      > https://www.w3.org/People/Jacobs/
>      > Tel: +1 718 260 9447
>      >
>      >
>      >
>      >
>      >
> 
>

Received on Saturday, 3 August 2019 05:54:11 UTC