-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Thirdparty/PISP APIs and FSPIOP v2.0 #68
Comments
It would be great to understand why these changes are required. As of now these are very high level requests without stating why they are needed by the PISP API as part of a 2.0 version of the FSP Interoperability API. |
Let’s be cautious here about burdening the central ledger with unnecessary handling of the transaction object. Having a transaction service that is signaled internally by the normal central ledger events (in some way) to deliver materials to subscribers might be explored. But we should not burden the central ledger notifications with the full transaction object.
Let me know if we need to discuss further if you think I have misunderstood your proposed change.
— Miller
On Oct 6, 2020, at 8:06 AM, Lewis Daly <notifications@github.com> wrote:
Following up from our discussion today, our current proposal for the PISP API requires changes to how the FSPIOP-API handles the Transaction object, and the contents of the Transaction object.
Our existing proposal includes the following:
Including the Transaction object in plaintext for the PUT /quotes/{id} POST /transfers request
The addition of a subscriptions list, which contains interested parties who should be informed by the switch upon the conclusion of a transaction
Linking together the transactionId, transferId and transactionRequestId in one place
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Hi Miller, Henrik, Thanks for your patience on this one. I didn't want to give a quick, half-baked answer, so I thought it best to wait until after the convening to give me time to "line up my ducks", so to speak. Reasons for FSPIOP-API 2.01. Extend
|
Thanks @lewisdaly, Maybe I missed something, but your comment does not really seem to answer why all the three requirements in the issue are needed:
I can see the answer for nr 2 (the subscription list), but not the others? It would be great if you can explain the reasons behind the other two requirements (nr 1 and nr 3) to the CCB/SIG as well, so that we all have a common understanding and can prioritize any issues accordingly. May I also ask you to explain why the PISP is requesting the transfer from Payer FSP (the customer's FSP), instead of the Payee FSP (the merchant's FSP in case of a merchant initiated payment)? This might very well already be documented somewhere, so feel free to just share a link in that case. If the PISP request was sent to the Payee FSP instead, which would in turn send a normal POST /transactionRequests to the Payer FSP, it seems like there would be no need of a subscription as the Payee FSP would then have the final outcome of the transfer from the Switch and can notify the PISP? I have not analyzed this in detail though, so there might very well be other issues. Kind regards, |
Thanks @ehenrka For #1 - I will leave for @MichaelJBRichards to comment on. I think this was a concern for the efficiency of processing transfers, since we will need to decode the transaction object to obtain the list of subscribers. As for #3, yes I realize now I didn't go into enough detail there. The PISP knows nothing about the underlying The
I think this was the way we always looked at the problem, given the relationship between the User, PISP and Payer FSP. Given that the Payer FSP is the one with the knowledge of the user's account, and the credential linking the account with the PISP, it makes sense for the Payer FSP to be the one requesting the authentication. I'm sure there's other reasons I'm not thinking of as well at the moment... Perhaps these two sets of documentation, linking and transfer will shed some more light, although we don't explicitly answer that question. To me a
Indeed I think this is possible in any case. We could very easily require the Payer FSP to inform the PISP of the transaction outcome after it receives the |
Thanks @lewisdaly,
Do you mean that it is the Switch that needs to be able to tie the Is it because you do want to store any information about the
I'm really sorry for the confusion, it seems like I had a too quick look on the flow and misunderstood the basic use case, if the User is the Consumer and this is a normal P2P transfer then yes it makes perfect sense. I was thinking about the use case Merchant initiated merchant payment, where it is the merchant that requests a payment from the Consumer. In that case the credential linking and related relationship should be between the Merchant, PISP, and Merchant FSP (the Payee FSP in a merchant initiated payment).
For a P2P Transfer, yes it should be very easy for the Payer FSP to inform the PISP as they have the final PUT /transfers callback from the Switch. It seems to me that a flow where it is the Switch that is in charge of informing the PISP puts unnecessary requirements on the Switch, as well as making unnecessary changes to the API. But it might very well be that there are very good reasons for that, and I would just like to understand them. Kind regards, |
Hi all,
For a P2P Transfer, yes it should be very easy for the Payer FSP to inform the PISP as they have the final PUT /transfers callback from the Switch. It seems to me that a flow where it is the Switch that is in charge of informing the PISP puts unnecessary requirements on the Switch, as well as making unnecessary changes to the API.
As Henrik writes above, it seems to me that the PISP should be receiving the notification of completion from the payer DFSP (in this customer initiated case). Until the payer DFSP is satisfied that the transfer completed, it is still pending with the payer and therefore the status between the PISP and the Payer DFSP is unsettled even if the transfer has been committed and even if the PISP has other knowledge of completion in the hub. That’s not a good outcome.
Interledger provides end to end assurance. The Payer DFSP should provide the ILP packet to the PISP following commit notification (after receiving the PUT from the hub). The PISP then, then in possession of the condition and the fulfillment, has all required information to ensure Payee was properly credited for the transaction.
The chain of accountability is between the PISP and one of the two DFSPs, depending on whether the transaction was merchant initiated or consumer initiated. The final transfer commitment notification should flow from the DFSP to the PISP to ensure the chain is unbroken.
If the transfer were initiated directly on the switch by the PISP, it would have an accounting relationship with the switch and should expect final outcome notification directly from the switch. But the present flow is between the PISP and the DFSP, proxied by the hub. The central ledger has no role in the transaction, and conducts transfers of value only for account hosting institutions with a stake in settlement. And the PISP has no role in the transfer other than to request its initiation by the DFSP who is bound by the scheme rules.
The central ledger should not be trafficking in Transaction objects. The job of the ledger is to clear and settle transfers, and should not see or be a party to the transaction details.
— Miller
On Oct 29, 2020, at 5:14 AM, Henrik Karlsson <notifications@github.com> wrote:
Thanks @lewisdaly,
The PATCH /thirdpartyRequests/transactions/{id} callback from the switch is sent upon the clearing of funds (as with the PUT /transfers/{id} call to the Payer FSP, and the optional PATCH /transfers/{id} to the Payee FSP). Which means we need a way to tie together a transferId and transactionRequestId.
Do you mean that it is the Switch that needs to be able to tie the transferId and the transactionRequestId together, or who is it that (the we) needs to tie these together? If the PATCH /thirdpartyRequests/transactions/{id} request is sent from the Switch, should not both the transferId and the transactionRequestId be known by the Switch already, as the original POST /thirdpartyRequests/transactions was passed along the Switch on its way to the FSP?
Is it because you do want to store any information about the thirdPartyRequest in the Switch? Should it really be the Switch that is sending this callback, would it not be easier if it was the FSP that the user has its account in, as that is where the original POST /thirdpartyRequests/transactions was sent to?
I think this was the way we always looked at the problem, given the relationship between the User, PISP and Payer FSP. Given that the Payer FSP is the one with the knowledge of the user's account, and the credential linking the account with the PISP, it makes sense for the Payer FSP to be the one requesting the authentication.
I'm really sorry for the confusion, it seems like I had a too quick look on the flow and misunderstood the basic use case, if the User is the Consumer and this is a normal P2P transfer then yes it makes perfect sense. I was thinking about the use case Merchant initiated merchant payment, where it is the merchant that requests a payment from the Consumer. In that case the credential linking and related relationship should be between the Merchant, PISP, and Merchant FSP (the Payee FSP in a merchant initiated payment).
Indeed I think this is possible in any case. We could very easily require the Payer FSP to inform the PISP of the transaction outcome after it receives the PUT /transfers/{id} call from the switch. This was something we discussed earlier on, but decided that the Switch is the authority on the state of a transaction, so it should be the switch doing the informing. But I'd like to open up this topic again.
For a P2P Transfer, yes it should be very easy for the Payer FSP to inform the PISP as they have the final PUT /transfers callback from the Switch. It seems to me that a flow where it is the Switch that is in charge of informing the PISP puts unnecessary requirements on the Switch, as well as making unnecessary changes to the API. But it might very well be that there are very good reasons for that, and I would just like to understand them.
Kind regards,
Henrik
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Thanks @millerabel, @ehenrka, I know there's another thread on the community page that contains some of this discussion.
I hadn't considered this case until now - this is a good point. From the PISP's perspective, the source of truth on a transfer's outcome should come from the Payer DFSP, and the Payer DFSP can use the ILP Packet to prove that indeed the transaction took place. The latest of @MichaelJBRichards's and my thinking is simply to require the Payer DFSP to inform the PISP of the transaction outcome. This simplifies many things, and avoids the can of worms. We weren't originally intending the PISP to need the fulfilment in the final notification from the Payer DFSP, but now I'm beginning to see that it will be necessary. Even if we decide to require the Payer DFSP to go this route, I think we should have a discussion on these generic notification principles, as it is something discussed in other proposed changes (or musings of proposed changes). Having a clear statement of the principles here will aid future designs (and make sure we don't go around in circles). |
Thanks @lewisdaly,
Please explain to me why the PISP should need the fulfilment? At least in my understanding, the PISP should not be involved in the actual transaction more than that the end user is requesting the transaction and confirming the transaction via the PISP instead of the FSP directly. The only entities that are involved in the actual financial transaction are the Payer, Payer FSP, Switch, Payee FSP, and the Payee. The only involved entities in the actual transfer of funds between FSPs are Payer FSP, Switch, and Payee FSP, hence there is a need for a proof of the transaction for these entities. The transfer of funds in the Payer/Payee FSP is within the same system, hence there should be no need for a proof of the transaction. If the end user gets the notification from its FSP via the PISP, then the end user can trust that the transaction has been performed. If there would be any problems, then the FSP has the fulfilment that the Switch has sent to them as proof. The PISP should not have to validate a fulfilment.
Please explain any use case that you see where it should be required that the Switch is sending a notification to anyone else than the Payer FSP or Payee FSP, as part of the transfer of funds between the Payer FSP and the Payee FSP? Kind regards, |
Following up from our discussion today, our current proposal for the PISP API requires changes to how the FSPIOP-API handles the
Transaction
object, and the contents of theTransaction
object.Our existing proposal includes the following:
Transaction
object in plaintext for thePUT /quotes/{id}
POST /transfers
requestsubscriptions
list, which contains interested parties who should be informed by the switch upon the conclusion of a transactiontransactionId
,transferId
andtransactionRequestId
in one placeThe question raised during the meeting was "Do we need the FSPIOP v2.0 API (with the above changes) for the PISP API to work?"
The text was updated successfully, but these errors were encountered: