Mojaloop Community Central: Paul Makin

A Practical Blueprint for Merchant Payments with Mojaloop

Paul Makin — Thu, 17 Sep 2026 16:50:10 +0000

The Mojaloop Community has published the first formal release of the Mojaloop Merchant Payments Overview, providing adopters with a practical description of how merchant payments can be implemented alongside an existing Mojaloop deployment.

The document brings together the key components, architecture and operating considerations needed to support merchant payments while keeping merchant-specific functions separate from the core Mojaloop Hub.

Read the Mojaloop Merchant Payments Overview

Bringing Merchant Payments to Mojaloop

Merchant payments are an important use case for inclusive instant payment systems, but accepting a payment at a merchant involves considerably more than simply transferring funds. Merchants need to be registered and identified, appropriate know your business (KYB) checks need to be undertaken, payment acceptance mechanisms need to be provided, and schemes need to address operational and fraud risks.

The Merchant Payments Overlay is designed to provide these capabilities without adding them to the core Mojaloop Hub. The overlay brings these elements together into an architecture that adopters can adapt to their own regulatory, commercial, and operational environments.

A Flexible Merchant Registry

At the heart of the model is a Merchant Registry. Merchants are onboarded by authorized registering/acquiring DFSPs, with appropriate KYB checks undertaken before a unique Merchant ID is issued.

That identifier can then be made available to the Mojaloop-based IIPS as a routable alias, while the merchant’s DFSP maintains the definitive mapping between the Merchant ID and the account into which payments are received.

Importantly, the model does not prescribe a single way to operate the registry. The document describes both centralized and federated approaches, allowing adopters to select a model appropriate to their scheme governance and market structure.

Supporting QR-Based Acceptance

The overlay also provides a practical route to QR-based merchant acceptance. The current open-source implementation uses static QR codes, minimizing the technology required at the merchant premises. The customer scans the QR code using their DFSP’s smartphone application and enters the transaction amount.

The architecture can also be extended to dynamic QR codes, where the amount and other transaction information are incorporated into a QR code generated for an individual purchase. Numeric Merchant IDs can additionally support customers using USSD and feature phones, extending the model to a wider range of payment scenarios.

Security at the point of acceptance is also addressed. The overview describes how cryptographic signatures and a scheme-level trust model can protect QR codes against substitution or tampering. They also allow the customer’s application to verify that a QR code was issued under the authority of a participating DFSP and the scheme.

Keeping Merchant Functions Separate

For adopters, one of the main benefits of this approach is separation of concerns.

Mojaloop continues to provide interoperable routing, liquidity management and real-time funds transfer, while the overlay handles merchant-specific functions and merchant payment scheme rules. This separation allows a merchant payments service to evolve without introducing unnecessary complexity into the underlying IIPS.

The result is an approach that gives adopters a way to add merchant payments capabilities while maintaining a clear division between the core payment infrastructure and the functions specific to merchant acceptance.

Looking Ahead with LEIs

The document also points to future possibilities. Work with the Global Legal Entity Identifier Foundation (GLEIF) is extending the model to incorporate legal entity identifiers (LEIs) into merchant onboarding and payment addressing.

This creates opportunities to automate elements of KYB, strengthen merchant identity verification and, particularly for cross-border payments, use a globally recognized legal-entity identifier alongside the scheme-specific Merchant ID.

A Starting Point for Adopters

For organizations considering merchant payments, the Mojaloop Merchant Payments Overview provides more than a description of a feature. It sets out a starting architecture and operating model that can be adapted to local requirements while retaining a clear principle: keep merchant-specific complexity at the edge, and use Mojaloop for what it does best — the interoperable movement of funds between participating DFSPs.

For Mojaloop adopters looking to support merchant payments, the overview provides a practical foundation for understanding how these capabilities can fit alongside an existing Mojaloop deployment.

Read the Mojaloop Merchant Payments Overview

Workstream Status Updates

Paul Makin — Mon, 06 Oct 2025 14:00:52 +0000

Following in-depth updates at the Workstream Leads call last Thursday, 2nd October, the latest, detailed statuses of all of the workstreams can be reviewed at https://community.mojaloop.io/active-workstreams

You can also view a brief, summary version of these statuses by clicking here.

PI 28 Workstreams

Paul Makin — Thu, 14 Aug 2025 13:45:45 +0000

I've updated the list of workstreams for PI 28 - you can see them here: https://community.mojaloop.io/active-workstreams

One change is that I'm not using the airtable to give an indication of future roadmap. So not all of the workstreams are currently active. One the left hand side each has one of the following classifications:

"Active - High Priority". These are the workstreams that we need to complete with some urgency. Together they define the standard set of functionality Mojaloop deployments need in order to achieve their potential.
"Active". These are important workstreams, but we can afford to complete them at a more leisurely pace.
"High Priority Candidate". The first roadmap category, these workstreams are needed with a greater or lesser degree of urgency, but we don't currently have capacity to begin them.
"Not Yet Begun". This is the second of our roadmap categories. A workstream in this category is something we know needs to be done, and is reasonably well defined, but we do not currently have an adopter asking for it.

When you're viewing the rather crowded spreadsheet, don't forget to click on the "View Larger Version" button at bottom right.

Mojaloop Roadmap for PI 27

Paul Makin — Thu, 08 May 2025 15:47:34 +0000

The updated Roadmap for PI 27 is available in the Product Council repo in SVG format (with a link to the DrawIo source in the ReadMe file). The micro version is here:

Adapting for Impact: Strategic Shift for vNext

Paul Makin — Mon, 23 Dec 2024 09:57:09 +0000

The Mojaloop Foundation has been diligently working to make vNext a potential release candidate, as outlined in Paul Makin's "Process Towards vNext Adoption”. Significant progress has been made since the release of the Beta code, thanks to the dedicated efforts of ThitsaWorks in addressing tasks from the structured list created to guide vNext toward release candidate status. Their contributions include improving definition documents, unit testing, and the deployment process.

Why the change?

At the same time, challenges have surfaced:

Resource Constraints: Despite ThitsaWorks’ efforts, advancing vNext has been constrained by a scarcity of dedicated resources.
Refinement of vNow: In the intervening time since the inception of vNext, the previously identified limitations of the vNow codebase, such as in the area of performance, have largely been addressed, strengthening vNow’s foundations.
Momentum of vNow: With deployment projects under way with the vNow codebase, and many potential adopters showing strong interest in deploying Mojaloop—evidenced by the participation of 15 Central Banks at the recent Mojaloop convening in Kigali—the reality is that new features are being developed for vNow. This further compounds the functional gaps between vNow and vNext, with features like ISO 20022, foreign exchange and interscheme support being planned for migration to vNext, further impacting timelines for vNext’s readiness for production beyond the previously-identified issues around code readiness and documentation.
TigerBeetle’s Integration: Initially envisioned as a key benefit of vNext, this integration has not been completed, and the TigerBeetle team has now committed to integrating TigerBeetle directly into vNow.

Taken together, these factors have prompted a re-evaluation of the strategy for vNext.

What’s the new strategy?

To ensure resources are used effectively and align with customer needs, the Foundation is introducing a revised approach:

Feature, Component, and Principle Migration: vNext itself is not being abandoned, instead its strengths will be incorporated into vNow over time. Features, technical components, and principles incorporated into vNext will be analyzed for their potential to enhance vNow. For example, security improvements and concepts from the various portals will be prioritized for migration. This ensures that vNext’s innovations continue to inform and improve Mojaloop. Two dedicated workstreams have been established to oversee this process:
- “Mojaloop Evolution” will focus on identifying those vNext elements that would most benefit Mojaloop, and refactor them for the vNow codebase. This workstream will comprise members from the Mojaloop Community.
- “TigerBeetle Integration” will be dedicated to integrating TigerBeetle into the Mojaloop central ledger, and exploring new approaches to settlement. As well as members from the Mojaloop Community, this workstream will be supported by the TigerBeetle team.

All analyses and implementations will be reviewed by the Design Authority (DA) before coding begins.

Continuous Reference Architecture Review: Insights from the vNext development process have underscored the importance of evolving the approach to reference architecture reviews. Moving forward, each impactful new feature implemented in Mojaloop will prompt a re-evaluation of the reference architecture to identify opportunities for improvement. A catch-up process will also address recently implemented features like foreign exchange to assess their architectural implications.

The Mojaloop Community will continue to operate a stable roadmap and release programme which adopters can rely on and plan around, while focusing available resources on the most impactful changes. This strategy has been approved by both the Mojaloop Technical Governance Board (TGB) and the DA.

The Foundation is actively seeking community members eager to contribute to strengthening Mojaloop and driving continuous improvement of the platform.

If you are interested in joining either of the new workstreams, please refer to the details below:

For any questions or to explore opportunities to contribute, please contact James, Paul, or Julie.

Product Council Schedule for PI 28

Paul Makin — Wed, 27 Nov 2024 17:24:12 +0000

The schedule for Product Council meetings during PI 28 is under development, and will be shared here soon.

Workstreams Selected for PI 26

Paul Makin — Wed, 27 Nov 2024 16:02:39 +0000

The following workstreams have been chosen by the Community for PI 26. Note that these will be subject to monitoring, and any workstreams that have been deprioritised or have hit some form of roadblock will be removed from this list.

Workstream	Lead	Mojaloop Slack Channel
Participation Tools	@James Bush	#ws-participation-tools
Participation Tools for Fintechs	@alain Kajangwe	#ws-participation-pisp
Deployment Tools - Maintenance	@James Bush	#ws-deployment-tools
Dispute Management	@Promesse Ishimwe	#ws-dispute-management
PISP 2.0	@Paul Baker	#ws-pisp2_0
Payments Addressing	@Arunjay, Clare Rowley	#ws-payments-addressing
FX Refinement	@Paul Baker	#ws-fx-refinement
Non-Mojaloop Interscheme	@Julie Guetta	#ws-interscheme
ISO 20022 Refinement	@Julie Guetta	#ws-iso20022
Refactor Bulk Payments	@Paul Baker	#ws-bulk
Settlement 3.0 and TB Integration	@James Bush	#ws-tb-integration
Timezone Localisation	@Luis Roy Zulu	#ws-localization-pi24
Mojaloop Evolution: Integrating the Outputs of the vNext Program	@James Bush	#ws-mojaloop-evolution
Performance Optimisation	@Julie Guetta	#ws-performance-characterisation
Platform Quality and Security	@Sam	#ws-pqs-pi26
Core and Releases	@Sam	#ws-ml-core-and-releases-pi26

Mojaloop Roadmap

Paul Makin — Tue, 26 Nov 2024 16:37:44 +0000

The Mojaloop Roadmap has been updated for PI 26, following a review of the PI 25 work streams and feedback from the recent Convening/Community Meeting, which included the identification of emerging requirements and their prioritisation and placement on the roadmap.

You can download the roadmap from here in SVG or PNG format, and the source file can also be viewed here.

PISP SDK: New Sub-Workstream

Paul Makin — Mon, 23 Sep 2024 09:45:33 +0000

After the recent Product Council session discussing the proposal for an Open Banking SDK for use by fintechs and others wishing to use Mojaloop’s PISP interface, a new sub-workstream has been initiated as part of the overall “Participation Tools” workstream.

This sub-workstream is being led by Alain Kajangwe of WiredIn, and I hope that anyone with an interest in promoting the use of PISP will join the workstream. Alain will be scheduling regular update calls, and I imagine he’ll be publishing details in due course.

Given that we are now halfway through the PI, we do not expect that this new workstream will be able to fully deliver on its objectives by the time of the Convening in November!

PI 25: Mid PI Review

Paul Makin — Thu, 19 Sep 2024 15:05:38 +0000

Next week's Product Council, scheduled for Tuesday 24th September at 11:00 UTC, will be the venue for the PI 25 Mid PI Review. The leads of all of the PI 25 workstreams are asked to attend, and give an update on the progress of the workstream against the stated objectives for the PI, to give an indication of what they think the workstream will achieve by the end of the PI (mid November), and to highlight any roadblocks they are facing.

The proposed running order is:

Workstream	Lead
Participation Tools	James Bush
Merchant Payments	Karim Jindani
Interscheme	Julie Guetta, Paul Baker
On Premise Deployments	Sam Kummary, James Bush
ISO 20022	Julie Guetta, Michael Richards, Paul Baker
FX	Paul Baker, Michael Richards
Localisation	Luis Roy Zulu
vNext	Julie Guetta
Performance Optimisation	James Bush
Platform Quality & Security	Sam Kummary
Core & Releases	Sam Kummary

You'll find joining instructions on the #product-council channel on the Mojaloop Slack.

Look forward to seeing you all there.

Updated Workstream Dashboard

Paul Makin — Mon, 16 Sep 2024 14:53:26 +0000

I've updated the workstream dashboard as below, to reflect the changes in the roadmap.

Updated Roadmap

Paul Makin — Mon, 16 Sep 2024 14:49:46 +0000

I've updated the roadmap, removing those workstreams that haven't attracted contributions during this PI and moving them to a "candidates" list for consideration for adoption in a future PI.

Should the need for these workstreams become more urgent, they will be reinstated in the roadmap.

The roadmap is available in the Mojaloop GitHub, in the Product Council repo.