01What is MO and MT messaging?
MO and MT are carrier terms for the direction of a message. A mobile-originated (MO) message starts on a mobile handset and enters the network — a customer texting a keyword to a long code or short code, or replying to an alert. A mobile-terminated (MT) message ends on a handset — an OTP, a delivery alert or a campaign SMS that a business sends to a customer's phone. Every person-to-person text is both: MO on the sender's side and MT on the recipient's.
The direction changes how a message is handled. An MT is routed by the recipient's number, so the platform must know which operator that number is on now, choose a route and pay that operator to terminate it; it is billed per message (per segment for SMS) and produces an SMS delivery report. An MO is routed by the number it was sent to: the operator hands it to whoever holds that long code or short code, who forwards it to the business. There is no receipt for the business to wait on — receiving it is the event — and it is usually included in the number's rental or priced lower, though terms vary by provider and country.
In SMPP, the protocol between a business application (ESME) and an operator's SMSC, an MT goes out as submit_sm and is acknowledged by submit_sm_resp carrying a message ID. An MO comes in as deliver_sm — the same PDU that carries delivery receipts for MTs, told apart by the esm_class field. The WhatsApp Cloud API keeps the same split in different clothes: customer messages arrive through the messages webhook and are never billed, while messages you send with POST /{PHONE_NUMBER_ID}/messages are charged per delivered message by category.
Key takeaways
- A mobile-originated (MO) message starts on a handset and enters the network; a mobile-terminated (MT) message ends on a handset.
- For a business, MO is inbound — replies, keywords, STOP — and MT is outbound — OTPs, alerts and campaigns.
- In SMPP an MT goes out as submit_sm; an MO arrives as deliver_sm, the same PDU that carries delivery receipts.
- MT is routed by the recipient's network and billed per message or segment; MO is routed by the number dialled and usually cheaper or bundled.
- WhatsApp keeps the split: inbound messages arrive by webhook and are never billed, outbound ones are charged per delivered message.
02 · How it works, step by step
How does MO and MT messaging work?
- Step 1
The business sends an MT
Your app submits the message to a gateway or SMSC —
submit_smover SMPP or an HTTP call — with the recipient's number and, in India, the DLT header, content template ID and PE ID. - Step 2
The network terminates it
The message is routed to the recipient's current operator and delivered to the handset; the terminating operator charges for it.
- Step 3
A delivery receipt comes back
The SMSC returns a receipt —
deliver_smwith the receipt bit set inesm_class— saying DELIVRD, UNDELIV, EXPIRED or REJECTD, matched to the original by message ID. - Step 4
The customer replies with an MO
Their reply to your long code or short code enters their operator's network and is routed to whoever holds that number: your provider.
- Step 5
Your app receives the MO
The provider forwards it as
deliver_smover SMPP or as an HTTP webhook. Acknowledge it, store it and attach it to the conversation it belongs to.
03MO and MT messaging in code
# MT: your application → SMSCsubmit_smsource_addr = "EXMPLE" # DLT header in Indiadestination_addr = "919812345678"registered_delivery = 1 # ask for a delivery receiptshort_message = "Your electricity bill is due on 25 Oct. Reply PAY to 9XXXXXXXXX for a payment link."# India: PE ID and content template ID travel as operator-defined optional TLVssubmit_sm_resp → message_id = "5f0c1a2b"# Receipt for that MT: SMSC → your applicationdeliver_smesm_class = 0x04 # a delivery receipt, not a customer messageshort_message = "id:5f0c1a2b sub:001 dlvrd:001 submit date:2610191030 done date:2610191031 stat:DELIVRD err:000 text:Your electricity"# MO: the customer's reply, SMSC → your applicationdeliver_smesm_class = 0x00 # an ordinary mobile-originated messagesource_addr = "919812345678"destination_addr = "91XXXXXXXXXX" # your long code / VMNshort_message = "PAY"
Outbound is submit_sm; both the receipt and the reply arrive as deliver_sm.
04MO and MT messaging: key facts and limits
- MO
- Mobile-originated: handset → network (inbound to a business)
- MT
- Mobile-terminated: network → handset (outbound from a business)
- SMPP, MT
- submit_sm, acknowledged by submit_sm_resp
- SMPP, MO
- deliver_sm with esm_class 0x00
- SMPP, receipt
- deliver_sm with esm_class 0x04
- Billing
- MT per message or segment; MO bundled or cheaper (varies)
- WhatsApp equivalent
- Inbound by webhook, never billed; outbound charged per delivery
05 · Common mistakes, and the fix
Common mistakes with MO and MT messaging
Parsing receipts as customer messages
Delivery receipts and MOs share the
deliver_smPDU. Checkesm_class, or the provider's event type, before treating text as a customer reply.Forgetting the MO side exists
A campaign that says "reply YES" needs an MO endpoint configured on the number. Test the reply path end to end before launch.
Waiting for an MO delivery report
No receipt exists for a message a customer sent you. Watch MO health through inbound volume and webhook errors instead.
Budgeting both directions the same
MT drives cost; MO is usually bundled or cheaper. On WhatsApp inbound messages are not billed at all, so leave them out of cost-per-message maths.
06Why does MO and MT messaging matter?
Mixing up the two directions breaks systems quietly: replies that never reach the CRM because no MO URL was configured, delivery receipts parsed as customer messages, or budgets that count inbound traffic as cost. Treating MO and MT as separate flows — different endpoints, metrics and prices, linked by number and message ID — is the base of every two-way messaging integration, on SMS and WhatsApp alike.
07Example: Bill reminders that invite a reply
A Hyderabad electricity distributor sends bill reminders as MT SMS from its DLT header, with "Reply PAY to 9XXXXXXXXX for a payment link" in the template. Over a month it sends 1.2 million MTs and receives about 38,000 MOs on its virtual mobile number. The flows live on separate dashboards: MT shows cost per delivered message and receipt states by operator; MO shows replies per keyword and how fast each payment link went out. When a parser change started treating delivery receipts as MOs, the MO count tripled overnight — an esm_class check fixed it.
08 · Tips from the bench
Best practices for MO and MT messaging
- Keep MT and MO on separate endpoints, queues and dashboards.
- Store each MT's message ID so receipts and replies can be linked to the original send.
- Attach an MO to the latest MT sent to that number to give the reply context.
- Alert when MO volume drops to zero — it usually means a broken forwarding URL.