Re: Calendar invitation for remote-first WPWG meeting (30 March - 2 April)

Dear Danyao,
Thank you for your elaborate response!

The primary (UX related) issue with Open Banking is described here:
https://www.linkedin.com/posts/andersrundgren_security-fintech-payments-activity-6627089570297069568-qAny

This could be addressed if Mobile Banking Applications were built on top of state-of-the-art Web technologies like WPA but currently they are [generally] not.

Due to the fairly universal desire to support omnichannel payments, this seems like a rather unlikely development as well.

If we stick to the Web, a PaymentRequest solution for the Desktop/Web + Mobile Wallet scenario appears to be a more universal target than Open Banking.  Yes, even Google Pay could use it :)

Best
Anders



On 2020-03-16 22:23, Danyao Wang wrote:
> 
> 
> On Tue, Mar 10, 2020 at 1:11 AM Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
> 
>     On 2020-03-09 23:36, Nick Telford-Reed (w3c) wrote:
>      > Hi everyone
>      >
>     <snip>
>      >
>      >     Here is a proposed agenda (details to follow):
>      >
>      >       - 30 March: Payment request and payment handlers
>      >       - 31 March: SRC
>      >       - 1 April: Authentication (both WebAuthn WG updates and joint task force discussion)
> 
>      >       - 2 April: Open banking
> 
>     This minimalist video clip https://www.youtube.com/watch?v=SXiRhCAYRCE published by the OBIE presumably represents the current state-of-the-art for payments using Open Banking.
> 
>     It shows two rather specific characteristics:
>     - You need to (in some way) tell the Merchant which Bank you use
>     - You authorize the payment request with the Bank's mobile banking application
> 
>     It is not very clear where PaymentRequest fits in.
> 
> 
> It's not clear to me in this demo, whether the ordering of coffee is meant to simulate an offline purchase in a physical store or online at a web store.
> 
> For online purchase, the flow of checkout -> select bank -> scan QR code is actually very similar to some existing online flows that involves native payment apps, e.g. LINE Pay. As demoed, the user needs to manually open the correct banking app on their phone, scan the QR code before they can authorize the payment. The merchant also need to do a bank-specific integration such as redirecting to a bank-specific page that displays the QR code and is capable of redirecting back to the merchant page once a notification of successful authorization is received from the user's app.
> 
> Payment Request can potentially streamline both user and merchant steps:
> 
>   * After the user chooses a bank on the merchant website, the merchant fires off a Payment Request with the appropriate payment method (e.g. https://ozonebank1.com), and the browser automatically activates the user's banking app for authorization.
>   * Merchant frontend receives a standard PaymentResponse when the user finishes the flow inside the payment handler (i.e. the banking app). 
> 
>     Note that whatever solution you come up with it must also work (as in the video clip) in physical stores.
> 
> 
> I see the argument that it is suboptimal if payment app developers have to build separate support for online and offline flows. I think it's a fair design goal to make sure payment app integration with Payment Request API (either via Payment Handler API or native app integration) is as easy as possible. But I don't think supporting offline purchase flows is generally in scope for Web Payments APIs.

Received on Tuesday, 17 March 2020 06:49:25 UTC