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

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
 

 



---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus