Reaching the feature phone: the case for USSD

There is a quiet assumption baked into most wallet roadmaps: that "mobile" means "smartphone app." In the markets where mobile money matters most, that assumption writes off the majority of the addressable population on day one. A large share of customers still carry a feature phone. Many who own a smartphone ration their data so carefully that an app they cannot afford to refresh is an app they do not use. If your wallet ships only as an app, you have not built for your market — you have built for the slice of it that already looks like you.

USSD is how you reach the rest. It is unglamorous, constrained, and decades old, and it is the single most important channel decision an inclusion-focused operator makes. Here is what it is, why it works, and what it takes to do it properly.

What USSD actually is

USSD — Unstructured Supplementary Service Data — is the technology behind the *123# codes you dial to check airtime. Unlike SMS, it is session-based and real-time: when a customer dials a code, the network opens a live session between the handset and a backend service, and a short conversation happens — menu, choice, menu, choice — until the task is done. It runs on the signalling channel that every GSM phone has had since the 1990s, which is exactly why it works on a twenty-dollar handset with no internet and no app.

The customer experience is a sequence of numbered menus. Dial the code. 1 for Send Money. Enter the number. Enter the amount. Confirm with your PIN. No download, no data bundle, no account setup beyond the wallet itself. For a huge population, this is not a fallback — it is the primary, and often only, way they will ever touch a digital financial service.

The whole wallet, on a dial-code

The mistake operators make is treating USSD as a cut-down menu — balance check and maybe a send, with "the real product" reserved for the app. Done properly, USSD runs the everyday wallet: send money, withdraw at an agent, Pay Bill, Buy Goods, buy airtime, check the balance and pull a mini-statement. These are the transactions people make every week, and every one of them is PIN-gated and confirmed before it posts. Richer journeys, such as applying for a loan or managing a savings goal, can follow the same pattern as the menu grows.

The detail that matters most is invisible to the customer: a USSD send and an app send are the same transaction, on the same ledger, with the same limits, the same KYC tier and the same audit trail. The channel is a different door into one house. This is not an implementation convenience — it is a correctness guarantee. If USSD and the app were separate code paths with separate rules, they would drift, and a customer's limit on one channel would differ from the other, which is exactly the kind of gap that becomes a fraud vector and a compliance finding.

The constraints that shape good USSD design

USSD is a hostile design medium, and respecting its constraints is what separates a channel people use from one they abandon mid-session.

• Tiny screens, short strings. A USSD page is a handful of lines of plain text. There is no scrolling on many handsets, no images, no styling. Every menu has to earn its characters. Long option lists must paginate with a "0. Next" convention that feels native to users who have done this for years.
• Sessions time out. Networks close idle sessions after a short, operator-controlled window — often well under a couple of minutes. A flow that asks too many questions will time out before the customer finishes, dropping them with no feedback. Good USSD design ruthlessly minimises steps and never makes the customer fetch information mid-flow that the system already knows.
• Latency is felt. Between each menu, the customer is staring at a "loading" state on a slow signalling channel. Every backend round-trip the menu engine makes is time the customer spends wondering if it broke. The engine has to be fast and has to fail clearly.
• State lives server-side. The handset is dumb; it remembers nothing between pages. The menu engine must hold the conversation state — where the customer is, what they have entered — keyed to the session, and reconstruct it on every step. Get the state machine wrong and customers re-enter data or land on the wrong screen.

How it fits the wider network

USSD does not stand alone; it is one corner of a system that has to hang together.

1. The gateway. A telco or USSD aggregator forwards each session step to a single backend endpoint. The menu engine interprets the input, advances the state machine, and returns the next screen — or a final confirmation. Supporting multiple aggregators behind one engine is what lets the same wallet run across countries and networks.
2. The agent network. A digital balance is only useful if it can become cash and back. Agents are what make USSD complete: a customer cashes in at an agent, transacts over USSD, and cashes out at another agent. Without the float network, USSD users are stranded with value they cannot spend in the physical economy most of them still live in.
3. Language. Menus should meet customers in the language they think in. In a market with several major languages, translated menu trees are the difference between a channel that includes people and one that quietly excludes them, so plan for them from the first menu you write.

Anatomy of a USSD session

Behind the menus, a USSD session is a short exchange of text between the gateway and your menu engine. Each time the customer answers, the gateway sends the whole trail of answers so far, separated by asterisks, and your engine replies with the next screen. A reply that starts with CON keeps the session open; one that starts with END closes it. A send might look like this:

Two design points follow from this format. The engine is stateless between steps, because the trail carries the whole conversation, which makes it simple to scale. And the trail contains the PIN at the confirmation step, which matters for security.

Security on a channel you do not fully control

USSD traffic passes through the mobile network and the aggregator before it reaches you, and the handset offers no app-level encryption. Good practice keeps the risk small:

• Never store the PIN. Session logs are valuable for resolving disputes, but the PIN position in the trail must be masked before anything is written to disk or shown to staff.
• Verify the PIN in the core, against a hashed value, and lock the wallet after repeated failures.
• Keep limits identical to the app. A channel with looser limits becomes the channel fraudsters prefer.
• Watch for SIM swaps. Where the mobile network provides SIM-change data, a recent swap followed by a large transfer deserves a hold or a check.
• Accept traffic only from your gateway, by network rules or shared secrets, so nobody can post fake sessions directly to your engine.
• Confirm by SMS. A receipt after every transaction gives customers a record and a prompt to report anything they did not do.

Designing menus for everyone

Many USSD users read slowly or in a second language, and some rely on family members to help. Menus that work for them share a few habits:

• Use the same order and numbering everywhere, so muscle memory builds. If Send Money is 1 today, it must be 1 next year.
• Use plain verbs: Send, Pay, Withdraw, Buy. Avoid internal product names on the main menu.
• Repeat the key facts at the confirmation step: who, how much, and the fee, before asking for the PIN.
• Write error messages that tell the customer what to do next, not just what went wrong.
• Test with real users on real basic phones, in the field, before launch and after every menu change.

Measuring the USSD channel

USSD performance is easy to ignore because it is invisible in app analytics. Track it deliberately:

USSD versus the app: not a hierarchy, a portfolio

It is tempting to rank channels — app best, web next, USSD last. That ranking encodes the bias that caused the problem. The right framing is a portfolio where each channel serves a population and a moment. The app is richer for those who have the device and the data. The web serves desktop and corporate users. USSD serves the feature phone, the rationed data plan, the patchy-coverage moment when an app will not load but a signalling session will. A serious operator runs all of them onto one core and lets customers self-select. The platform's job is to make sure they are the same wallet underneath.

Inclusion is an architecture decision

"Financial inclusion" appears in every mobile money pitch deck, usually as a value, rarely as a constraint that shapes the build. But inclusion is not a tagline you add at the end — it is a decision you make at the start, when you choose whether USSD is a first-class channel with the full product behind it or an afterthought with a balance check. The markets that leapfrogged into mobile money did so on USSD, because that is what was in people's hands. Building for them means building the channel they actually have.

Working with networks and aggregators

Most operators reach USSD through an aggregator that holds connections to several mobile networks and forwards sessions to one endpoint. Choose aggregators on reliability and reach, not only price: ask for their session success rates, their response time to your engine, how they handle network outages, and whether they can provide codes on every network your customers use. Agree service levels in writing, monitor them from your side, and keep a second aggregator in mind for critical markets. When a network changes its session timeout or routing, you want to hear about it before your customers do.

A pilot plan for a new USSD channel

1. Weeks 1–2: connect the gateway in test, run every menu path on real basic phones on each network, and measure response times.
2. Weeks 3–4: invite staff and friendly agents to use the channel with real, small amounts; collect every error message they see.
3. Weeks 5–8: open to customers in one area with active agents, track completion and drop-off by step, and fix the worst screen each week.
4. Week 9 onwards: expand area by area, adding agents ahead of demand so every new USSD customer has somewhere to cash in and out.

The pilot is also the time to write the support scripts. Customers on basic phones cannot send a screenshot, so support staff need to be able to see the session trail, with the PIN masked, to understand what happened.

Why USSD matters to the business case

USSD is sometimes seen as a cost centre for inclusion. In practice it often carries a large share of transactions in markets with many basic phones, and those customers can be among the most loyal, because switching is harder for them. Every customer who can only reach you by USSD is also a customer your app-only competitors cannot serve at all. Measured that way, USSD is less a charity and more a moat.

When things go wrong mid-session

Sessions fail: the network drops the session, the customer's balance changes between screens, or a partner does not answer in time. The customer on a basic phone has no app to check afterwards, so the channel must close every loop. If a transaction completed, an SMS receipt confirms it even when the final screen never arrived. If it did not complete, the customer should be told plainly and nothing should be deducted. If the outcome is uncertain, for example a payment to a partner that has not yet confirmed, the customer should get a message saying the payment is being confirmed, followed by the final result. Customers forgive a failure that is explained; they do not forgive money that disappears silently.

Frequently asked questions

Does USSD cost the customer anything?

That depends on the market and the agreement with the mobile network. Many operators absorb or zero-rate USSD session costs, because a free channel drives adoption among the customers who most need it.

Can USSD work without an agreement with the mobile network?

No. A USSD short code is allocated and routed by the mobile network, usually through an aggregator. Securing codes on every network your customers use is part of the launch plan.

Is USSD going away as smartphones spread?

Smartphone adoption is growing, but basic phones remain common, and many smartphone users still ration data. USSD usage in mature mobile money markets remains significant, and it is often the fallback when data coverage fails.

Can agents use USSD too?

Yes. Agents in areas with weak data coverage benefit from the same channel for serving customers, as long as their menus, limits and commissions come from the same core as the agent app.

PesaBridge treats USSD as a first-class channel: a menu engine behind a standard USSD gateway interface, backed by the agent network, and running the exact same balanced ledger, limits and fees as the apps — so the customer on a feature phone gets the everyday wallet, not a polite subset of it.