- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Sun, 3 Nov 2019 07:55:59 +0100
- To: Web Payments Working Group <public-payments-wg@w3.org>
- Cc: VIGNET cyril <Cyril.VIGNET@bpce.fr>, KUNTZ Vincent <Vincent.KUNTZ@swift.com>, Matt Saxon <matt.saxon@gmail.com>
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
Received on Sunday, 3 November 2019 06:56:06 UTC