Everything worth knowing, nothing that isn't.
How MO works in two-way SMS
When a subscriber texts your virtual long number or short code, their operator's SMSC receives an MO submit, looks up the registered destination (your aggregator), and forwards it via SS7 MAP-MO-FORWARD-SHORT-MESSAGE or via SMPP deliver_sm (with esm_class flag indicating MO, not DLR). Your aggregator's gateway delivers it to your webhook.
Why MO billing differs from MT
MT is billed to the sender (you, the enterprise). MO is billed to the originator (the consumer, on their plan). On premium short codes, MO can be reverse-billed to the consumer at a premium rate that you share in — this is how donation campaigns and premium content monetised in the 2000s. For modern A2P, premium MO is largely dead; standard MO is free to the consumer.
What MO requires from your aggregator
An inbound virtual number (long number, short code, or alphanumeric two-way capable). Many short codes don't support MO — they are MT-only. Long numbers always do, but consumer recognition is weaker. For two-way conversational use cases see /products/two-way-sms.
MO in WhatsApp and RCS
The MO/MT terminology is GSM-native. In WhatsApp Business API, the equivalent terms are 'inbound message' (MO-equivalent) and 'outbound message' (MT-equivalent). The semantic is identical; the protocol is HTTP/JSON webhooks instead of SMPP PDUs.
MO vs MT at a glance
| MT (mobile-terminated) | MO (mobile-originated) | |
|---|---|---|
| Direction | To the handset | From the handset |
| Enterprise example | Every A2P message you send | Replies, STOP / START / HELP keywords |
| Billed to | The sender (enterprise) | The originator (consumer) |
| Requires | Sender ID + route to destination | Inbound virtual number or short code |
| SMPP carrier | submit_sm | deliver_sm (MO esm_class) |
| WhatsApp / RCS term | Outbound message | Inbound message |