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 >> >
