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

The "discovery" problem is solved by PR API when the participants in the
ecosystem come together and agree on a standard data model to exchange via
the API and package this as a "payment method" for the Web.

If all the banks agree to this then PR API can be invoked with the payment
method identifier for that standard payment method and the Payment Handler
for the user's bank will automatically be invoked.

Note: PR API assumes that the browser in which the payment is being made is
truly the User's Agent, i.e. It has Payment Handlers registered for the
current user.
It won't work where the UI is a kiosk that is effectively the merchant UI.



On Tue, 17 Mar 2020 at 08:49, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> 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.
>
>
>