[jira] [Updated] (FINERACT-2750) Search by routing code and receipt number

["Victor Romero (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/FINERACT-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Victor Romero updated FINERACT-2750:
------------------------------------
    Description: 
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.

 

  was:
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.

 


> 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
>            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)