Victor Romero created FINERACT-2750:
---------------------------------------
Summary: Search by routing code and receipt number
Key: FINERACT-2750
URL: https://issues.apache.org/jira/browse/FINERACT-2750
Project: Apache Fineract
Issue Type: Bug
Reporter: Victor Romero
Search by routing code and receipt number is required because currently in
Apache Fineract, *routing code* and *receipt number* live on payment details
(m_payment_detail) and are attached to loan and savings transactions. When the
core is wired to payment gateways / payment hubs / mobile-money rails, those
two fields are the main *external correlation keys* not Fineract’s internal
transaction id.
h3.
||Field||Typical meaning outside Fineract||
|*Routing code*|Channel / institution / switch identifier (bank routing number,
sort code, mobile-money provider code, payment-type routing key, etc.)|
|*Receipt number*|Gateway’s unique proof of the payment (RRN, operator receipt,
mobile-money confirmation, ACH/wire reference, etc.)|
Gateways almost never know Fineract’s internal id. They return _their_ receipt
and routing identifiers. Staff and automated jobs therefore need to find the
core transaction using those external values.
h3. Why lookup by them is required
*1. Reconciliation* Gateway reports and statements list receipt + routing
codes. Ops must match those lines to Fineract deposits/repayments without
relying on internal ids that the gateway never sees.
*2. Idempotency / duplicate protection* Callbacks and retries from a gateway
often resend the same receipt. Looking up by routing code + receipt number lets
the system detect “already posted” and avoid double-crediting.
*3. Customer support and dispute handling* A client quotes the SMS receipt or
bank reference (“I paid, receipt ABC123”). Support must find the transaction in
Fineract by that external reference, not by an internal id the client never
received.
*4. Multi-channel deployments* One Fineract instance may receive money via
several providers (M-Pesa, bank transfer, card, etc.). Routing code
distinguishes _which_ channel; receipt number identifies _which_ payment on
that channel.
*5. Async settlement flows* Payment hub / Mojaloop-style flows: request →
accept → settle. Intermediate and final messages reference the same external
receipt/routing identifiers. The core must resolve those to the correct account
transaction.
*6. Reversals and adjustments* Reversals from the gateway usually cite the
original receipt. Fineract needs to locate the original payment detail by
receipt (and often routing code) to reverse or adjust the right transaction.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
