W3C home > Mailing lists > Public > public-payments-wg@w3.org > May 2017

Re: Credit transfer next steps

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Tue, 2 May 2017 17:13:37 +0200
To: Adrian Hope-Bailie <adrian@hopebailie.com>
Cc: Zach Koch <zkoch@google.com>, Ian Jacobs <ij@w3.org>, "Saxon, Matt" <Matt.Saxon@worldpay.com>, VIGNET cyril <Cyril.VIGNET@bpce.fr>, KUNTZ Vincent <Vincent.KUNTZ@swift.com>, KETELS Kris <Kris.KETELS@swift.com>, Adrian Hope-Bailie <adrian@ripple.com>, "Albers, Todd" <Todd.Albers@mpls.frb.org>, Frank Hoffmann <frank.hoffmann@klarna.com>, Payments WG <public-payments-wg@w3.org>
Message-ID: <8be65632-2f0e-f1e0-9c65-446c599a8c93@gmail.com>
On 2017-05-02 10:48, Adrian Hope-Bailie wrote:

Hi Adrian,

I don't disagree with what you write but my core claim was simply that
there's nothing specific to implement "inside of Chrome" to cite Zack,
in order to support credit transfers and similar push scenarios.

If this is wrong, it might be useful trying to describe what's missing as
a first step. Well, maybe that's completely obvious to everybody but me?

Anders

> On 1 May 2017 at 22:15, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     On 2017-05-02 02:27, Zach Koch wrote:
>
>         It's not super hard for us to implement (i.e. add support for) inside of Chrome.
>
>     > But the key thing is to have integrators lined up on both sides (merchants + payment apps).
>
>     It is course your project and headache but AFAICT there is no need bringing in
>     specific credit-transfer related data in dedicated browser objects if you (re)define
>     the result of the payment request as "authorization" and leave "execution" to a
>     subsequent step taking place on the server.
>
>
> The Payment Request API intentionally does not differentiate between these. This API is simply an exchange of data between the website and some other application.
>
> The payment method (in this case Credit Transfer) specifies the the data models exchanged in the request and the response. Whether the response is a proof of execution or just authorization is payment method and use case specific.
>
>
>     It might be useful knowing that SEPA credit transfers currently are non-realtime
>     (sometimes takes days) which (IMO) calls for a "receipt" of some kind telling that
>     the transaction request has been accepted and is "in progress".  I believe this
>     method can be applied to any push-like scheme, be it realtime or not.  It should
>     also work for invoice-based schemes (Klarna?) which by definition are not realtime.
>
>
> I think the concept of "real-time" is misunderstood. A card payment is not real-time in the sense that the money is not instantly available to the merchant and yet this hasn't proven to be a problem.
>
> This payment method is not specific to a scheme. I suspect the schemes will define what the business rules are around the different requests and responses.
>
>
>     In fact, I believe the existing payment API can do this right out of the box!
>
>     Anders
>
>
>
>         -Zach
>
>         On Mon, May 1, 2017 at 2:39 PM Ian Jacobs <ij@w3.org <mailto:ij@w3.org> <mailto:ij@w3.org <mailto:ij@w3.org>>> wrote:
>
>             [Zach see implementation question for you]
>
>             Hi all,
>
>             Here is a summary of points made about next steps for Basic Credit Transfer Payment [1]:
>
>             * We have a few issues:
>               https://github.com/w3c/webpayments-methods-credit-transfer-direct-debit/ <https://github.com/w3c/webpayments-methods-credit-transfer-direct-debit/>
>
>             * BPCE, Worldpay, and Klarna indicated at the Chicago meeting that they are potential implementers.
>               Google also expressed interest in this payment method. Zach, how does that interest translate to
>               implementation?
>
>             * We should get more feedback from credit transfer systems. I note that Unify/Atos has just joined the WPWG
>               and I look forward to hearing from them on this spec.
>
>             I think for some people in cc, PR API and Payment Handler are currently a higher priority. But I’d like
>             to make some progress on the issues (e.g., via pull requests).
>
>             If people think it would be useful, I can organize a 30-minute call to organize. Or we could use a portion
>             of the Thursday call this week or next, if the Chairs think that would be useful.
>
>             Ian
>
>             [1] http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/ <http://w3c.github.io/webpayments-methods-credit-transfer-direct-debit/>
>
>             --
>             Ian Jacobs <ij@w3.org <mailto:ij@w3.org> <mailto:ij@w3.org <mailto:ij@w3.org>>>
>             https://www.w3.org/People/Jacobs/ <https://www.w3.org/People/Jacobs/>
>             Tel: +1 718 260 9447 <tel:%2B1%20718%20260%209447> <tel:(718)%20260-9447>
>
>
>
>
>
>
>
Received on Tuesday, 2 May 2017 15:14:14 UTC

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