[
https://issues.apache.org/jira/browse/FINERACT-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Dailey updated FINERACT-706:
----------------------------------
Description:
This is a ticket to cover the new requirements from integration with a payment
switching solution, using best practices in a push-payment real-time
environment.
[https://lists.apache.org/thread.html/fa8f745cd7228a8f8418561ddadc715a3388d01656bcbc28680f86f2@%3Cdev.fineract.apache.org%3E]
Basically, there are a few minor changes are needed to fineract1.x to support
integration with a payments hub. The payments hub will handle most of the
functionality, so the changes to fineract1.x are to be minimal.
A new package will be created with new API endpoints.
The functional requirements will include:
* Get a quote
* Hold funds
* Send funds (confirmed )
Assuming customers are authenticated and using a front end solution, in the
payments flow, end users (payors) get a "Request for Payment" (RfP) from a
Payee and after getting a quote for the cost of that payment, they do a Payment
Initiation. When they initiate the payment their checking/savings account
shows an entry which is debit-amount-on-hold.
There is a further requirement around lookup values - where a new "secondary
ID" is needed in the account table. That secondary ID is used for the routing
address of the payee.
To further explain the intent, imagine a payments switch between two instances
of fineract, the switch or "interoperable service for transfers" (IST) talks
over APIs to a thin "Payments Hub" on the fineract infrastructure.
was:
This is a ticket to cover the new requirements from integration with a payment
switching solution, using best practices in a push-payment real-time
environment.
[https://lists.apache.org/thread.html/fa8f745cd7228a8f8418561ddadc715a3388d01656bcbc28680f86f2@%3Cdev.fineract.apache.org%3E]
Basically, the changes are needed to fineract1.x to support integration with a
payments hub. The payments hub will handle most of the functionality, so the
changes to fineract1.x are to be minimal.
A new package will be created with new API endpoints.
The functional requirements will include:
* Get a quote
* Hold funds
* Send funds (confirmed )
Assuming customers are authenticated and using a front end solution, in the
payments flow, end users (customers) receive a "Request for Payment" (RfP) and
after getting a quote for the cost of that payment, then do a Payment
Initiation. When they initiate the payment their (current) account shows an
entry which is debit-amount-on-hold.
> Payments switch integration
> ----------------------------
>
> Key: FINERACT-706
> URL: https://issues.apache.org/jira/browse/FINERACT-706
> Project: Apache Fineract
> Issue Type: New Feature
> Components: Accounting
> Affects Versions: 1.3.0
> Reporter: James Dailey
> Priority: Major
> Labels: features
> Fix For: 1.4.0
>
>
> This is a ticket to cover the new requirements from integration with a
> payment switching solution, using best practices in a push-payment real-time
> environment.
> [https://lists.apache.org/thread.html/fa8f745cd7228a8f8418561ddadc715a3388d01656bcbc28680f86f2@%3Cdev.fineract.apache.org%3E]
>
> Basically, there are a few minor changes are needed to fineract1.x to support
> integration with a payments hub. The payments hub will handle most of the
> functionality, so the changes to fineract1.x are to be minimal.
> A new package will be created with new API endpoints.
> The functional requirements will include:
> * Get a quote
> * Hold funds
> * Send funds (confirmed )
> Assuming customers are authenticated and using a front end solution, in the
> payments flow, end users (payors) get a "Request for Payment" (RfP) from a
> Payee and after getting a quote for the cost of that payment, they do a
> Payment Initiation. When they initiate the payment their checking/savings
> account shows an entry which is debit-amount-on-hold.
> There is a further requirement around lookup values - where a new "secondary
> ID" is needed in the account table. That secondary ID is used for the
> routing address of the payee.
> To further explain the intent, imagine a payments switch between two
> instances of fineract, the switch or "interoperable service for transfers"
> (IST) talks over APIs to a thin "Payments Hub" on the fineract
> infrastructure.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
