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 >
