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
>