PoS on Feature Phones: USSD and SMS Interfaces for Emerging Markets

Why Feature Phones Still Dominate Emerging Market Retail#

Despite the global smartphone narrative, feature phones remain the primary device for hundreds of millions of people across sub-Saharan Africa, South Asia, and parts of Southeast Asia. In Kenya, approximately 35 percent of mobile subscribers still use feature phones. In Tanzania and Mozambique, the figure exceeds 50 percent. For rural and peri-urban retailers, the feature phone is not a temporary situation — it is a rational choice. Feature phones cost USD 10 to USD 25, last years on a single battery charge, survive drops and dust that would kill a smartphone, and operate on 2G networks available in areas where 3G and 4G coverage is patchy or absent. A retailer earning a net margin of USD 5 to USD 10 per day is not going to invest USD 100 to USD 200 in a smartphone and USD 10 per month in a data plan to run a PoS app, no matter how good the app is. The technology must meet the retailer where they are, not where the tech industry wishes they were. USSD (Unstructured Supplementary Service Data) and SMS are the two communication protocols available on every feature phone ever made. USSD is the technology behind M-Pesa and other mobile money systems — the menu-driven interface accessed by dialling short codes like *144#. SMS needs no introduction. Both work on 2G, both require zero data plan, and both are familiar to anyone who has used a mobile phone in an emerging market.

How a USSD-Based PoS Interface Works#

A USSD PoS session works like this: the retailer dials a short code, say *789#, and receives a menu. Option 1: Record Sale. Option 2: Check Stock. Option 3: Today's Summary. Option 4: Reorder Alert. Selecting Record Sale prompts for the product code — a short numeric code printed on a reference card kept by the register — followed by the quantity and payment method (cash or mobile money). The system confirms the sale with a summary screen showing the product name, amount, and updated stock level. The entire interaction takes 20 to 30 seconds. USSD sessions are server-driven, meaning the processing happens on a remote server and the phone simply displays the responses. This is an advantage because it means the retailer's device needs no storage, no app installation, and no processing power. The disadvantage is that USSD sessions time out after 90 to 180 seconds depending on the mobile operator, so complex operations must be broken into multiple sessions. The product code system is a practical compromise. A retailer with 200 SKUs cannot scroll through a text-based product list on a 2-inch screen. Instead, each product is assigned a short code — 01 for sugar, 02 for cooking oil, 03 for maize flour — printed on a laminated reference card. The retailer looks up the code and enters it. It is faster than it sounds, and regular transactions for the top 20 products are memorised within a week.

SMS as a Fallback and Reporting Channel#

SMS complements USSD for two use cases: asynchronous operations and reporting. USSD is session-based — if the network drops mid-session, the transaction is lost and must be restarted. SMS is store-and-forward — the message will be delivered when the network recovers. For retailers in areas with intermittent 2G coverage, SMS provides a more reliable channel for recording transactions. The format is structured: the retailer sends a text like "S 01 3 C" (Sale, product 01, quantity 3, Cash) to a designated number. The server parses the message, records the transaction, and sends back a confirmation SMS with the sale total and updated stock level. SMS is also the natural channel for daily and weekly summary reports. At the end of each day, the system sends the retailer an SMS summarising total sales, top-selling products, items below reorder threshold, and cash versus mobile-money split. This daily SMS becomes the retailer's business intelligence report — a single message that provides more structured insight than months of exercise-book record-keeping. The SMS format forces brevity, which is actually a design advantage. Instead of a 20-page dashboard the retailer will never read, they receive the five most important numbers about their business delivered to the device in their pocket.

Limitations and Design Trade-Offs#

USSD and SMS interfaces are not pretending to be smartphone apps. They have real constraints that the system design must acknowledge. Screen size limits information density — you cannot display a sales chart on a 128-by-160 pixel screen. Input speed is slow — T9 text entry and numeric keypads are not designed for data-intensive operations. Session timeouts limit transaction complexity — a multi-item sale with different payment methods may require multiple USSD sessions or a more structured SMS format. The product catalogue is practically limited to 300 to 500 items with short codes before the reference card becomes unwieldy. Barcode scanning is not available without a camera. Customer identification is limited to phone number, which is sufficient for mobile-money customers but excludes cash customers from any loyalty or tracking features. These trade-offs are acceptable because the alternative is not a smartphone app — the alternative is no data at all. A retailer who records 80 percent of transactions through USSD and misses the other 20 percent during rush periods still has dramatically more business intelligence than one who records nothing. The system should be designed for the common case — a single-product cash sale — to be completable in under 15 seconds, with multi-item and mixed-payment transactions handled through slightly longer flows that the retailer uses when the shop is quieter.

Bridging USSD to Smartphone When the Retailer Upgrades#

The USSD interface should not be a dead end. When a retailer eventually upgrades to a smartphone — and many will as device prices continue to fall — their transaction history, product catalogue, and business data should migrate seamlessly to the app-based PoS. This means the USSD system and the smartphone app must share the same backend infrastructure. The retailer's account, identified by their phone number, holds all their data regardless of which interface they use to access it. On day one they use USSD. On day 180 they buy a smartphone and download the app. They log in and find six months of transaction history, an established product catalogue, and trend reports they could not see on the feature phone but that were accumulating in the background all along. This migration path is critical for adoption. Retailers are more willing to invest time in learning the USSD codes and building their product catalogue if they know the data carries forward. It also means that in a household where the shop owner uses a feature phone but their child has a smartphone, the child can log in on the app and show the parent richer reports and visualisations. AskBiz supports both USSD and app-based access on a unified backend, ensuring that the transition from feature phone to smartphone is a change of interface, not a change of system.