Bulk SMS in Kenya: Prices, Sender IDs, and How to Get Started

B
Bob Mwenda
Published • 11 min read
Kenyan business professional using a smartphone for SMS customer notifications in a Nairobi office

Bulk SMS in Kenya is still one of the simplest ways to reach customers, staff, students, patients, and suppliers. The difficult part is usually not sending the first message. It is working out what you will actually pay, how sender ID registration works, and how message length affects your bill.

This guide explains Statum's current bulk SMS pricing, sender ID requirements, SMS segment billing, delivery reports, and a practical way to get started.

Last checked: 12 October 2026. Statum's rates are current at the time of writing but can change, so confirm the live rate before topping up your wallet.

Quick answer

  • The applicable pricing band is based on the wallet balance after a top-up.
  • The rates below are VAT-inclusive.
  • SMS charges are based on messages accepted by the gateway.
  • Concatenated and Unicode message parts are billed individually.
  • Sender ID registration costs KSh 10,000 per telco, VAT-inclusive, as a one-time fee with no renewal fee.
  • Sender IDs are registered independently per telco. You can register on one, two, or all three networks. There is no shared sender ID option.
  • The Statum dashboard shows the units used for each SMS.

For budgeting, think in accepted message segments. A one-segment SMS uses one accepted segment. A two-segment SMS uses two accepted segments.

Statum bulk SMS prices in Kenya

Statum uses volume bands for its bulk messaging service. Basic, Plus, Premium, and Enterprise are Statum's names for these pricing bands. They are not monthly subscription plans.

Wallet top-up amount Statum band Rate per accepted SMS segment
KSh 0-19,999 Basic KSh 1.00
KSh 20,000-99,999 Plus KSh 0.80
KSh 100,000-399,999 Premium KSh 0.70
KSh 400,000 and above Enterprise KSh 0.60

All rates in this table include VAT. The table shows the rate band applied after a wallet top-up. If a top-up moves your wallet into another band, the next SMS is charged using the rate for the new wallet balance. Earlier SMS charges are not recalculated.

What the rates mean in practice

The headline price only tells part of the story. Your usable message count depends on the number of billable message segments in each SMS.

For example:

  • A KSh 20,000 top-up at KSh 0.80 per accepted segment covers up to 25,000 one-segment SMS.
  • A KSh 100,000 top-up at KSh 0.70 per accepted segment covers up to 142,857 one-segment SMS when rounded down to a whole message.
  • A KSh 400,000 top-up at KSh 0.60 per accepted segment covers up to 666,666 one-segment SMS when rounded down.

These examples assume that every message is one segment and that the full wallet balance is used for SMS. If a message is split into two or more segments, each accepted segment counts toward the charge. That is why short, carefully written messages are easier to budget for than long messages.

How sender ID registration works in Kenya

A sender ID is the name a recipient sees as the sender of an SMS. It is useful for building recognition and making an alert or campaign easier to identify than a random phone number.

Statum's current sender ID information lists a one-time fee of KSh 10,000 per telco. The fee is VAT-inclusive and there is no renewal or recurring fee. Sender IDs are registered separately with each telco, so customers can choose to register on one, two, or all three of the supported networks:

  • Safaricom
  • Airtel
  • Telkom

There is no shared sender ID option. Registering one sender name separately on all three networks therefore totals KSh 30,000 in sender ID fees before buying SMS balance. If you only need to reach one or two networks, you can request registration for those networks without registering on all three.

The usual supporting documents are a signed and stamped authorization letter, plus a business registration, incorporation, or trademark certificate. Statum's SMS documentation gives an estimated registration period of about 2-3 business days across the supported telcos. Treat that as an estimate rather than a guaranteed turnaround, because approval depends on the information and documents submitted.

If you are sending on behalf of another company, get the authorization from the brand owner before starting registration. The sender name should be clear, recognizable, and appropriate for the messages you plan to send.

Why SMS segments affect your cost

An SMS is not always one billable message. Long text is divided into segments so it can be delivered as one joined message on the recipient's phone. Each accepted segment is billed individually.

The standard encoding limits are:

Encoding Single SMS Concatenated SMS
GSM-7 Up to 160 characters Up to 153 characters per part
Unicode or UCS-2 Up to 70 characters Up to 67 characters per part

These are global SMS encoding standards. A single emoji, smart quote, long dash, or character outside the GSM-7 character set can change the message encoding and increase the number of segments. Not every accented character causes this change because some are supported by GSM-7. If a message does not need special characters, use normal letters, numbers, straight quotes, and regular hyphens.

A simple example: a message containing 161 basic GSM-7 characters needs two segments, even though it exceeds the one-segment limit by only one character.

Before sending a campaign, test the exact text that will be used in production. Do not estimate the bill from the number of recipients alone. A better estimate is:

recipients x accepted segments per message x price per accepted SMS segment

For example, 10,000 recipients receiving a two-segment message produces up to 20,000 billable accepted segments before accounting for failed or rejected submissions.

The Statum dashboard shows the units used for each SMS, which gives you the practical record to use when checking segment consumption. For general SMS character-set background, see Twilio's SMS character limit guide.

Accepted messages are different from delivered messages

It is important to separate the billing event from the final delivery result.

The pricing basis confirmed for this guide is accepted message segments. An accepted request means the gateway has accepted the message for processing. It does not by itself prove that the recipient has opened the message or that the handset has received it.

For delivery tracking, Statum's SMS API documentation describes a request ID and delivery report callback. The callback can include the charge, account balance, result code, and result description. The Statum dashboard also shows the units used for each SMS. Store the request ID, original message, recipient, units, and charge with your internal notification or order ID so that your application can reconcile the billing and final delivery result later.

Keep the business event and the SMS notification as separate records. Confirm a payment from the verified payment result, an order from the order system, and an appointment from the booking system. A successful payment should remain successful even if its confirmation SMS is delayed or fails. The SMS notification record can stay pending until delivery handling records the outcome, while the business record follows its own verified status.

How to get started with bulk SMS

A smooth setup normally follows these steps.

  1. Define the use case. Separate transactional messages such as OTPs, payment confirmations, and order updates from marketing campaigns.
  2. Estimate your volume. Count recipients, message length, likely segments, and how often you will send.
  3. Choose the wallet band. Use the top-up amount and accepted-segment estimate to calculate the likely balance you need. A later top-up can move the wallet into a new band for the next SMS.
  4. Register your sender ID. Choose the telcos you need and submit the sender ID registration separately for each one. Prepare the authorization letter and registration or trademark documents before submitting the request.
  5. Integrate the API. Statum's SMS endpoint is https://api.statum.co.ke/api/v2/sms. The API documentation lists phone number, message, and sender ID as the main request fields.
  6. Configure delivery reporting. Receive callbacks over HTTPS, validate the incoming request according to the provider's instructions, and make your callback handler idempotent.
  7. Test with a small group. Check the sender name, formatting, encoding, unit count, delivery callback, and balance before sending to your full list.
  8. Monitor the results. Track accepted, rejected, delivered, and failed messages separately. Keep enough balance for retries only where a retry is safe and appropriate.

API integration normally requires a developer or someone comfortable with HTTP requests, credentials, callbacks, and logging. If your team needs a browser-based sending portal, Statum can provide one on request as part of a custom software development engagement. The portal is hosted on the client's side, so there is no universal public dashboard URL.

Two simple message examples

A school notice might be: "School closes at 1 pm on Friday. Please arrange pickup." Keep the final text within one segment where possible, and only send it to contacts who are allowed to receive the notice.

A payment acknowledgement might be: "Payment received. Ref ABC123. Thank you." The payment system must confirm the payment first. The SMS is a communication of that verified result, not the source of the result.

The Statum SMS API documentation also covers transactional alerts, OTPs, campaign messages, Unicode support, and delivery reports.

Bulk SMS marketing and unsubscribe practices

Marketing SMS should be treated differently from service notifications. Send campaigns to people who have given permission to receive them, keep a record of that permission, identify the sender clearly, and include a clear opt-out instruction in every marketing message that points to a working and accessible opt-out mechanism.

Kenya's Consumer Protection Regulations set requirements around consent, sender identification, and objections to direct marketing. The ODPC communication sector guidance also discusses consent and opt-out expectations for promotional messages. This article is not legal advice, but the practical baseline is straightforward:

  • Keep consent records for marketing contacts.
  • Include a clear opt-out instruction in every marketing message, with a working and accessible mechanism.
  • Process opt-out requests promptly.
  • Maintain a suppression list so an unsubscribed number is not added back by a later import.
  • Do not use a marketing list for transactional messages without a separate lawful basis and clear purpose.

With an alphanumeric sender ID, a recipient usually cannot reply directly to the brand name. Do not promise that replying STOP will work unless the sending route supports two-way replies. Use the actual supported alternative for the campaign, such as a short code, keyword workflow, web form, or customer-care channel, and make sure it updates the suppression list.

An unsubscribe process is only useful if it works consistently. Put the suppression check before every campaign send, not only when a contact first subscribes.

What to compare when choosing an SMS provider

Price matters, but it is not the only thing to compare. Ask these questions before committing a budget:

  • Is the rate VAT-inclusive?
  • Is billing based on submitted, accepted, or delivered messages?
  • Are concatenated and Unicode segments charged separately?
  • Is sender ID registration charged per telco, and is it a one-time or recurring fee?
  • Are Safaricom, Airtel, and Telkom covered?
  • Can you see the units used for each SMS and reconcile them with the charge?
  • Do you receive delivery reports with a request ID you can reconcile?
  • Can you set up an unsubscribe and suppression process for marketing messages?
  • Is the API documentation clear enough for your team to test and monitor the integration?

These questions prevent a low advertised rate from becoming an unexpected bill after a campaign is sent.

Is Statum bulk SMS a good fit?

Statum is a practical fit if you need a Kenya-focused SMS API for alerts, OTPs, customer updates, or permission-based campaigns and you want delivery reporting alongside the send request. It can also suit teams that prefer wallet-based pricing instead of a monthly plan.

Before you top up, write down the number of recipients, the exact message text, the expected number of segments, and the networks you need to reach. That small exercise will give you a more realistic budget than multiplying a headline rate by a contact list.

For SMS account onboarding, wallet top-ups, or sender ID registration, talk to Statum and tell us which telcos you need. If you need a client-hosted sending portal, ask about the custom software development option. For technical integration, start with the Statum SMS API documentation and use the same contact route for integration support.

Pricing and provider terms can change. Confirm the current rate, sender ID requirements, account-specific top-up treatment, and opt-out process before sending a production campaign.

A practical next step

Need help applying this to a real system?

Statum can help turn the idea into a scoped piece of work. See our software services, browse completed projects, read the developer documentation, or start a project conversation.

B

Bob Mwenda

Article author

Bob Mwenda is a software engineer at Statum with over ten years of experience building business applications and integrating enterprise systems. His work spans Java, Spring Boot, PHP, Laravel and Vue.js, including API integrations, payment and messaging systems, and application deployment. On the Statum blog, Bob writes about software development, business automation and the practical decisions behind building and maintaining software. His articles help business owners and developers understand implementation options, technical trade-offs and common pitfalls.

More Articles

View All →