Start with payment-method routing and transaction handling. In markets where mobile money adoption is high, M-Pesa, MTN MoMo, and Airtel Money generally serve different use cases from cards. Mobile money leads in bill payment, person-to-person transfers, and informal commerce. Cards tend to perform better at formal POS, e-commerce, and higher-value retail. Infrastructure supporting only one side leaves acceptance gaps.
This article examines the architecture for combining mobile money and card processing, the points where complexity emerges, and the relevant tradeoffs.
Africa's Mobile Money Market
M-Pesa is present in Kenya, Tanzania, Uganda, and several other East African markets. In Kenya, Safaricom M-Pesa is deeply integrated: for a substantial share of Kenyan adults, M-Pesa accounts are the main financial instrument. Acceptance infrastructure that omits M-Pesa therefore leaves Kenyan coverage incomplete.
MTN MoMo spans more African markets, including Nigeria, Ghana, Ivory Coast, Uganda, and others. Its geographic reach makes MoMo broadly important to West African payments infrastructure. Its API surface is fairly consistent between markets, although authentication requirements and settlement report formats vary by market.
Airtel Money serves East and Central African markets including Kenya, Uganda, Tanzania, and Zambia. It frequently overlaps with M-Pesa and gives those markets a second mobile money option.
Orange Money is active across francophone West African markets including Senegal, Ivory Coast, Mali, and others. Complete West African mobile money acceptance therefore needs Orange Money alongside MTN MoMo.
Cards and Mobile Money Serve Different Needs
The idea of "mobile money vs. cards" does not reflect actual usage. In Ghana, someone shopping in a formal supermarket may use a card, then use MoMo to send money to family in a rural area. That person may also pay a utility bill with MoMo or bank transfer rather than a card. A street-market merchant likewise accepts MoMo instead of using a card terminal.
A platform claiming African payment coverage without both methods leaves substantial volume untouched. The division is by use case, not customer type. Routing should follow the payment method presented, which can change with customer preference and transaction context.
Pattern One: Side-by-Side Integration
The simplest design keeps mobile money and card paths separate, with routing at merchant or checkout level. The mobile money layer connects directly to each operator API, including MTN MoMo API, M-Pesa Daraja API, and Airtel API. The card layer connects to the acquirer or processor. Checkout routes according to the method selected by the customer.
This design functions, but operating it becomes harder at scale. Each mobile money operator needs its own settlement reconciliation, as does the card processor. Reporting must combine multiple sources, while failures and disputes take different routes by instrument. In a few markets it is manageable. Across six to ten markets, with three to four mobile money operators per market, maintenance becomes difficult.
Pattern Two: A Unified Acceptance API
A more scalable design presents merchants with one acceptance API while hiding the instrument-specific path. The merchant or platform submits an initiate-payment request containing method details, such as card number or mobile number plus operator. The API selects card or mobile money processing, formats the relevant message, and returns a normalized response.
Merchants gain one integration and one settlement and reconciliation feed, whatever the instrument mix. The difficulty is normalizing unlike protocols. Card authorization is synchronous and usually completes in under 3 seconds. MTN MoMo sends an async push to the customer's handset, and resolution may take 30 to 120 seconds while the customer confirms on the phone.
The async interval is the central challenge. Timeout rules, customer status displays, and webhooks must allow for a mobile money result taking 2 minutes, whereas a card result arrives in under 3 seconds.
Settlement Across Payment Instruments
Card settlement uses scheme infrastructure: Visa and Mastercard settle through their own systems, Verve through Interswitch, and GHLink through GhIPSS. Mobile money settles through its operator. MTN MoMo funds arrive from MTN's payment platform, while M-Pesa settlement comes from Safaricom or Vodacom, depending on the market.
Reconciliation must therefore combine sources with different schedules. Card settlement may arrive T+1 or T+2, depending on scheme and corridor. MTN MoMo may provide daily batch files, while M-Pesa settlement in Kenya may follow another frequency. Float exposure changes by instrument during the settlement cycle.
Reconciliation breaks, where your transaction record differs from the received settlement record, occur at different frequencies by instrument. Mobile money APIs have historically produced more double-confirmation events, meaning success and error for one transaction, than card authorizations. Reconciliation must address this directly, using operator-specific deduplication for each failure mode.
Fraud Patterns by Payment Instrument
Card and mobile money fraud follow different patterns. In African markets, card fraud is concentrated in card-not-present activity, including compromised data used for international or e-commerce transactions. Mobile money fraud more often involves social engineering, with victims persuaded to disclose OTPs or approve payments on false pretenses.
A shared fraud scoring layer must still understand the instrument. Card-calibrated velocity rules do not suit mobile money's different frequency patterns. Location anomalies also differ: mobile money signals relate to the SIM card's registered location, while card signals relate to the card and device fingerprint.
A single fraud model should not be expected to score both instruments equally well. Card and mobile money require sufficiently different features and thresholds that combining them as one problem weakens both outcomes. Our architecture uses a separate model for each instrument within one risk decision framework, applying consistent approval, decline, and review logic across instruments.
Infrastructure Design Implications
For infrastructure intended to support both instruments across several African markets, adding routing and normalization at the outset costs less than retrofitting them. Separate paths are a workable starting design, but adding a unified acceptance abstraction later demands major changes to settlement, reconciliation, and fraud layers.
Our practical recommendation is to define the normalized transaction event schema before building integrations. Specify the fields for a completed record whether the payment came by card or mobile money. With that contract established from day one, instrument-specific code fits the schema instead of producing separate data structures that every reporting and analytics layer must reconcile.