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