W3C home > Mailing lists > Public > public-payments-wg@w3.org > November 2019

Re: [External Sender] Re: State of "payment-method-credit-transfer"

From: Robert Martin <robert.martin@capitalone.com>
Date: Tue, 12 Nov 2019 14:32:50 -0500
Message-ID: <CAHx4b2A-KQHUk4ewTLactWZqW64xmWZN0z2e-zz+Q6UWsJZDiA@mail.gmail.com>
To: Anders Rundgren <anders.rundgren.net@gmail.com>
Cc: Rouslan Solomakhin <rouslan@google.com>, Web Payments Working Group <public-payments-wg@w3.org>, VIGNET cyril <Cyril.VIGNET@bpce.fr>, KUNTZ Vincent <Vincent.KUNTZ@swift.com>, Matt Saxon <matt.saxon@gmail.com>
Hey all, question from a bit of a "noob":

What's the business value from the Open Banking API approach?  Are we
shooting for an easier (and more cost effective) integration to support
bank bill pay use cases?  Do you envision any other meaningful use cases
from this approach?


Rob Martin (Capital One)

On Tue, Nov 5, 2019 at 11:33 PM Anders Rundgren <
anders.rundgren.net@gmail.com> wrote:

> On 2019-11-04 16:17, Rouslan Solomakhin wrote:
> > Hi Anders,
> Hi Rouslan & Co,
> >
> > Do you have a video or a GIF of the PoC?
> That's a very good idea so I will try to create a video ASAP.
> In the meantime you may take a look at this very short clip produced by
> Open Banking in the UK:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.youtube.com_watch-3Fv-3DSXiRhCAYRCE&d=DwIDaQ&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=R42TiJiw1bu1swc_YHON4DY1ld3RTyHDVDaCImek898&m=JdPNzyWYpd8hA8tF07zgwrdzWPUqD-Gcmsfiz_fANa0&s=DtfpcPoM_SKaASB7fParuv-RowiscH3srxT8BVQhbbg&e=
> Particularly noteworthy is that bank selection is performed in the
> MERCHANT environment.
> Using a "Wallet" concept like Google Pay, Apple Pay and Saturn everything
> needed is in YOUR own local environment.
> The reason why Open Banking doesn't come with a "Wallet" is because it is
> based on OAuth2 which is a server-centric and moves the authentication to
> on-line banks.
> The additional mode of Open Banking APIs I'm proposing uses a security and
> interaction model which is closer to EMV which is a user-centric scheme.
> If somebody wants to the "kick the tires" of the prototype, it is
> currently available on the public web:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__mobilepki.org_swedbank-2Dpsd2-2Dsaturn&d=DwIDaQ&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=R42TiJiw1bu1swc_YHON4DY1ld3RTyHDVDaCImek898&m=JdPNzyWYpd8hA8tF07zgwrdzWPUqD-Gcmsfiz_fANa0&s=St-txMUkGcBamxNbFxmBzIb1C0Ip7kTlORhD5sYJloI&e=
> It (of course) uses the PaymentRequest-4-Android API :)
> The LIS (Local Integration Service) code took < 40 *calendar days* to
> write.  Given the fact that I had ZERO previous experiences with Open
> Banking, I would say that this is a really simple solution.
> Kind regards,
> Anders Rundgren
> >
> > Cheers,
> > Rouslan
> >
> > On Sun, Nov 3, 2019 at 1:56 AM Anders Rundgren <
> anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>
> wrote:
> >
> >     Hi List,
> >
> >     Regardless of the merits of
> https://urldefense.proofpoint.com/v2/url?u=https-3A__w3c.github.io_payment-2Dmethod-2Dcredit-2Dtransfer_&d=DwIDaQ&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=R42TiJiw1bu1swc_YHON4DY1ld3RTyHDVDaCImek898&m=JdPNzyWYpd8hA8tF07zgwrdzWPUqD-Gcmsfiz_fANa0&s=H8UHuJPTUbOlv3qLOJDq1AW77HHzFngZrE7TkePNA3Q&e=
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cyberphone_doc_blob_gh-2Dpages_payments_dual-2Dmode-2Dopen-2Dbanking-2Dapi.md-23background&d=DwIDaQ&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=R42TiJiw1bu1swc_YHON4DY1ld3RTyHDVDaCImek898&m=JdPNzyWYpd8hA8tF07zgwrdzWPUqD-Gcmsfiz_fANa0&s=5ImOrGzEJPs2rVo398GYx-6t0NCG3DTh8CZEQ_xU8-g&e=
> >
> >     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://urldefense.proofpoint.com/v2/url?u=https-3A__openid.net_wg_fapi_&d=DwIDaQ&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=R42TiJiw1bu1swc_YHON4DY1ld3RTyHDVDaCImek898&m=JdPNzyWYpd8hA8tF07zgwrdzWPUqD-Gcmsfiz_fANa0&s=m4HkzGbGi4aG1W62AiDlDhQRUCQBkIWyWfQwMnQk9ds&e=
> >     2]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cyberphone_swedbank-2Dpsd2-2Dsaturn&d=DwIDaQ&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=R42TiJiw1bu1swc_YHON4DY1ld3RTyHDVDaCImek898&m=JdPNzyWYpd8hA8tF07zgwrdzWPUqD-Gcmsfiz_fANa0&s=VmDyuxwzCFOsADQjI2gq4F7m-ACkmrgWm3UZ9MBg5fs&e=
> >

Robert Martin
Senior Manager - xCEL (xCommerce, EMI, Lab) Strategy
Capital One
804-432-4240 (M)


The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
Received on Tuesday, 12 November 2019 19:37:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:43:34 UTC