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.
Oldest comments (0)