Payments in West Africa are an infrastructure story

Payments in West Africa usually get discussed as a fintech opportunity. Large young population, low card penetration, mobile money growth. That framing is accurate and it is also the least useful part of the picture, because it describes the market rather than the machine.

What I keep running into when I build anything that has to take money is that the payment is the last step of a long chain, and most of the chain is not software.

The chain underneath one transaction

A user in Lagos or Cotonou paying five dollars for something touches most of these:

• Which rail they have access to at all. Card, bank transfer, mobile money wallet, or cash handed to an agent.
• Whether the rail is up right now. Bank downtime is not an edge case here, it is a weekday.
• Whether they trust the recipient enough to move first, given that reversals are hard and disputes are slow.
• What identity the rail demands, and whether they have the document it wants.
• Whether the currency they hold is the currency the product prices in.

A checkout page written for a market with stable card rails assumes all five are solved. Drop it into this environment and the failure looks like a conversion problem, when it is actually a rail problem five steps upstream.

The operators tell you what the constraint was

The clearest way to read the environment is to look at what actually won, and why.

M-Pesa in Kenya is the reference case. It did not start as a bank product or an app. It started as SMS on feature phones with a physical agent network doing cash in and cash out, at a time when most users had no bank account and no smartphone. The design brief was the constraint set: no data plan, no card, no branch nearby. Everything since has been built on that base rather than replacing it.

In Nigeria the split is more interesting because the constraints are different. There is a working instant transfer system, so the wallet is less of a novelty and the fight moved to reliability, cost and reach.

• OPay grew on ubiquity and cheap transfers, and picked up an enormous amount of usage during the 2023 cash crunch when bank apps were failing and people needed something that simply completed.
• Kuda went after the bank experience itself, digital first, aimed at users who already had accounts and wanted an app that did not fall over.
• Moniepoint went the other direction and built out the agent and merchant side, POS terminals in small shops, which is the part most software people ignore because it involves hardware, float and people.

Three companies, one country, three different reads on where the friction actually was. If you only look at the app screenshots they look like the same product. They are not.

Trust does more work than UX

The thing that surprised me most is how much of the design budget goes to trust rather than flow. People are not slow to pay because the button is in the wrong place. They are slow because they have been burned, or they know someone who was, and the product has given them no reason to go first.

What helps is boring and specific: showing the exact amount in the currency they hold, naming the recipient the way it will appear on their statement, confirming instantly rather than eventually, and making the failure state say what happened instead of “something went wrong.” Every one of those is a product decision, not a payments integration.

Agents are the interface

The other thing outsiders miss is that the human agent network is part of the stack. Cash gets into the system through a person, often a shop owner two streets away, and out of it the same way. That means the last mile of a digital payment is a relationship, and it carries its own float, fees, fraud patterns and trust dynamics.

Moniepoint is the clearest evidence of this. Its distribution is a network of small merchants running terminals, which means its growth curve is partly a logistics and training problem rather than a download problem. M-Pesa’s agent network is the same idea a decade earlier. You cannot design that away by building a nicer app. You can design around it by treating the agent as a user with their own needs, which almost nobody building from outside does.

Where AI agents run into this

The current wave of AI agents that book, buy and pay on a user’s behalf assumes a payment layer that barely exists here. An agent checking out with a saved card, or calling a hosted checkout that expects a card, fails at the first step for a user whose money lives in an OPay or M-Pesa balance.

There are three specific problems I keep coming back to.

The first is authorization. Most rails here confirm with a PIN, a USSD prompt or a push in the wallet app, and that confirmation is deliberately attached to a human. An agent cannot hold that credential without becoming the exact thing users are most afraid of, which is something that can move their money while they are not watching.

The second is failure handling. An agent retrying a transfer during bank downtime can produce a double debit, and a reversal here takes days rather than a tap. Any agent that touches money in this environment needs an idempotency key and a hard spending ceiling before it needs better reasoning.

The third is the last mile. An agent can arrange a purchase, but if the payout ends at an agent kiosk or a cash handoff, there is a human step it cannot complete. The realistic shape is an agent that prepares the transaction, states the amount and the recipient plainly, and hands the final confirmation to the person. That is less impressive in a demo and it is the only version I would trust with my own balance.

Regulation and currency move faster than roadmaps

Rules change, sometimes quickly, and a product that priced in one currency assumption can be wrong within a quarter. Nigeria’s cash withdrawal limits in 2023 rewrote consumer behaviour in weeks, and the naira’s devaluation moved dollar pricing far enough that any hardcoded conversion was wrong within a quarter. Anything I build now that touches money keeps the pricing, the rail, and the payout path loosely coupled, because at least one of them will change before the feature is a year old.

What I am actually arguing

Copying a payment product from a market where card rails, stable addresses and predictable banking already exist gives you something that works in the demo and fails in the field. The friction here is not temporary and it is not a sign the market is immature. It is the operating environment.

The interesting products are the ones that treat that environment as the spec.