thirdparty-scheme-adapter & sdk-scheme-adapter working together to implement PISP Transfer

[eoln]

We want to implement e2e test for PISP Transfer as described here

We already have PISPTransactionModel which implement three phases of PISP Transfer -> Lookup, Initiate, Approve: source code

We already have modified OutboundRequestToPayTransferModel in sdk-scheme-adapter so it allows us to make a transfer with PISP Authorization source code

Let put in tandem both adapters to implement PISP Transfer flow orchestrated by PISPTransactionModel

But first, we need to extend thridparty-scheme-adapter (DFSP side) and expose POST /thridpartyRequests/transaction at Inbound service (3p-sa-in) where we will invoke a synchronous call on sdk-scheme-adapter POST /requestToPay when 3p-sa-in will receive the response from this sync call it will make a call to PATCH /thirdpartyRequests/transactions/123 to inform the PISP about the results.

Already OutboundRequestToPayTransferModel is listening on /requestToPay, and it starts the workflow with request for quote from Payee DFSP. After receiving a quote it requests the authorization form PISP POST /authorization, and when it comes back it uses synchronous call POST /verify-authorization to decide should the transfer be started or not.

So let implement synchronous endpoint/verify-authorization on thirdparty-scheme-adapter at Outbound service which will use an asynchronous interface and do a roundtrip to auth-service via POST/PUT /thridpartyRequests/tranctions/{ID}/authorization which will realize the authorization verification algorithm

When OutboundRequestToPayTransferModel will receive the response from /verify-authorization will do the transfer, and will inform in synchronous response on POST /requestToPay the 3p-sa-in about the result so it can initiate the PATCH notification call to PISA and when received PISPTransactionModel will also ends its final phase.

[eoln]

This is requestToPayTransfer (Merchant initiated) flow used but it can easily be adapted to P2P if so instead OutboundRequestToPayTransferModel we will use OutboundTransfersModel.

For all cases, there will be a need to inform sdk-scheme-adapter about the color of transfer (PISP or DFSP) so the Authorization Request and Verification calls will be made after quote received and before starting the transfer. We can do this by adding optional parameters to the payload (to not to harm legacy clients)

[lewisdaly]

Thanks for this Pawel - I like the idea of the scheme adapters interfacing with one another using the outbound API only.

A few other things:

1. The PATCH /thirdpartyRequests/transactions/123 should be configurable - in the full switch scenario, it's the switch who will take care of this call, but this is a good shortcut for testing without a switch
2. As we discussed mentioned POST /requestToPay will need a parameter for "PISP Mode", but let's worry about that elsewhere, and stick to the environment variable configuration for PISP Mode for now.
3. POST /verify-authorization isn't a very resty-name (and I also don't like the dash), is there a better name we can think of for this resource? At the least it could be POST /verifyAuthorization

Were there any other notes from the call after I had to drop off?

[eoln]

ad 1.

Thanks for this Pawel - I like the idea of the scheme adapters interfacing with one another using the outbound API only.

A few other things:

1. The PATCH /thirdpartyRequests/transactions/123 should be configurable - in the full switch scenario, it's the switch who will take care of this call, but this is a good shortcut for testing without a switch

yes let add a env variable or use the additional (optional) property in the payload to POST /thridpartyRequests/transaction

2. As we discussed mentioned POST /requestToPay will need a parameter for "PISP Mode", but let's worry about that elsewhere, and stick to the environment variable configuration for PISP Mode for now.

+1

3. POST /verify-authorization isn't a very resty-name (and I also don't like the dash), is there a better name we can think of for this resource? At the least it could be POST /verifyAuthorization

camels rulez everywhere and eat all dashes

Were there any other notes from the call after I had to drop off?

@sridharvoruganti pointed out that P2P scenario should also be covered