I believe that this functionality was not pursued (Abandoned ) for very good reasons related to authentication and then authorization of said two stage transactions.
Instead an outside component was proposed to be a more secure “payments gateway “. I do not believe this should be implemented until and unless a secure design is in place. If it is implemented then it would need to fall into the surface area of security scans . Sent from Gmail Mobile On Tue, Aug 18, 2026 at 2:47 PM Ádám Sághy <[email protected]> wrote: > Hi Shubham, > > > Thanks for bringing this topic to our attention. > > > Could you please provide more details about the current implementation > lifecycle for interoperation transfer? > > > I’m also curious about the `state` field. I’d appreciate learning more > about the possible values it can take and the situations in which it’s used. > > > Thanks, > > Adam > > On Aug 18, 2026, at 2:42 PM, Ádám Sághy <[email protected]> wrote: > > Hi Shubham, > > Thanks for bringing this topic to our attention. > > Could you please provide more details about the current implementation > lifecycle for interoperation transfer? > > I’m also curious about the `state` field. I’d appreciate learning more > about the possible values it can take and the situations in which it’s used. > > Thanks, > Adam > > On Aug 18, 2026, at 1:45 PM, Shubham Chaudhary < > [email protected]> wrote: > > Hi all, > > I am working on FINERACT-2751, which is about implementing the currently > incomplete Interoperation transfer query endpoint: > > GET /interoperation/transactions/{transactionCode}/transfers/{transferCode} > > Jira: > https://issues.apache.org/jira/browse/FINERACT-2751 > > Pull Request: > https://github.com/apache/fineract/pull/6261 > > The main problem I found is that the endpoint needs both transactionCode > and transferCode to identify a transfer, but there was no durable > association between these two values. > > Because of that, InteropServiceImpl#getTransfer() was effectively > unimplemented and returned null. > > In the PR, I have currently implemented the following: > > - Added a small interop_transfer record to persist the association > between transactionCode and transferCode. > - The record stores: > - transaction code > - transfer code > - current action state > - latest completion timestamp > - PREPARE, COMMIT/CREATE and RELEASE transfer operations create or > update this record. > - Implemented getTransfer() using an exact lookup on (transactionCode, > transferCode). > - Unknown or mismatched transaction/transfer pairs return 404. > - Corrected the endpoint permission from READ_INTERQUOTE to > READ_INTERTRANSFER. > - Added a unique constraint on (transaction_code, transfer_code). > - Added integration coverage for prepared and committed transfer > lookups, mismatched codes, unknown transfers and response fields. > > I intentionally kept the new record small and continued using the existing > savings transaction/payment-detail flow for the actual financial > transaction. The new table is only being used as a durable > lookup/association for the Interoperation transfer. > > One limitation is that old transfers cannot be reliably backfilled because > their transactionCode association was not previously stored. > > The main point where I would appreciate feedback is the data model. > > Is introducing this small Interoperation-specific interop_transfer record > the right direction, or would it be preferable to persist the > transactionCode–transferCode association in an existing Fineract domain > model? > > I am happy to change the implementation based on the preferred > architecture. > > Thanks, > Shubham > > > >
