[
https://issues.apache.org/jira/browse/FINERACT-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Victor Romero updated FINERACT-2750:
------------------------------------
Summary: Search by cheque number, routing code and receipt number (was:
Search by routing code and receipt number)
> Search by cheque number, 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
> Assignee: Victor Romero
> Priority: Major
>
> Search by cheque number, 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)
