How Fineract accounts connect to real-time payments through Payment Hub EE
A bank or fintech team that needs its Fineract accounts to send and receive real-time payments should plan around one supported route: the openMF ph-ee-connector-ams-mifos connector. It maps Zeebe worker routes in Payment Hub Enterprise Edition to Fineract interoperation endpoints such as /interoperation/parties, /interoperation/accounts and /interoperation/quotes, so Fineract acts as the local account management system (AMS) that holds balances and authorizes debits and credits. The connector is licensed under MPL-2.0, which the reader's legal team should review alongside the Payment Hub and Fineract licenses (Apache-2.0 for Fineract).
The division of work is the central design decision. Payment Hub EE owns the payment process: Zeebe runs the BPMN flows, which the connector README lists as GSMA P2P, GSMA bill payment, international remittance and payer fund transfer. Each flow calls workers that ask the AMS a specific question, such as whether a party exists, what a quote will cost, or whether a transfer can be posted. Fineract owns the ledger entries, account status and holds that answer those questions. Teams should document, for each flow, which step is authoritative for the final balance change and what happens if a Zeebe step times out after Fineract has already posted.
Before build starts, confirm with the connector's maintainers which Payment Hub EE and Fineract versions the connector was tested against, and which BPMN flows your payment scheme needs. Map each interoperation call to a Fineract product, account type and tenant, and agree who owns the mapping. Retries and idempotency between Zeebe and Fineract need an explicit design, because a retried transfer that posts twice is the failure that matters most in a payments flow. Those decisions belong in the design phase, before any scheme connection is tested.
What you need in place before the connector is configured
The connector sits between a Fineract tenant and a Payment Hub EE deployment, so each side must be ready before any mapping work starts. The cards below cover the platform versions, database, orchestration cluster, tenant setup, network paths and certificates that the connector depends on.
Fineract 1.x release line
Plan on the Fineract 1.x line, where 1.15.0 is the current stable release on the project site. Record the exact Fineract version you will run, because the connector's endpoints must match it. Confirm connector version compatibility with that Fineract version against the connector repository before you pin either component.
PostgreSQL as the database
PostgreSQL is the database the Fineract project recommends, and the official Docker image ships only the PostgreSQL JDBC driver. Provision it with backups and a tested restore path before the interoperation tests begin, because transfer and account records written during testing must survive a restore. Confirm your DBA team can support this version in your own environment.
Payment Hub EE and its Zeebe cluster
The connector's Zeebe workers only receive work when a Payment Hub EE deployment and its Zeebe cluster are running and reachable. Confirm which BPMN flows you will run, such as the payer fund transfer or GSMA P2P processes, and that the cluster has capacity for the workers you plan. Decide who owns cluster upgrades, since a connector change can depend on them.
Interoperation-enabled tenant
Each Fineract API call carries a Fineract-Platform-TenantId header, so the connector must target a specific tenant. Create the tenant in the tenants database, set up the offices, savings products and settlement accounts the flows will use, and confirm the interoperation endpoints respond for that tenant. Use a dedicated service user with only the permissions the connector needs.
Network paths between systems
The connector must reach Fineract's REST API and the Zeebe gateway, while Payment Hub EE must reach the connector. Map every hop, including firewall rules, DNS names and any proxy or gateway in between, and confirm each path works from the environment where the workers run. Limit inbound access to Fineract to the connector and to the front ends that legitimately need it.
TLS certificates and endpoints
The Fineract documentation strongly encourages HTTPS only and documents SSL settings through environment variables such as FINERACT_SERVER_SSL_ENABLED. Issue certificates that cover every internal hostname the connector calls, and set a renewal owner and alert before expiry. Decide how the connector trusts your internal certificate authority, and test that trust chain from the worker host rather than assuming it.
Configuration sequence from tenant setup to first test transfer
This sequence takes a Fineract tenant and the Payment Hub EE connector from empty configuration to a verified party lookup, quote and transfer in a non-production environment. Each step closes with a check that tells the team whether it can move on.
Prepare the Fineract tenant and interoperation accounts
The Fineract administrator creates the tenant configuration, the offices, the savings or ledger accounts that the payment switch will address, and the test clients whose account numbers the connector will look up. Confirm with your Fineract release notes that the interoperation endpoints are present in the version you run, and record the exact tenant identifier that every request must send in the Fineract-Platform-TenantId header. Done when a test account can be read through the Fineract REST API under that tenant, and the account identifiers match the list your payment team will use in scheme test cases.
Create a dedicated service identity in Fineract
Create a non-personal Fineract user for the connector, assign it only the permissions the interoperation calls need, and replace any default development credentials before the environment is reachable. Decide whether the connector authenticates with HTTP basic authentication or OAuth2 for this environment, and confirm the choice with your security team. Done when the service user can call a read-only interoperation endpoint and is refused on an administrative endpoint, which proves the permission set is narrower than an administrator account.
Deploy the connector and enable HTTPS to Fineract
The platform engineering team deploys the openMF ph-ee-connector-ams-mifos service alongside the Payment Hub EE components in the non-production cluster, and sets the Fineract base URL to an HTTPS endpoint. Fineract's documentation strongly encourages HTTPS-only access and documents SSL settings through environment variables such as FINERACT_SERVER_SSL_ENABLED, so use those settings and do not allow plain HTTP between the two services. Done when the connector starts without errors, and a request from the connector to the Fineract health endpoint succeeds over a verified certificate chain.
Register the BPMN flows in Zeebe
The integration team deploys the BPMN process definitions shipped in the connector repository to the Zeebe cluster, starting with the flow that matches the first test scenario, such as the GSMA P2P or payer fund transfer process. Check the connector README for the exact process names and the version of each definition before deploying, and keep a record of which definition versions are active. Done when Zeebe lists each deployed process with its version and the team can start one instance without an error on a worker route.
Map Zeebe worker routes to interoperation endpoints
Review the connector configuration so each Zeebe worker task points to the matching Fineract interoperation path, such as /interoperation/parties for party lookup, /interoperation/quotes for quotes and /interoperation/accounts for account actions. Confirm that every route sends the correct tenant header and uses the service identity from the earlier step, and remove any route that a flow does not need. Done when a manual check of the mapping shows one worker route for each task in the selected flow, and each route resolves to an endpoint that Fineract reports as available.
Run the party lookup in a non-production environment
The test lead starts a process instance that performs a party lookup for a known test account, using identifiers from the scheme or switch test set. Watch the Zeebe instance history and the Fineract request log together, so the team can see the request leave the connector, reach the interoperation endpoint and return a party record. Done when the lookup returns the expected test party name and identifier, and the Fineract log shows the same tenant and service identity on the request.
Obtain a quote and run the first test transfer
Run a quote for a small amount on the test account, then execute a transfer through the same flow. Confirm that the quote amount, currency and fees match the agreed test case, and that the Fineract ledger shows the expected debit and credit after the transfer completes. Done when the quote is returned for the test account and the transfer finishes with a matching entry in Fineract, which is the first end-to-end evidence that the configuration works. Record the process instance, request identifiers and ledger references so the result can be repeated and audited.
How party identifiers, tenants and account references map to Fineract records
The mapping from a payment party identifier to a Fineract record is the first thing to pin down, because a wrong match sends money to the wrong account. In the connector, a party lookup arrives through the Zeebe worker route and is resolved against Fineract through the /interoperation/parties endpoint. Decide, before build, which identifier type your scheme uses (for example, a mobile number, a national ID or an account alias) and which Fineract attribute stores it on the client or savings account. Confirm in the connector source for the version you run which request field becomes the lookup key, whether the lookup returns the client, the savings account or both, and what happens when more than one record matches. Do not assume a one-to-one link between a party and an account until you have tested a shared identifier case.
Every call to Fineract must carry the Fineract-Platform-TenantId header, and that header decides which tenant database the request reaches. In a multi-tenant deployment, a misconfigured connector can resolve a valid identifier in the wrong tenant, so the tenant value should be set per connector environment and never inferred from the payload. Ask your integration team to confirm where the tenant identifier is configured, whether it is shared across all BPMN flows, and how the connector behaves when the header is missing or unknown. Include a negative test for each tenant boundary in your test plan.
Transfer references and idempotency keys tie a payment instruction in Payment Hub to the Fineract transaction that settled it. Record the scheme transaction identifier, the Payment Hub transaction identifier and the Fineract transaction or journal reference in one reconciliation record, and confirm which of these the connector sends as the external identifier on transfers and quotes. A retried Zeebe task must not post a second debit, so verify how the connector behaves when a transfer call times out after Fineract has committed it. Treat this mapping as a control: an auditor or reconciliation team should be able to trace any settled payment from the scheme message to the ledger entry.
Payment Hub fields mapped to Fineract attributes
This table lists the main data objects that move between Payment Hub EE, the AMS connector and Fineract, and what each one maps to on the Fineract side. Rows marked as confirmation items are mappings the reader must verify in the connector code before go-live, not settled facts. Use it to scope the interoperation work and the test cases that follow.
| Payment Hub object | Fineract attribute or endpoint | Status and what to verify |
|---|---|---|
| Party identifier | Client lookup through /interoperation/parties, keyed to a client identifier in the Fineract tenant | Confirmation item: check which identifier type the connector sends and how it resolves to a single client when more than one identifier matches |
| Account identifier | Savings account reference returned by /interoperation/accounts | Confirmation item: confirm whether the account number, external ID or another field is the lookup key, and the behavior for closed or inactive accounts |
| Quote request | Fee and amount calculation through /interoperation/quotes using the product's configured charges | Confirmation item: confirm which charges are included, the currency handling, and whether the quote is stored or recalculated at transfer time |
| Transfer | Deposit or withdrawal on the savings account, with journal entries posted through Fineract accounting | Confirmation item: confirm the transaction type used, the payment type mapping, and the accounting mapping that receives each posting |
| Transfer reference | Transaction identifier returned by Fineract, used to correlate retries and reversals | Confirmation item: check whether the connector sends an idempotency key and how a repeated request is handled |
| Status codes to Zeebe | Connector route result mapped to the Zeebe worker response and BPMN flow variables | Confirmation item: list every Fineract error response the connector maps and the flow path each one triggers, including timeouts |
Securing the connector, credentials and payment traffic
The connector sits between a payment switch and the Fineract core, so a weakness in either side exposes account movements. The cards below cover authentication, transport encryption, secrets, network placement, audit logging and the PCI DSS scope question that should be settled before traffic flows.
Replace the default Fineract login
Fineract's README ships a development login of mifos with a default password, and that account must not survive into any deployment that touches payment traffic. Decide whether the connector authenticates with OAuth2 or HTTP basic authentication, create a dedicated service identity for the connector, and give it only the interoperation permissions it uses. Confirm the exact role setup in your Fineract version before go-live, and test that the default login is disabled in every tenant.
HTTPS only between every hop
Fineract strongly encourages HTTPS only and exposes SSL settings through environment variables such as FINERACT_SERVER_SSL_ENABLED. Apply the same rule to the calls from the Zeebe workers to the connector and from the connector to Fineract, and to the switch callbacks. Confirm how certificates are issued, rotated and trusted by each component, since a single plain HTTP hop on the interoperation path undermines the rest of the design.
Secrets for Zeebe and Fineract
The connector needs credentials for Fineract, for the Zeebe cluster and for any broker or database it reaches. Store these in a dedicated secrets manager with rotation and access logs, not in BPMN variables, connector configuration committed to source control, or container images. Check that workflow variables recorded in Zeebe history do not carry tokens or account identifiers you would not want retained.
Segment the switch from the core
Place the connector and Zeebe workers in a zone that can reach the switch and the Fineract API, while the Fineract database, write instances and batch instances stay in a tighter zone with no route from the switch network. Limit the connector to the specific Fineract endpoints it calls, such as /interoperation/accounts, /interoperation/quotes and /interoperation/parties. Confirm these rules with your network team and record them as part of the design.
Audit trail for interoperation calls
Record each interoperation request with a timestamp, the calling identity, the tenant, the Fineract endpoint, the transaction reference and the outcome, while excluding full account numbers and authentication material from logs. Make sure the record can be correlated with Zeebe process instances and with Fineract's own journal entries during reconciliation. Agree retention and access rules with your compliance team before the first production day.
Confirm PCI DSS scope early
PCI DSS applies to entities that store, process or transmit cardholder data or sensitive authentication data, or that could affect the security of that data. Whether these flows fall in scope depends on whether card data appears in any message, log or stored record, and on which parties operate each component. Confirm scope with your Qualified Security Assessor or internal assessor before design freeze, because scope decides the controls and evidence you must produce.
Common failures in Payment Hub and Fineract interoperation
This table lists the failures teams most often hit when the Payment Hub connector calls Fineract interoperation endpoints, with the likely cause and the fix for each. Read each row as a check to run during integration testing, before a payment flow reaches production traffic.
| Failure | Likely cause | Fix |
|---|---|---|
| Party lookup returns no match | The connector sends a Fineract-Platform-TenantId header that does not match the tenant where the account exists, or the identifier type differs from the one stored in Fineract. | Confirm the tenant identifier configured in the connector against the tenants database, then test a lookup with a known account in each tenant and identifier format. |
| Quote rejected for an inactive account | The account is pending approval, dormant, closed or blocked, so the interoperation quote call fails the account status check. | Map Payment Hub account states to Fineract statuses in the design, and test quotes for each status the switch can send, including accounts that are not yet activated. |
| Transfers time out during Close of Business | The Close of Business Spring Batch job, which can run for several hours on large deployments, holds locks or consumes database capacity while transfer calls arrive. | Schedule payment traffic and the COB window together, size read and write instances as the Fineract documentation describes, and load test transfers while the batch job runs. |
| Duplicate transfers after retries | A timed-out transfer is retried by the workflow or switch while the first request still completes in Fineract, and the request carries no idempotency key that Fineract can match. | Generate one stable transaction reference per payment in the workflow, check for an existing transfer with that reference before posting, and test retries deliberately. |
| Certificate trust errors between connector and Fineract | The connector does not trust the certificate chain presented by Fineract's HTTPS endpoint, often because an internal CA or a self-signed certificate is not added to the connector's trust store. | Install the internal CA in the connector runtime trust store, enable HTTPS on Fineract using the documented SSL settings, and confirm the chain with a test call before enabling the flow. |
| Zeebe workers not picking up tasks | The worker is not connected to the Zeebe gateway, the task type in the BPMN model does not match the worker route, or the worker has stopped after a deployment change. | Compare each service task type in the deployed BPMN with the connector routes, check worker logs and connectivity to the gateway, and confirm the process version is the one being started. |
| Default Fineract credentials left active | The development login documented in the project README is still enabled in a shared or staging environment that the connector uses. | Replace the default login before any connection, use a dedicated integration user with the least privileges needed for interoperation calls, and confirm the connector secret is stored outside the configuration files. |
Questions teams ask before connecting Fineract to a payment switch
What drives the effort and timeline for a Fineract payment switch connection?
The number of payment flows in scope and the switch's own onboarding requirements drive most of the effort. Each BPMN flow the connector supports, such as GSMA P2P, GSMA bill payment, international remittance or payer fund transfer, needs its own mapping of Zeebe worker routes to Fineract interoperation endpoints, plus error handling and reconciliation rules. Other drivers include how many product types and ledger accounts must be mapped, whether the switch scheme requires certification testing, and how many environments the bank must stand up. Ask for a written scope that lists each flow, each endpoint and each environment, and that states the test cycles and sign-off points. A quote should follow from that list rather than from a generic estimate.
Can our own team build a Payment Hub EE connection without a partner?
A team with Java, Fineract API and Zeebe experience can build it in-house, and the connector is open source under MPL-2.0, so the code is available to read and change. The harder parts are usually outside the code: understanding the payment scheme rules, designing the accounting entries that each transfer creates, and running the switch certification and go-live tests. Fineract's README also warns that production deployments can be complex, costly and time-consuming and recommends that organizations consider a vendor for deployment and maintenance. Before deciding, list the skills you have in each area, then compare that list with the scope. DeployOpen plans, implements and tests self-hosted platforms in your own infrastructure under a written, fixed scope if you choose to use a partner.
What does the bank need to provide for the switch integration?
The bank must provide access to the payment switch's test environment, test accounts and participant identifiers, and a named owner who can approve each flow. Engineering needs a Fineract test tenant, service credentials that follow your secrets policy, and network paths between the connector, Zeebe, Fineract and the switch. Operations needs an agreed list of ledger accounts and product codes, and compliance needs to confirm how transaction data is logged and retained. Sign-off on each BPMN flow should be written down, with the expected accounts debited and credited for every success and failure path. Confirm these items with the switch operator and your internal teams before the work starts, because they often set the schedule.
How should go-live testing be scoped for a payment switch connection?
Scope go-live testing around the flows and failure cases, not just the happy path. A useful test plan covers party lookup, quotes and transfers for each flow, duplicate and timed-out requests, reversals, insufficient funds, closed or frozen accounts, and restarts of Zeebe workers in the middle of a transfer. It should also check end-of-day ledger totals against the switch's settlement files and confirm that any batch job, such as Close of Business, completes within the window you have planned. Fineract's documentation notes that the Close of Business job can run for several hours on large deployments, so schedule that test with realistic account volumes. Write the exit criteria before testing starts, and agree on who signs them off.
Which regulations apply to a Fineract payment switch connection?
The answer depends on the rails you use and your license type. PCI DSS applies if the environment stores, processes or transmits cardholder data or could affect the security of that environment, so a switch that carries card data brings the connector and its hosts into scope. The PCI SSC does not enforce compliance itself; the payment brands decide who must validate, and assessments are documented as a Report on Compliance or a Self-Assessment Questionnaire with an Attestation of Compliance. DORA applies to listed EU financial entities, including payment institutions, from 17 January 2025 and requires a register of ICT contracts and tested exit plans for critical functions. If you use Swift, the Customer Security Controls Framework v2026 requires independent assessment and an annual attestation in KYC-SA. Ask your compliance adviser to confirm which of these apply to your entity.
Does DeployOpen certify or audit a payment switch integration?
No. DeployOpen plans, implements, hardens, tests and documents self-hosted platforms, and it prepares systems, controls and evidence for compliance assessments. Independent auditors, Qualified Security Assessors and certification bodies issue reports and attestations, and the payment switch or scheme operator may run its own certification tests. DeployOpen can help with security testing of the APIs and infrastructure, and with documenting the controls an assessor will ask about. Ask any partner to state in writing which evidence they will produce and which parts remain the responsibility of your auditor, your switch operator or your own staff.
Which Fineract version should we use for a payment integration?
Use a currently supported release of the Fineract 1.x line, and confirm the connector's compatibility with that version before you commit. Fineract's website lists 1.15.0 as the current stable release, and the project creates official releases quarterly, with end-of-life releases archived. The connector repository should state which Fineract versions it has been tested against, so check that before you choose a version. Plan an upgrade path from the start, because switch certification may take months and a new Fineract release could arrive in the meantime. Ask for a written statement of which versions will be tested and how a version change would be retested.
What to test before go-live
A go-live decision for a payment switch connected to Fineract rests on evidence from each payment flow, from failure paths, and from the nightly close. The cards below cover what to test, in what order, and what to agree in writing before cutover.
Functional tests per BPMN flow
Run one scripted test set for each process the connector README lists: GSMA P2P, GSMA bill payment, international remittance and payer fund transfer. For each flow, confirm that party lookup, quote, and transfer calls reach the matching /interoperation/parties, /interoperation/quotes and /interoperation/accounts routes and that Fineract posts the expected savings movement. Record the Zeebe path taken and the final account balance for every case, so a passing run proves the ledger, not only the workflow.
Failure and reversal paths
Test the paths where money should not move: party not found, insufficient available balance, quote expiry, switch timeout after Fineract has already debited, and a rejected transfer that must be reversed. For each path, define the expected end state in both the switch and Fineract, including whether a hold is released or a compensating entry is posted. Confirm that a retried request does not create a second debit.
Close of Business overlap
Schedule payment load during the Close of Business Day batch on a copy of production volume. The Fineract README notes that this job can run for hours on deployments with millions of accounts, so measure how long it takes in your environment and whether real-time transfers queue, fail or post to the wrong business date. Agree a rule for when payment traffic is paused, and test that the pause works.
Endpoint security tests
Test the interoperation endpoints and connector APIs as an attacker would: authentication on every route, tenant isolation through the Fineract-Platform-TenantId header, rejection of default credentials, HTTPS-only access, and authorization limits on account lookups. Check that party lookup cannot be used to enumerate customer identities. Include the Zeebe and connector management interfaces, which are often left out of scope.
Reconciliation between switch and ledger
Build a daily comparison of switch transaction records against Fineract journal entries and savings transactions, keyed on a transfer identifier that both systems store. Test deliberately broken cases: a duplicate callback, a late settlement, and a transfer present in one system only. Confirm who receives each exception, how long it can stay open, and which system is treated as the record of truth for each break type.
Runbooks for stuck Zeebe instances
Write and rehearse runbooks for process instances that stop partway through a payment flow. Cover how to list instances waiting on a worker, how to find the matching Fineract transaction before retrying, when to cancel rather than resume, and who approves a manual journal correction. Rehearse each runbook on a test cluster with a fault injected at a known step, and time how long the operator takes to reach a safe state.
Running the integration after go-live
Treat the Fineract release, the connector and the Payment Hub EE deployment as one coupled release unit. The Fineract project publishes official releases quarterly, at the end of each quarter, so a new Fineract version will arrive on a fixed rhythm whether or not your payment flows need it. Before each upgrade, confirm with the connector maintainers which Fineract versions the current ph-ee-connector-ams-mifos build targets, and which Payment Hub EE release it was tested against. Fineract interoperation endpoints such as /interoperation/parties, /interoperation/quotes and /interoperation/accounts are the contract the connector depends on, so a change in their request or response shape is a regression risk even when the Fineract upgrade notes look minor.
Re-test the full set of BPMN flows you run after every quarterly Fineract release, not only the happy path. Cover party lookup, quote, transfer and reversal, plus the failure paths that Zeebe workers handle through retries and error routes. Monitor Zeebe job backlog and failed or incident instances, the latency and error rate of interoperation calls, and the Fineract Close of Business job, since a long batch can delay account state that the payment flows read. Alert on these signals in your own monitoring stack, and confirm what Payment Hub EE exposes for them in your version.
Change control for this integration should follow the ICT service expectations in DORA where your institution is in scope. Article 28(3) expects a register of information covering the Fineract, connector and hosting arrangements, and Article 28(8) expects documented, tested exit strategies and transition plans for services that support critical or important functions. Article 30(2) expects contracts with any implementation or support provider to state where services are performed and data processed, to require advance notice of changes, and to cover data return on termination. Confirm these terms with your legal and third-party risk teams before go-live, and record each upgrade decision and its test evidence against them.
How DeployOpen scopes and delivers this integration
The sequence turns a payment switch connection into a written scope, a tested build in your own infrastructure, and a handover your team can operate. Each step ends with a named output that you can check before the next one starts.
Confirm the payment switch and flows in scope
DeployOpen reviews which payment switch, scheme or bill payment flows you need, and which Payment Hub Enterprise Edition BPMN processes apply, such as the GSMA peer-to-peer, GSMA bill payment, international remittance or payer fund transfer flows. We confirm with your payments and operations leads which transaction types, currencies and account types are in scope and which are excluded. The output is a flow inventory that lists each process, its Fineract endpoints and its owner on your side.
Map environments and infrastructure boundaries
We document the environments you will use, such as development, test, pre-production and production, and where each Fineract, Payment Hub, Zeebe and broker component will run in your cloud accounts, data centers or air-gapped network. We also record network paths to the switch, secrets storage and the PCI DSS scope decision, if cardholder data is involved. The output is an environment and boundary diagram that your security team has reviewed.
Agree the written test plan
DeployOpen writes the test plan with you before build starts. It covers party lookup, quotes, transfers and failure paths, including timeouts, duplicate requests and reversals, along with the test data, switch sandbox access and acceptance criteria for each flow. The output is a signed test plan that defines what passes go-live, and any items you must confirm with the switch operator.
Build the connector and Fineract configuration
Our engineers deploy the AMS connector from the openMF repository, configure Zeebe worker routes to the Fineract interoperation endpoints, and set up the Fineract products, accounts and tenant settings that the flows need. Changes are tracked in version control and reviewed against the agreed flow inventory. The output is a build in your test environment that completes the first agreed flows end to end.
Run the agreed test plan
We execute the test plan against the switch sandbox and your test environment, recording results for each case, defect and retest. Failures are triaged with your team, and fixes are verified against the same cases before the plan is closed. The output is a test report that lists each case, its result and any open items you accept in writing.
Prepare production and go-live controls
DeployOpen hardens the production deployment to the agreed design, sets up monitoring, alerting and backups for the connector and Fineract, and writes the go-live and rollback runbook with your operations team. Cutover steps are rehearsed where the environment allows. The output is a signed go-live checklist and a rollback plan your team has walked through.
Hand over documentation and operations
We deliver the architecture record, configuration inventory, runbooks, test evidence and known-issue list to your team, and walk through operations with the engineers who will run the system. Support after handover is available as a separate retainer if you want it. The output is an accepted handover record, with each document and training session confirmed by your named owners.
How DeployOpen works on this
DeployOpen plans, implements, integrates, tests and documents Apache Fineract and Mifos Payment Hub EE inside your own cloud accounts, data centers or air-gapped networks. We start from the switch rules, the account model and your control requirements, then build and verify the connector path before any live payment flows.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names the payment switch, message schemes, Fineract tenants and the BPMN flows in use.
- We confirm which connector routes, interoperation endpoints and Zeebe workers your payment types require.
How we build
- We configure the AMS connector against your Fineract tenant and map party, quote and transfer calls to ledger accounts.
- We deploy Zeebe workflows and Payment Hub components in infrastructure you control, with secrets kept out of source.
- We test each flow end to end against sandbox switch endpoints, including failed, timed-out and duplicate transfers.
How we hand over
- You receive the written configuration, flow diagrams, endpoint mappings and runbooks for each payment type.
- Test evidence covers party lookup, quoting, transfer posting, reversals and reconciliation against Fineract balances.
- Your team is trained to operate workflows, read Zeebe incidents and follow the go-live and rollback checklist.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live.
- Retainers can cover connector version alignment with Fineract releases, which follow a quarterly cadence per the project.
- We can re-run the end-to-end test suite after switch scheme changes, Fineract upgrades or new payment types.
