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

On Tue, Mar 10, 2020 at 1:11 AM Anders Rundgren <
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.