Re: State of "payment-method-credit-transfer"

Hi Anders,

Do you have a video or a GIF of the PoC?

Cheers,
Rouslan

On Sun, Nov 3, 2019 at 1:56 AM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> Hi List,
>
> Regardless of the merits of
> https://w3c.github.io/payment-method-credit-transfer/ the cost for
> integrating a new scheme in a bank environment is simply put prohibitive.
> The only realistic way ahead seems to be building on Open Banking APIs
> which also provides the (currently missing) security solution.  This would
> though require a major revision of the draft.
>
> Having seen a few demos of payment systems using Open Banking APIs, I note
> that they are behind in user-experience compared to state-of-the-art
> systems like Apple Pay.  This is not due to laziness or incompetence of the
> developers, but rather stems from the fact that Open Banking APIs such as
> FAPI [1] primarily targeted third-party "Financial Services" which is quite
> distinct from Payments in a shop.  Analogy: EMV-cards were designed for
> payments using a specific account and associated key combining security and
> convenience, while login to a bank for paying an invoice usually requires
> another authentication solution and UI.
>
> To neither have to "boil the ocean" nor have to accept second-class
> user-experiences, I have developed a proposal for "tweaking" Open Banking
> APIs:
>
> https://github.com/cyberphone/doc/blob/gh-pages/payments/dual-mode-open-banking-api.md#background
>
> In addition, I have created a working PoC using an Open Banking "sandbox"
> [2] which verified my initial hunch that this is both simple and efficient.
>
> WDYT?
>
> Thanx,
> Anders
>
>
> 1] https://openid.net/wg/fapi/
> 2] https://github.com/cyberphone/swedbank-psd2-saturn
>
>