Re: Credit transfer next steps

On 2 May 2017 at 08:13, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> 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
OR
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>
>>
>>
>>
>>
>>
>>
>>
>>
>