Thank you, James. I suppose the next question is: Is anyone currently using this in production?
If yes, we should complete and enhance the missing parts. If no, perhaps we should deprecate and remove it from the next release. Regards, Adam Saghy > On Aug 18, 2026, at 4:09 PM, James Dailey <[email protected]> wrote: > > 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] > <mailto:[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] >>> <mailto:[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] <mailto:[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 >>>> >>> >>
