Selling into West Africa: what your platform must handle

A platform designed for a European market works technically in West Africa. It does not sell, or barely, and the explanation rarely lies in the product: it lies in four decisions taken — or not taken — before development.

None of the four is technical. They are contractual and financial choices, and they are what then determine the architecture. Taking them afterwards means rebuilding the checkout.

Why cards are not enough

In most countries of the region, mobile payment — an account attached to a phone number, funded in cash through a local agent — is the dominant electronic payment method. It is not an alternative to cards: for a large share of buyers, there is no card.

A platform offering only card payment therefore does not offer a narrow choice; it offers no way to pay. It is the most common breaking point, and the most expensive, because it occurs at the last step, after all the acquisition work.

Two practical consequences follow, often overlooked. Mobile payment happens in several steps away from your site — the buyer receives a prompt on their phone, enters a code, confirms — which requires a waiting page and a confirmation that does not arrive immediately. And the buyer can abandon at any step without your site being told: you therefore have to poll the state of the transaction rather than wait for it.

Decision 1 — aggregator or direct integration

Each mobile money operator exposes its own technical interface, with its own rules and its own commercial agreement. Two paths are open, and neither is better in the abstract.

	Aggregator	Direct integration
What you integrate	One interface, several operators behind it	One interface per operator
Contracts to sign	One	One per operator, and per country
Time to launch	Short	Long, depends on each approval
Cost per transaction	Higher: the aggregator's commission is added	Lower
Dependency	One more intermediary in the chain	As many relationships to maintain

The rule of thumb: an aggregator suits a launch, a market test, or a plan targeting several countries at once. Direct integration becomes interesting when volume makes the commission difference significant — and that is a calculation, with your own figures.

One point to check either way: real coverage per country. An aggregator that “covers West Africa” does not necessarily cover the dominant operator in the country you care about. The market is not homogeneous: each country has its own operators, regulation and habits.

Decision 2 — the settlement delay

Money collected is not money available. Between the customer's payment and the transfer to your account there is a delay, specific to each provider and each contract, compounded by currency and repatriation questions if your company is established elsewhere.

That delay has three direct consequences on your cash flow, and they must be known before you set your commercial terms:

• When do you ship? On payment confirmation, or on actual receipt? Both answers are defensible, but the second lengthens the delay the customer experiences.
• How do you handle a refund requested before settlement, on money you do not yet hold?
• In which currency are you settled, and who carries the exchange risk?

Commission rates and delays vary from one contract to the next, and are negotiated on volume. Which is why no figure appears here: the only useful figure is the one in your own contractual proposal.

Decision 3 — failed payments

Failures are more frequent than with cards, often for ordinary reasons: insufficient balance, expired confirmation code, transaction ceiling reached, network dropped mid-operation.

What separates a usable platform from another is not the failure rate — you do not control it — but what the site displays next. Three requirements:

• A message that says what to do. “Payment declined” helps nobody. “Your mobile account balance is insufficient, top up and try again” prevents an abandonment.
• The order preserved. The buyer must find their basket and resume where they stopped, without retyping everything.
• Double debits handled explicitly. It happens that a customer is debited while the confirmation never reaches your site. You need a verification and correction procedure, and an address to report it to. Without that, every case becomes a dispute.

Decision 4 — accounting reconciliation

This is the quietest point and the one that becomes unmanageable fastest. Every operator transaction carries a reference; every order carries its own. If nothing links the two automatically, someone reconciles them by hand — and that person will spend more and more time on it as volume rises.

Two rules suffice, provided they are set from the start. Your order reference must be passed to the operator and appear in its statement; and the transaction reference returned must be stored with the order. It sounds obvious, and it is regularly omitted: the checkout works perfectly without it, and the problem only appears at the first accounting close.

A payment you cannot attach to an order is not money collected: it is a line to justify.

Designing for constrained networks

Three requirements, which incidentally improve the platform everywhere else.

Page weight. On a mobile connection billed by volume, every unnecessary megabyte is an expense for the buyer. The checkout should be the lightest path on the site, not the richest.

Recovery after a drop. A connection failing during payment must not lose the order. State lives on the server, never only in the browser.

Asynchronous confirmation. Do not make validation depend on the customer being on your page. The operator's notification must be able to arrive later, and the order to validate itself — the buyer having already closed their browser.

Questions to ask before choosing

1. Which operators, in exactly which countries, and with what real coverage?
2. What delay between collection and settlement, and in which currency?
3. How is a refund triggered, and within what time?
4. Is there a full test environment, simulating failures and not only successes?
5. What does the transaction statement contain, and can I export it in a format my accounting can use?
6. What is the procedure for a double debit, and who handles it?

The fourth question is the one that most often decides. A provider whose test environment only simulates successes will have you discovering half the cases in production, on real orders.

A note on where we stand

We build from Lomé, and the constraints described here are the ones we meet on our own projects — not a reading of a market study. That is the only reason this article exists, and also the only time we mention it.

Our Web & Mobile Development page covers building these platforms. If you are at the costing stage, describe your project: the four decisions above move the estimate more than the number of pages.