Accepting payments in Africa. 7 chapters and a final quiz.

Chapter 1. Choosing the rail the market actually runs on.

The rail is the infrastructure that actually carries a given market's payment volume. It is determined country by country, not region by region: each of the five markets in this course has its own dominant infrastructure. Accepting payments in Africa is therefore five separate projects, not one. Kenya pays by telco wallet, Nigeria by instant interbank transfer, and Ghana by interoperable mobile money. South Africa pays by card, and WAEMU by wallet, in an open price war. The first decision in a collection project is the rail, and it comes before choosing a provider.

• Which rail carries the volume here? Not the one that gets the most press, but the one whose scale is established by a recent primary figure. In Nigeria, the answer is not “mobile money.” It is NIP.
• Can my customers use it without changing their habits? A rail that requires an app, a smartphone, or a bank account automatically excludes part of your customer base. Size that share before you choose.
• How long until we're live? A merchant account with an issuer, a connection to a national switch, and a card acquiring agreement all have different lead times. The most effective rail is not always the one you can open this quarter.
• Who settles with me, in which currency, and how many days later? This question separates two rails that look equivalent, and it is the one most often forgotten when comparing them.

Chapter 2. Building a mobile money collection flow.

Building a mobile money collection flow means connecting the merchant's system to the wallet issuer's, from payment initiation through reconciliation. The work comes down to four decisions, made in this order: which merchant identifier you obtain when the account is opened, who initiates the transaction, how the merchant learns that it succeeded, and what it is reconciled against. The last three are technical. The first is contractual: it is made weeks before any code is written, and it locks in everything else.

ALLOWED STATES
  initiated -> pending -> { succeeded | failed | unknown }
  unknown -> { succeeded | failed }        via status query or statement
  unknown -> unknown                       as long as nothing decides: THIS IS LEGITIMATE

RULE 1 — a missing notification is NOT a failure
  never switch to "failed" on a timer expiring alone
  a payment may have debited the customer without you being notified

RULE 2 — idempotency on the issuer's identifier
  key = (issuer, country, issuer_transaction_id)
  second notification with the same key -> ignored, logged, 200 OK
  answering a notification slowly triggers a resend

RULE 3 — bounded polling loop, not an infinite one
  t+20s, t+60s, t+180s, t+600s, then stop
  beyond that, the state is resolved at reconciliation, not by one more call

RULE 4 — never match on the amount
  amount, timestamp, and payer number do NOT discriminate:
  the same customer pays the same amount twice in the same minute
  more often than you would think

RULE 5 — always keep the issuer's identifier
  it is the only evidence that holds up if you request a "reversal":
  there is no chargeback, in the card sense, on these rails

• Answer the notification in under a second, then process it. Return an acknowledgment, queue the work, and process it asynchronously. Heavy business logic inside the notification handler triggers resends, and therefore duplicates.
• Store the amount in local currency, never converted. KES, NGN, GHS, ZAR, and XOF are the only amounts that hold up in a dispute. A database that stores only the euro or dollar equivalent makes reconciliation impossible and leaves any correction request indefensible.
• Mask the payer's number in storage. On these rails, the phone number is the payment identifier: treat it with the same care as a card number.
• Build the unmatched payments queue into version 1. If customers key in the reference, it will start filling up in the first week. The question is not how to avoid it but who works it, how fast, and with which screen.
• Test replays. Resend yourself a notification you have already processed, both in testing and in monitored production. If a second copy of the order ships, your idempotency is decorative.

Chapter 3. USSD: designing the flow without a smartphone.

USSD is a text-menu dialog channel that any handset can open by dialing a short code, with no data connection. It still carries a decisive share of collections in these markets. The channel is synchronous, keeps no state on the handset, has a cramped screen, and is billed per session. Those four properties set USSD apart from a mobile app, which keeps its state between screens and tolerates waiting. A flow designed by app rules ends in sessions that time out right at the moment of payment. This chapter covers designing the collection flow, not the channel's technology.

• The latency budget is your technical contract. A USSD session expires (roughly 20 to 180 seconds depending on the operator). Any slow external call in the session path kills it. The rule: respond immediately, confirm asynchronously, and never make a blocking call to your back office.
• Every screen costs you twice. The operator bills for it, often per session or per screen, and it adds a drop-off point. A seven-screen flow is not “more complete” than a three-screen one: it costs more and converts less.
• A screen holds about 182 characters. That is not a layout constraint but a copywriting one: the amount label and the payee's name must fit without truncation, in the local language.
• A short code is a scarce, regulated asset. It is assigned by the country's electronic communications regulator, not by the mobile money operator. Getting your own takes an application and lead times measured in months. Most projects therefore use the issuer's or the aggregator's code. Decide this at scoping, not during testing.
• Codes differ by country for the same operator. MTN MoMo uses *170# in Ghana, *165# in Uganda, *133# in Côte d'Ivoire, *126# in Cameroon, *182# in Rwanda, and *671# for MoMo PSB in Nigeria; M-PESA uses *334# in Kenya (codes published by the operators, 2026; check again with the local subsidiary before printing them on anything customer-facing, as they change).
• The channel is not end-to-end encrypted. The PIN protects the transaction, not the confidentiality of the transport. Nothing sensitive should travel in clear text through a menu, above all nothing that would allow a transaction to be replayed.

SESSION BUDGET — set it BEFORE writing the first screen

  usable session length       20 to 180 s depending on operator (low case: 20 s)
  read + input time           ~6 to 10 s per screen for the customer
  => 3 screens already use up most of a short session

  what your back office may consume:  < 1 s per screen
  what it may NOT do inside the session:
      - call a third-party service without a strict timeout
      - compute a price, check stock, call an ERP
      - wait for final payment confirmation

TARGET DESIGN — three screens, zero reference entry

  screen 1   confirm the item and amount          "Pay 2,500 to NAME? 1=Yes 2=No"
  screen 2   PIN                                  handled by the issuer's platform
  screen 3   acknowledgment                       "Request sent. Confirmation by SMS."
             -> final status arrives by server notification, NOT in the session

WHAT BREAKS FLOWS, MOST FREQUENT FIRST
  1. customer types in an order reference        -> typo
  2. synchronous call to a slow internal system  -> session timeout
  3. label truncated on screen                   -> drop-off from doubt
  4. amount recalculated after screen 1          -> perceived inconsistency
  5. delivery triggered on screen 3              -> delivery without payment

Chapter 4. Domestic cards, A2A rails, and recurring payments.

A domestic card scheme is a card network whose rules and brand belong to an entity based in the zone where it operates. An account-to-account (A2A) transfer rail carries a credit pushed by the payer from their account to the payee's. Alongside the wallet, each of these five markets has built its own instruments in both families, and South Africa adds one of the most sophisticated direct debit regimes on the continent. This chapter sets out what each one allows and what it rules out. Most unexplained declines in production come from assigning the wrong role to one of these instruments.

• A domestic card does not cross borders. AfriGO is designed to keep transactions inside the country; gh-link, e-zwich, and GIM-UEMOA are zone schemes. A subscription billed from a foreign entity on one of these cards will fail, and the decline will not say why. If your model relies on recurring international debits, these cards are not your instrument.
• Co-badging changes the cost, not just acceptance. When a card carries both a domestic and an international scheme, routing determines the interchange you pay. It is an acquiring parameter to negotiate explicitly, not a technical default.
• The instant rail has no two-step authorization. No pre-authorization, no delayed capture, no void: the credit is pushed, immediate, and final. Any business model built on a hold followed by a later debit (deposit, reservation, amount adjustment) has to be redesigned, not transplanted.
• The limit is a product parameter. GHS 50,000 per transaction on GIP in Ghana; KYC-tier limits on wallets, which vary by country, by tier, and sometimes by channel. A high average order value may be structurally impossible to collect on the rail you chose: check before integrating, not after.
• An instrument can be live without being used. GhQR has been technically deployed since 2020 and has disappointed commercially; the eNaira is still running, and the CBN publicly acknowledged its weak adoption in November 2025. “Available” and “used” are two different things, and only the second matters to a collection plan.

Chapter 5. Aggregator or direct: choosing, and calculating the full cost.

There are three paths to collecting payments in these markets. The first is to contract directly with every issuer and acquirer. The second goes through a domestic gateway that has already connected all of them in one country. The third goes through a pan-African aggregator covering several countries under a single contract. The choice depends on time to launch, the chain of accountability, and full cost, rather than on the technical features of the integration. That full cost goes well beyond the headline fee, which is just one line out of six, alongside settlement fees and settlement lag, FX, transaction tax, and the cost of failures and disputes.

THE SIX COST LINES. The last five are the ones people forget.

  1. COLLECTION FEE                 % of the amount, + a fixed part, often tiered
                                    and per instrument (wallet != card != transfer)
  2. SETTLEMENT FEES                payout from the merchant account to a local
                                    bank account -- billed separately, per
                                    transfer or per batch
  3. SETTLEMENT LAG                 D+0 in e-money, often D+1/D+2
                                    to the bank. Cost = cash tied up
  4. FX                             spread vs. the interbank rate, NOT the
                                    headline fee. Measure it, don't ask for it
  5. TRANSACTION TAX                a political line, variable, open to change
                                    in every budget law (see chapter 6)
  6. FAILURE AND DISPUTE COST       unmatched payments to match by hand,
                                    "reversals" to pursue, tier-1 support

WORKED EXAMPLE -- THE RATES ARE EXAMPLE PARAMETERS,
NOT OBSERVED PRICES: replace them with YOUR negotiated rates.

  Order value                                   10,000 (local currency)
  Collection fee               assumed 1.80%         180
  Fixed part                   assumed                20
  Settlement fees              assumed, amortized      8
  Cost of the D+2 lag          assumed                 3
  FX spread on repatriation    assumed 1.20%         120
  Transaction tax              country-dependent       0
  Failure/matching provision   assumed 0.40%          40
  ------------------------------------------------------------
  FULL COST                                          371  = 3.71%
  HEADLINE FEE                                       180  = 1.80%

  >>> THE RATIO BETWEEN THESE TWO LINES IS THE ONLY FIGURE
      THAT LETS YOU COMPARE TWO OFFERS.

WHAT TO DEMAND TO FILL IN THE GRID
  - a simulation on YOUR actual mix (instrument, amount, country, month)
  - the FX rate applied to a test amount on a given day,
    compared with that day's interbank rate
  - the settlement schedule: frequency, minimum threshold, fee per transfer
  - the unmatched payment rate observed at comparable merchants

• Who holds my money between collection and settlement, and under what license? The answer must name an entity and its legal status, not a brand.
• What is the contractual settlement lag, by instrument, and what can suspend it? This is the first line to negotiate, even before the fee.
• Which currency am I settled in, and who sets the rate? Settlement in local currency that you convert yourself does not cost the same as settlement converted by the provider.
• What is the actual coverage by issuer, in this specific country? An aggregator that is “present in Ghana” may cover only one issuer in three there.
• What happens when a payment arrives without a usable reference? Is there a screen, a matching API, a retention period?
• *How do I request a reversal, how long does it take, and what is the observed success rate? There is no standardized dispute framework on these rails: the provider's procedure is* your only recourse.
• What daily reconciliation mechanism do you provide? A machine-readable statement, or an export that needs reworking?
• Which limits apply, per transaction, per day, per KYC tier? And how will I be notified when they change?
• How easy is it to leave? Portability of merchant IDs, export of transaction history, notice period. The exit cost is negotiated on the way in.
• Which of the figures you gave me are audited? See the warning below.

Chapter 6. E-money licenses, FX, repatriation, and PAPSS.

Two assessments decide whether a collection project in these markets is feasible, and both come before the first API call. The first concerns licensing: whether the merchant needs its own license or collects under a third party's. The second concerns getting the money out: which route the funds take to leave the country, at what rate, and how fast. Companies that address the second question after go-live find, at best, that their margin disappears into FX.

• Work out repatriation before signing, never after the first month. The questions: which local bank, what supporting documents per outgoing transfer, what observed lead time, how much hard currency is available, and what prior approvals are needed. The answers shape your treasury model, not just your accounting.
• Transaction taxes are the region's No. 1 political risk, and they can be modeled. Ghana introduced an e-levy in May 2022 at 1.5% above a daily exemption threshold of GHS 100, cut to 1% in January 2023. Mobile money values fell by about 12% in the six months after it took effect (Bank of Ghana), before the repeal passed on March 26, 2025, and took effect on April 2, 2025. Cameroon has levied 0.2% on both sending and withdrawals since its 2022 finance law, with a flat 4 CFA francs added in 2025; Uganda taxes withdrawals at 0.5%. Every revenue forecast in these markets must include a tax scenario.
• In a monetary union, “cross-border” doesn't mean what you think. Between two WAEMU countries, a payment is technically domestic: SICA-UEMOA for clearing and STAR-UEMOA for settlement have operated since 2004 under the BCEAO, and GIM-UEMOA covers cards across all eight countries. An Abidjan–Dakar flow does not raise the FX issue of an Abidjan–Accra flow.
• Mobile money is the cheapest origination instrument for receiving money. Sending $200 to sub-Saharan Africa cost 8.78% on average in Q1 2025, vs. a global average of 6.49%, but 3.63% when originated via mobile money and 9.50% via a bank (World Bank, Remittance Prices Worldwide, Q1 2025). That is the economic reason every corridor is converging on the wallet.

Chapter 7. Testing, fraud, and daily operations.

A failure mode is a way a collection fails or gets corrupted in production. In these markets, failure modes differ from those in a card market, where disputes follow a cycle-based framework, network arbitration, and representment rules. None of those three mechanisms exists here. Correcting an erroneous payment goes through a *reversal procedure run by the issuer on request, with highly variable timelines and success rates. The checks therefore happen upstream*, and testing must cover the local failure modes, not just the happy path.

EVERY DAY, IN THIS ORDER

  1. PULL the issuer's / provider's statement for D-1
     -> source of truth. Your application log is NOT

  2. MATCH on the issuer's transaction ID
     never on (amount, time, number): not distinctive

  3. SORT discrepancies into FOUR groups, each with its own handling
     a. at the issuer, missing here      -> lost notification:
                                            create, deliver, alert
     b. here, missing at the issuer      -> phantom state:
                                            cancel, DO NOT deliver
     c. amounts differ                   -> unmodeled fees,
                                            or wrong tier
     d. unmatched (no reference)         -> matching queue,
                                            named owner, deadline

  4. RECONCILE the bank settlement received against gross collected on D-2/D-3
     gross collected - fees - settlement fees - tax = expected net
     any unexplained gap is disputed within the contractual window,
     which is short

  5. PUBLISH three indicators, every day, to the same people
     - rate of states still unknown at D+1
     - age of the oldest unmatched item
     - expected net vs. received net gap, in LOCAL currency

WHAT SHOULD TRIGGER AN ALERT, NOT A TICKET
  - an unknown state older than 24 h
  - a bank settlement missing on the contractual date
  - a fee discrepancy that repeats two days in a row