Overview
Financial institutions looking to use Mojaloop as the payment rails, often take help from a system integrator to connect their backend financial system to a Mojaloop deployment with all security and authentication enabled. We at INFITX not only have extensive experience in connecting financial institutions to Mojaloop, but we have experience in supporting System Integrators build capacity and expertise in Mojaloop so that they can perform this function. At INFITX we recently supported such a system integrator to build a Mojaloop integration. This blog is an effort to document the process as a case study that can be used as a reference to help other system integrators. If your organization is on a similar journey and you are interested in learning from previous experiences, feel free to contact us and join the discussion.
The journey to becoming a Mojaloop system integrator starts with needing a good understanding of the Mojaloop APIs and the various components of the Mojaloop system. Let’s start by having a more detailed view of the challenge that must be overcome.
Challenges
The API that Mojaloop exposes is an Asynchronous API. This means SIs (System Integrators) have to expose a server endpoint that Mojaloop uses to send the asynchronous callback response. Not all SIs like this approach and prefer a more synchronous request-response approach. To help bridge this gap, SIs can leverage Payment Manager to facilitate that conversion. Payment Manager for Mojaloop is a collection of tools that support DFSPs (Digital Financial Service Providers like banks, mobile wallets…etc) to integrate with Mojaloop using best practices. Two compelling features of Payment Manager are the Asynchronous to Synchronous API conversion and the automation of the security onboarding and maintenance. This both simplifies the integration requirements and ensures that the step when deployed against a full security-enabled switch is an easy one.
Mojaloop exposes granular API for the different operations that are involved while making a transfer, like a parties API for looking up the receiver party, quotes API, and transfers API. To lessen the burden of making multiple calls, Payment Manager provides a composite API that exposes one endpoint to make the transfer.
A Production deployment of Mojaloop comes with multiple security mechanisms enabled. JWS for application data-level encryption, mTLS for secure data transfer, and OAuth for authentication. There is quite an effort involved for SIs to implement all these while sending the transfer. Payment Manager simplifies this and takes care of all the security-related tasks before making the Mojaloop API call.
In addition to the above features, Payment Manager also automates the process of Onboarding into the Switch by having bi-directional communication with MCM (Mojaloop Connection Manager).
Objectives
A system integrator wants to connect their backend to the Mojaloop switch and make a test transfer (Outbound)
A system integrator wants to receive an inbound transfer on their backend from Mojaloop
Proposed Solution
Because of all the advantages offered by Payment Manager, Orion Systems chose to use Payment Manager while connecting to the Mojaloop deployment.
Orion Systems developed the Core Connector that facilitates the integration between Backend Financial System API and Payment Manager API.
To support rapid development and testing of their Core Connector implementation, they used an On-Premise Payment Manager that comes with a mock Switch using TTK (Mojaloop Testing Toolkit – This is a testing toolkit that can be used for testing, simulation, and development for the Mojaloop services).
Once their initial testing is complete, to test the end-end connectivity, they can use Payment Manager Golden Path Test collection as a reference.
Deployed a Mojaloop sandbox using IaC (Infrastructure as code – For deploying functionally complete Mojaloop instance) and given access to the system integrator like VPN profiles, and login credentials for different portals.
Presented the integration flow between a backend system to the Mojaloop switch using payment manager and demonstrated a P2P transfer (Peer to peer transfer – A basic transfer in Mojaloop from a sender DFSP to a receiver DFSP) flow using TTK interface
Demonstrated the process of developing core connector inside the payment manager step by step
- Using an on-premise-deploy repository for local development and simulation
- Outbound
- Inbound
- Packaging the solution and deploying with IaC
Alternatives
A system integrator can develop the DFSP implementation on their own without using Payment Manager by following the Mojaloop FSPIOP API.
But they need to take care of the following things
- Establishing communication with switch with security features like mutual TLS, JWS, and OAuth token authentication
- Onboarding the DFSP in the switch by providing the endpoints and security certificates
- Handling asynchronous callbacks from the switch
- State management for a 3-phase transfer
- Build a mechanism to trace transfers
- Build a mechanism to support the technical operations of the connection
Achievement
The system integrator could develop a core connector with the help of on-premise-deploy and demonstrate their use case at the Mojaloop community event.
Connecting to Mojaloop Switch in an IaC deployed environment
This step is to connect to the Mojaloop switch, which is deployed in an environment where security is enabled. Sis can send the API requests and observe the responses to understand the FSPIOP API.
One needs to have access to the below clusters and portals to run requests successfully and validate the results.
Switch cluster VPN – This is the switch cluster
Payment Manager VPN – This is the sender and receiver cluster
Login credentials for BOF portal – to check DFSP positions, settlement account balances, etc
Login credentials for Payment Manager sender portal and Payment Manager receiver portal – These are used to validate the transfer sent through the systems.
After successfully understanding the FSPIOP API and how Payment Manager is very helpful in bridging the connectivity along with providing security, the SI is ready to build their own connectors.
Below is the diagram to show the setup in an IaC deployed environment:
Click to expand
Developing Core Connector with local payment manager (on-premise-deploy)
What is on-premise-deploy?
The below diagram represents the typical DFSP integration process with the Mojaloop switch.
Click to expand
There is a sender FSP and receiver FSP both have payment manager instances, core connectors, and core backends.
Payment Manager for Mojaloop simplifies the integration process by managing the security, asynchronous to synchronous API conversion, state management …etc
However, a DFSP still needs to develop a connector to connect to their backend system in order to speak with Mojaloop.
To develop the core connector, we can use a local instance of payment manager called “on-premise-deploy” (https://github.com/pm4ml/on-premise-deploy)
The Mojaloop switch and receiver FSP will be simulated by TTK and the system integrator can develop the core connector against a real payment manager instance and a TTK.
Developing Core Connector – Outbound
Let’s begin with developing the outbound functionality of a core connector.
In this scenario, the core connector should implement a few synchronous outbound API requests to the Payment Manager with the provided API specification. (Refer to the API specification here for outbound API requests https://github.com/mojaloop/api-snippets/blob/master/docs/sdk-scheme-adapter-outbound-v2_0_0-openapi3-snippets.yaml). For basic outbound transfer use case, you can look at the operations POST /transfers and PUT /transfers.
Refer to this documentation to deploy a local Payment Manager and TTK and develop the core connector https://github.com/pm4ml/on-premise-deploy#developing-your-own-core-connector
When a transfer is triggered by a core banking application through the core connector, the TTK will respond with the mock responses and the core banking application can see the transfer as successful.
Developing Inbound functionality in Core Connector
After developing and testing the outbound functionality, the system integrator may want to enable inbound transfers in their implementation.
In this scenario, the core connector should listen on a port and a few API calls to support inbound requests from Mojaloop.
Refer to this documentation for developing inbound functionality in a core connector https://github.com/pm4ml/on-premise-deploy#developing-your-own-core-connector
To test the inbound, we can trigger a transfer from TTK, and the core connector should see the inbound HTTP requests and respond appropriately. Responses from the core connector can also get validated by the TTK.
Future Plan
Achieving financial inclusion goals requires connecting as many organizations into a Mojaloop switch as possible. It is imperative that connections use best practices to ensure quality is maintained and risks are managed. Empowering System Integrators to be able to quickly, efficiently, and effectively connect core backend systems is therefore a cornerstone of the financial inclusion effort.
The future plan is to iterate on these tools and processes with the System Integrator community to refine them; so that they are easier to use; quicker to implement; of high quality; with reusable connector components that the community can share. Contact us if you are interested in joining this initiative.
