hey everyone, just wanted to give a small update on what i am doing with the interoperation transfer work after the discussion on mailing list.
i think one thing i should clarify first, i am not trying to redesign the interoperation flow or bring a new payment architecture inside fineract.
the flow already exists in fineract. while looking into it i found some small issues in the current implementation, mainly around the transfer query, permissions, persisted data and how the transfer state is represented.
FINERACT-2751 is mainly about fixing those existing issues, not introducing a new prepare -> commit system.
after the concerns raised on the mailing list, before continuing i am checking a few things:
if Payment Hub is supposed to handle those responsibilities, i want to keep that boundary as it is.
my goal here is much smaller: understand how the existing functionality is supposed to work and fix the current inconsistencies without unnecessarily changing the architecture.
if during this investigation i find that some part of FINERACT-2751 requires a bigger architectural or security change, i will not include that in this PR. i will bring that separately for discussion first.
once i finish checking the existing consumers and lifecycle, i will share what i found.
i think one thing i should clarify first, i am not trying to redesign the interoperation flow or bring a new payment architecture inside fineract.
the flow already exists in fineract. while looking into it i found some small issues in the current implementation, mainly around the transfer query, permissions, persisted data and how the transfer state is represented.
FINERACT-2751 is mainly about fixing those existing issues, not introducing a new prepare -> commit system.
after the concerns raised on the mailing list, before continuing i am checking a few things:
- whether Payment Hub or any other current consumer is still using the existing interoperation transfer APIs
- whether the GET transfer endpoint is currently used anywhere
- what the intended lifecycle of prepare and commit actually is
- why both currently return ACCEPTED and whether that is intentional
- how transactionCode and transferCode are currently stored/retrieved
- whether current tests or deployment examples still depend on this functionality
if Payment Hub is supposed to handle those responsibilities, i want to keep that boundary as it is.
my goal here is much smaller: understand how the existing functionality is supposed to work and fix the current inconsistencies without unnecessarily changing the architecture.
if during this investigation i find that some part of FINERACT-2751 requires a bigger architectural or security change, i will not include that in this PR. i will bring that separately for discussion first.
once i finish checking the existing consumers and lifecycle, i will share what i found.