A transactional SMS is an automated message sent to one person because of an event that concerns them — an OTP after a login attempt, a receipt after a payment, a reminder before a due date, a status update on an order or a claim. It is triggered by your system, sent through an SMS API, and expected by the recipient.
Why it matters
Transactional messages are the ones customers rely on. If an OTP does not arrive, a customer cannot log in or pay. If a repayment reminder does not arrive, the instalment is missed. These messages have to be sent the moment the event happens, to the right number, from a sender the customer recognises, and you need to know whether each one was delivered. That is a different problem from a marketing broadcast, and it is solved with an API and delivery reports rather than a spreadsheet.
Typical transactional messages
Authentication
One-time passwords for logins, payment approvals and number verification. See OTP SMS.
Payments and balances
Deposit and withdrawal confirmations, balance alerts, mobile money receipts, low-balance warnings.
Reminders
Loan instalments, premium and renewal dates, school fees, appointments, subscription expiry.
Status updates
Order dispatched, claim approved, application received, ticket resolved, results ready.
Service alerts
Planned maintenance, outage notices, delivery windows, meter readings.
Account changes
Password changed, new device login, contact details updated — security notices the customer should see immediately.
How transactional SMS works
- An event happens in your system — a payment posts, a user requests a code, a cron job finds instalments due tomorrow.
- Your code builds the message from a template and the event's data, and calls the Ontech BulkSMS send endpoint with the recipient's number, the text, your sender ID and your API key.
- The platform validates and queues it — number format, blacklist, credit balance — and returns a message ID immediately.
- The gateway routes it to MTN, Airtel or Zamtel based on the number prefix and submits it over the carrier connection.
- The network reports delivery, and the status is stored against the message ID. Poll it, read it in the dashboard, or have it pushed to your callback URL.
Sending a transactional message from code
One request per event. The HTTP API accepts GET or POST; the JSON API takes the same fields as a body:
# HTTP GET
curl "https://bulksms.ontech.co.zm/smsservice/httpapi?api_key=YOUR_ACCESS_ID&phone=260970000000&sender_id=YOURBRAND&msg=Payment%20of%20K450%20received.%20Ref%20TX8821."
# JSON (one or many messages per request)
curl -X POST https://bulksms.ontech.co.zm/smsservice/jsonapi \
-H "Content-Type: application/json" \
-d '{"auth":{"api_key":"YOUR_ACCESS_ID","sender_id":"YOURBRAND"},
"messages":[{"phone":"260970000000","message":"Payment of K450 received. Ref TX8821."}]}'
# → {"status":100,"message":"Success","sent":1}
The HTTP API response includes a message_id; use it to check the outcome:
curl "https://bulksms.ontech.co.zm/smsservice/status?api_key=YOUR_ACCESS_ID&message_id=MESSAGE_ID"
# → {"status":100,"message":"Success","message_id":"…","delivery_status":"delivered"}
API keys are IP-whitelisted, so add your server's address under API Keys before going live. Requests are limited to 60 per minute per account, so batch notifications through the JSON API's messages array rather than one request each. An identical message to the same number within three minutes is treated as a duplicate and suppressed, which protects you from double-sends on a retry. For sustained high volumes — a bank's alert stream, for instance — a persistent SMPP bind avoids per-request overhead. Full details are in the API reference and the SMS API guide.
Designing transactional messages well
- Lead with the fact. "K450 received" before the reference number and the thank-you.
- Include what the customer needs to act. Amount, date, reference, and where to go or whom to call.
- Use a branded sender ID. A message from ZAMBANK is trusted; the same text from a random number looks like fraud. Sender IDs are up to 11 characters and approved on an authorization letter.
- Never put a promotion in a transactional message. It confuses the customer and blurs the consent line between transactional and marketing traffic.
- Keep sensitive detail minimal. A balance alert can say "balance updated" rather than the full balance if your policy requires; a health message can say "results are ready" rather than the result.
- Store the message ID. It is how you reconcile delivery later and how support answers "did you send it?".
Delivery reports for transactional traffic
Every message returns a network delivery report with one of the states delivered, failed, rejected, queued or submitted. For transactional flows the useful pattern is: treat delivered as done, retry or offer an alternative channel on failed, and alert your own operations team if submitted lingers for a network. The delivery reports guide explains each state and the four ways to collect them.
What is A2P messaging?
A2P (application-to-person) is the industry term for exactly this: messages sent by software to a mobile user, carried over dedicated carrier connections and allowed to use alphanumeric sender IDs. The opposite, P2P (person-to-person), is a normal text between two SIMs. Transactional notifications, OTPs and bulk campaigns are all A2P; the SMS gateway is the system that carries them.