Re: Sanity check on API using flows from Flows Task Force

Matt,
I absolutely agree with what your propose hereunder (return a pending...).

As regards the PISP, that's already a problem: for example, a quite 
successful PSP in Germany, SOFORT, proposes to pay by transfer, and it 
is of broad use among the shoppers. And the problem is that (strong) 
authentication is not thoroughly satisfied at present. SOFRT is nothing 
but a PISP...And the PSD2 is catching up with the realities of the market.
In the very next future, paying by transfer should be much more 
widespread than today.
Regards,
Fred.

Le 17/02/2016 12:59, Matt Saxon a écrit :
>
> Fred,
>
> Thanks for the observations, I agree with them.
>
> However it should be noted that the Flows as documented by the Flows 
> Taskforce are current flows in use in the wild, the PISP, PSD2 flows 
> are future flows. We need to address both as we can assume that 
> everyone will have migrated to the new flows IMO.
>
> I believe the current flow should  be handled by allowing the API to 
> return a ‘pending settlement’ status or similar so the merchant can 
> wait for the async notification before providing the agreed services.
>
> Regards,
>
> Matt.
>
> *From:*Frédéric Meignien [mailto:frederic.meignien@cantonconsulting.fr]
> *Sent:* 17 February 2016 11:38
> *To:* Manu Sporny; Web Payments WG
> *Cc:* VIGNET cyril; Jean-Yves Rossi; Paddy Ramanathan; 
> evert.fekkes@rabobank.nl; David Ezell
> *Subject:* Re: Sanity check on API using flows from Flows Task Force
>
> Hello,
>
> There is indeed a real problem when we try to apply the API to the SCT:
>
> 1/ The basic logic of the SCT does not work with a web API
>
> -SCT is mainly a batch flow (it's quite difficult to say that such a 
> flow is managed by a payment app)
>
> -For that reason, it is impossible to embrace the flow in a browser 
> logic: the API cannot consider that:
>
> o// once this is called, Steps #3-#12 are executed by the payment app
>
> in fact, the process is interrupted when the transfer initiation 
> message is done.
>
> -That is why the SCT flow represented in PlantUML in GitHub shows a 
> shopper who quits the Merchant website to go to his home banking to 
> order his transfer.
>
> -This is why the API has no work to do…
>
> 2/ The API should be applied to a reconfigured SCT flow
>
> Some PSP propose a webized SCT: this is done by turning into real-time 
> flows Steps 9 and 10 (transfer initiation and report). This allows to 
> have a fluid real-time process by embedding all the shopper dialog of 
> initiation in one "frame".
>
> This flow becomes especially important when we introduce the new 
> entity created by PSD2, e.g. the Payment Initiation Service Provider.
>
> The rest of the process (inter-bank clearing and notification) remains 
> based on batch flows triggered later.
>
> But the flow logic has to be drawn  differently to represent this 
> case. (I a preparing a new document, which makes the link between this 
> problem and the emergence of Payment Initiation Service Providers will 
> present such flows; Cf. "PISP under PSD2 - SCT flows - Merchant 
> PISP.pml" and "PISP under PSD2 - SCT flows - Shopper PISP.pml").
>
> 3/ The authentication framework is absent
>
> But then remains the biggest part of the problem, which is the 
> authentication methodology.
>
> A difference between a card and an SCT is that a card includes an 
> authentication mechanism, while a transfer does not.
>
> A consumer who enters his IBAN on a "transfer HTML page" is not at all 
> doing a "strong authentication".
>
> And the PSP site who sends the resulting message to the shopper's bank 
> has no way to prove to the bank that it was the authentic customer who 
> made this operation.
>
> No regulatory instance defined a methodology to solve this…Which means 
> that there is, at present, no standard for a e-SCT.
>
> This is where Cyril's proposal (SCAI) comes to address this big 
> shortcoming.
>
> By providing a "generic" framework of authentication for any payment 
> instrument in the initiation phase, it makes it possible to create a 
> e-SCT based on:
>
> -Real-time messages
>
> -A flow logic embedding the authentication data between the 3 actors 
> of the initiation: Bank of the shopper, Shopper, and PSP of the Merchant.
>
> Le 12/02/2016 23:51, Manu Sporny a écrit :
>
>     Hi Matt and the rest of the Flows Task Force,
>
>     In order to get a sanity check on the Web Payments CG Browser API
>
>     proposal, we've started checking the API against the flows that the
>
>     Flows Task Force has been working on. We're doing this by writing code
>
>     that uses the payments API to match the flows. The result can be found here:
>
>     http://wicg.github.io/web-payments-browser-api/#flows-addendum
>
>     We've integrated the legacy card, tokenized card, SEPA Credit Transfer,
>
>     and basic Bitcoin flows for now. The good news is that there is very
>
>     little variation between each payment scheme so far (which demonstrates
>
>     that the API is fairly generic, which is a good thing).
>
>     We'd be interested in your feedback. For example, we think we've made a
>
>     mistake in the PSP-mediated SEPA Credit Transfer use case, but can't
>
>     quite figure out where.
>
>     In any case, just a heads up that we've started integrating the flows
>
>     and apologies for taking so long to get around to this.
>
>     -- manu
>
>
>
> ------------------------------------------------------------------------
> Avast logo <https://www.avast.com/antivirus>  
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <https://www.avast.com/antivirus>
>
>