- From: Adrian Hope-Bailie <adrian@hopebailie.com>
- Date: Tue, 2 May 2017 01:48:13 -0700
- To: Anders Rundgren <anders.rundgren.net@gmail.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: <CA+eFz_+UePK8PVUzarbzaUmfkoTUyPAbj0gboko_dCgxLqftcg@mail.gmail.com>
On 1 May 2017 at 22:15, Anders Rundgren <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>> >> 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/ >> >> * 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/ >> >> -- >> Ian Jacobs <ij@w3.org <mailto:ij@w3.org>> >> https://www.w3.org/People/Jacobs/ >> Tel: +1 718 260 9447 <tel:(718)%20260-9447> >> >> >> >> >> > >
Received on Tuesday, 2 May 2017 08:48:47 UTC