Re: Credit transfer next steps

On 2017-05-03 11:29, Adrian Hope-Bailie wrote:
>
> On 2 May 2017 at 08:13, Anders Rundgren <anders.rundgren.net@gmail.com <mailto: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.

IMHO, the browser only needs to validate the core syntax, the rest is up to each payment application
to validate and act upon.  If we take the credit transfer draft, I would assume that all these ISO 20022
specific elements are passed as an (for the browser) opaque object in PaymentMethod.data.  This is why
I earlier asked about the motives for mandating payment method specific data to be expressed in WebIDL
rather than in JSON.

Option #2 is based on the idea that the browser validates input data for each supported
method which in turn is related to having a list of "allowed" identifiers, right?  Personally,
I wouldn't settle for hard-coded schemes unless someone was pointing with a gun at me :-)

This isn't really a browser vendor specific question, it is rather about how you enable new
payment methods and systems without too much pain.

If option #2 essentially is a security feature, the attack vectors ought to be thoroughly
examined (including possible countermeasures), before "final API freeze".

I will now stand back and see where this goes :-)

Anders

>
>
>
>     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> <mailto: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>> <mailto: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/> <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/> <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>> <mailto: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/> <https://www.w3.org/People/Jacobs/ <https://www.w3.org/People/Jacobs/>>
>                     Tel: +1 718 260 9447 <tel:%2B1%20718%20260%209447> <tel:%2B1%20718%20260%209447> <tel:(718)%20260-9447>
>
>
>
>
>
>
>
>
>

Received on Wednesday, 3 May 2017 12:17:53 UTC