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

Re: Credit transfer next steps

From: Adrian Hope-Bailie <adrian@hopebailie.com>
Date: Wed, 3 May 2017 02:29:08 -0700
Message-ID: <CA+eFz_+rfStdzx5b_4yU8QEC25+dA+WwdTDiW_WCxtkTAPUGuQ@mail.gmail.com>
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>
On 2 May 2017 at 08:13, Anders Rundgren <anders.rundgren.net@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.

That's a fair question. I think it would be useful to understand if support
for new payment methods entails:
1) Simply adding the identifier (short-string) to a list of allowed values
2) Putting data validation logic into the browser to ensure that the
payment method data is valid

Assuming it is just 1 then it's difficult to be sure that the data passed
to the payment apps will be valid. I will put this on the agenda for our
call this week to get some insight from the browser vendors.

> 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/webpay
>> ments-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 Wednesday, 3 May 2017 09:29:42 UTC

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