Digital solutions
USSD, mobile money & payment integrations
Reach customers on the handset they already have, and make every payment land in a record you can reconcile.
The channel is only half the job
A USSD menu or a mobile-money prompt is easy to demonstrate and hard to run well. Sessions time out mid-entry. A payment succeeds at the channel but the application never hears about it. A customer pays twice because the confirmation never arrived. The integration, not the menu, is what determines whether the service holds up under daily use.
Logitech Consultants builds USSD services and payment integrations around the transaction that has to complete: what the customer is trying to do, what the application must record, what the customer is told, and how the two sides are reconciled when a session fails halfway. We connect the channel to the system of record rather than leaving staff to match messages against a spreadsheet.
What an integration can cover
-
01
USSD enquiry and service menus
Session-based menus for enquiries, balances, references, status checks and service requests, designed for short entries, small screens and users who may be on any handset.
-
02
Mobile-money payment initiation
Payment requests raised from the application to a supported mobile-money channel, with the outcome recorded against the correct account or reference when the response arrives.
-
03
Payment status and reconciliation
Status checks, retries and exception handling so a delayed or failed confirmation does not leave a paid customer marked unpaid, or the reverse.
-
04
Online payment gateways
Card and online payment flows through supported providers, using hosted payment pages where that keeps sensitive card data outside your systems.
-
05
SMS, email and notifications
Transactional messages confirming receipt, failure or next steps, written clearly enough that customers do not call the office to ask what happened.
-
06
APIs between systems
Documented interfaces connecting the website, application or internal system to the channel, so data moves in one direction only and is not re-keyed.
How the integration is designed
One transaction, mapped end to end
We map the full path before building: what the customer enters, what the application sends, what the channel returns, what is stored, what the customer is told, and what happens on timeout, duplicate request or partial failure. Each state is written down and tested, because these are the cases that generate support calls.
- Success, failure, timeout and duplicate paths defined for every step
- Reference numbers agreed so a payment can be matched to one record
- Behaviour when the channel is unreachable, with no silent data loss
- Which system holds the authoritative status, and who may change it
Security and data handling
The application stores the minimum it needs. Sensitive credentials such as customer PINs are entered on the channel, never in our application, and card details stay with the payment provider where a hosted flow is used. Access to transaction records is role-based and logged.
Testing on the real network
Menus and prompts are tested on actual handsets across the networks in use, not in a browser emulator. We test slow responses, abandoned sessions, wrong entries and repeated submissions, then run a controlled pilot with a small user group before opening the service.
Implementation and support
Channels change; the integration has to be maintainable when they do.
- Requirements and journey mapping with the teams who handle customer queries and reconciliation today.
- Build and integration testing against the supported channel, including failure and duplicate cases.
- Controlled pilot, then full release with monitoring of failed and unmatched transactions.
- Documentation, administrator training and a support route for channel or reconciliation faults.
Questions we are asked
Which mobile-money providers and gateways do you support?
Support depends on the channel available to your organisation and the integration terms in force at the time. We confirm the specific providers, wallets and gateways during the assessment rather than promise a list that may have changed.
Can USSD work without internet access?
Yes. USSD runs over the mobile signalling channel, so it works on basic handsets without data. That is why it remains useful for customers outside smartphone coverage or with limited data.
How are failed or duplicate payments handled?
Every payment carries a reference that ties it to one record, and status checks run against the channel rather than relying on the customer's message. Duplicate submissions are detected by reference, and unresolved cases are queued for review rather than silently dropped.
Can this connect to a system we already run?
Usually, where that system exposes an interface we can work with. We review its API, database access and data model, and agree whether integration happens directly or through a middle layer.
Do we need to change our website as well?
Not always. The USSD service and payment integration can sit alongside the existing site. Where a payment page is needed, we agree whether it is built into the current site or handled on the provider's hosted page.
Related capabilities
Let’s build the right solution
Tell us what you are trying to achieve. We will help you assess the requirement, shape the architecture and identify the technology needed to deliver it.