USSD billing looks simple until money starts moving across several systems.
A subscriber dials a short code, completes an action and gets charged. Behind that interaction, the USSD platform may need to communicate with charging systems, wallets, external applications and operator infrastructure.
If those systems do not stay aligned, revenue leakage can appear through unbilled sessions, duplicate charges, failed transactions or incorrect charging rules.
Good USSD billing integration starts with one decision: what exactly are you charging for?
1. Per-session charging
With session-based charging, the subscriber is charged for using a USSD session rather than for every individual action inside it.
This can work well when the service itself has value as a complete interaction.
For example, a subscriber may:
- Dial a short code
- Browse several menu options
- Complete an action
- Exit the session
Instead of charging for each menu request, the operator applies a charge based on the session.
hSenid’s USSD Gateway supports session-based charging and can integrate with an operator’s existing charging environment.
The important part is defining exactly when the charge should happen.
Charging too early can create poor customer experiences if the session later fails. Charging too late can create missed billing events.
2. Per-request or transaction charging
Another model is charging when a particular request or transaction occurs.
This is useful when only specific actions should generate a charge.
Examples could include:
- purchasing a service
- requesting paid information
- completing a payment
- activating a package
- carrying out another billable USSD action
hSenid’s documentation specifically states that the USSD Gateway supports per-request charging as well as session-based charging.
This model gives operators more control because different activities can be treated differently.
A balance inquiry, for example, does not necessarily need to follow the same charging rule as a paid service activation.
3. Subscription charging
Subscription charging is another possible commercial model for USSD services.
Instead of charging every time the subscriber uses the service, access can be linked to a daily, weekly or monthly subscription.
This can make sense for services used frequently, such as information services, content subscriptions or recurring enterprise services.
The hSenid USSD documents provided here confirm per-request and session-based charging. They do not state that subscription billing is a native charging mode, so subscription implementation would need to depend on the operator’s charging system and integration design.
That distinction matters.
Do not assume that every commercial billing model is automatically handled inside the USSD gateway itself. In many deployments, the gateway is one component in a wider charging architecture.
Charging should follow the transaction state
One of the biggest billing mistakes is treating the start of a session as proof that a transaction succeeded.
Imagine a mobile-money flow:
- Subscriber selects Send Money
- Enters the recipient
- Enters the amount
- Confirms
- Backend transaction fails
If billing has already been finalized before the transaction result is known, the customer may be charged for something they did not receive.
A better design links charging to the correct business event.
That could mean charging when a valid request is accepted, when a transaction succeeds, or according to another rule defined by the operator.
The exact rule depends on the service, but the charging point should always be deliberate.
Session management matters to billing too
Billing and USSD session management are closely connected.
hSenid’s USSD Gateway manages the initiation, management and termination of USSD sessions. It also provides session-resuming capability after unexpected timeouts within a configured period.
That becomes important when charging is involved.
If a timed-out user resumes a session, the system needs to understand whether the subscriber is continuing an existing transaction or creating a new one.
Otherwise, operators risk duplicate charging or inconsistent transaction states.
A subscriber should not be charged twice simply because the network or session interrupted the journey.
Integrate charging with the systems already running the business
Most operators already have charging infrastructure.
Replacing it just to introduce USSD rarely makes sense.
The USSD layer should integrate with existing charging systems and pass the information required to apply the correct rule.
hSenid’s USSD Gateway is designed for this type of integration, supporting different charging approaches while connecting with an operator’s existing charging systems.
The platform also exposes REST APIs for connecting third-party USSD applications to the operator network.
That matters because many USSD services depend on systems outside the gateway itself.
Watch for revenue leakage
Revenue leakage is not always a dramatic system failure.
It can be small inconsistencies repeated thousands of times.
Operators should watch for:
- completed transactions without corresponding charges
- charges without successful transactions
- duplicate charging after retries
- abnormal differences between USSD traffic and charging records
- unexpected changes in billable transaction volumes
- applications generating traffic but little or no corresponding revenue
The hSenid USSD product direction also includes application traffic monitoring, peak-usage analysis and ML-based identification of applications showing revenue-risk patterns.
That creates an opportunity to move from simply recording charges to identifying unusual commercial behaviour earlier.
Why this matters at scale
hSenid’s USSD platform documentation states that the platform can handle more than 45 million transactions per day and up to 15,000 transactions per second.
At those volumes, even a small billing inconsistency can matter.
A 0.1% mismatch across one million transactions is 1,000 transactions that need investigation.
That is why USSD billing integration should be designed alongside session handling, transaction processing and monitoring rather than added later.
The right billing model depends on the service.
Per-session charging works when the session itself is the billable unit. Per-request charging gives more control over specific actions. Subscription models can suit recurring services when the surrounding charging environment supports them.
The technical goal is the same in every case:
Charge the right subscriber, for the right action, once.
