Provider differences
Authentication, status vocabulary, retry rules, and capabilities vary by provider and country. MQPay contains that variability behind provider adapters.
Governed mobile-money product infrastructure
Turn mobile-money complexity into a payment product your institution can run.
MQPay gives approved banks, fintechs, institutions, NGOs, and platforms one operating foundation for branded collections. It connects product configuration, provider routing, payment state, pricing, ledger evidence, and reconciliation in one governed model.
Collection-first launch pathEntity-specific configurationAPI and guided product experiences
The MQPay model
One institution-facing product. Three connected planes.
Your branded journey
Checkout, payment link, API, or channel
Control plane
Tenant configuration, commercial terms, release evidence
Transaction plane
Canonical instruction and approved provider route
Financial plane
Pricing, journal evidence, reconciliation, settlement
The product experience is yours. The operating discipline is built in.
MQPay keeps each configuration change and payment outcome connected to evidence.
Why MQPay
A provider integration is only one part of a payment product.
The hard work is also commercial, operational, and financial: choosing a permitted route, protecting credentials, handling uncertain outcomes, and being able to explain every result after the fact.
Governed launch
Each entity's product, rate, connection, environment, and release are versioned, approved, and scoped to that entity.
Financial proof
The operating record includes the payment outcome and the commercial, ledger, reconciliation, and audit evidence that support it.
One platform, three responsibilities
Keep launch decisions, money movement, and financial truth in the same picture.
Your teams can focus on the customer journey and business model. MQPay provides the governed platform layer that lets those decisions become safe, repeatable operating reality.
Control plane
Configure the product you are approved to run
Entity, sub-account, product, commercial terms, credentials, and release configuration are governed as tenant-specific versions—not loose settings in an app.
Transaction plane
Use one canonical instruction, then route deliberately
MQPay accepts a consistent payment instruction and maps it through the approved provider connection, keeping provider-specific behaviour at the adapter boundary.
Financial plane
Keep the financial record connected to the outcome
Pricing snapshots, immutable journal postings, reconciliation, and settlement evidence make the payment more than a successful API response.
How an entity gets to launch
A launch path that respects the responsibilities around money movement.
MQPay is designed to move a product from onboarding to independent operation with evidence at every decision point—not simply hand over credentials and hope for the best.
- 01
Establish the operating basis
Complete entity onboarding, commercial and product eligibility, and the evidence required for the route you intend to use.
- 02
Configure, test, and approve
Shape the tenant-specific product, connect approved credentials through the protected vault flow, and collect test and approval evidence.
- 03
Promote without disturbing other entities
A governed release moves through the right environments with rollback readiness, while other tenants keep their own active configuration.
- 04
Operate from verified evidence
Use authoritative payment state, audit history, reconciliation, and settlement reporting to manage the product after launch.
Operating model
Choose a route deliberately. Operate it with evidence.
MQPay can support an entity's own approved provider connection, an agreed aggregator commercial route, or a permitted hybrid. The available route is determined by the entity's contract, country, product entitlement, and approvals.
Explore the developer workspaceNo duplicate execution
Idempotency turns a retried instruction into the same request—not a second payment.
UNKNOWN is not a failure
When a provider response is ambiguous or times out, MQPay preserves the outcome for inquiry and reconciliation instead of initiating another payment.
Tenant scope is earned from identity
Entity context comes from a trusted credential and is enforced through data, configuration, queue, and credential boundaries.
Financial history can be reconstructed
Immutable audit and double-entry financial evidence preserve the decisions, pricing, and events behind each outcome.
Built for institutions with different models
The common need is a reliable product foundation—not a one-size-fits-all payment flow.
Banks & fintechs
Add collection products without tying every customer journey to a single provider's API shape.
Schools & institutions
Offer a branded route for fees and collections while finance teams keep a clear record of what happened.
NGOs & programs
Run accountable collection programmes with explicit configuration, payment evidence, and approval trails.
Businesses & platforms
Embed mobile-money collection in the products customers already use, with an operating layer behind it.
Start with the right foundation
Make mobile money a product advantage—and keep the operating record behind it.
Begin entity onboarding to establish the commercial, technical, and operational basis for the payment product you want to launch.