2-Way Interactive SMS, USSD, and OTP Workflows: Architecting State Machines for MO-Triggered MT Pipelines

The Stateless Reality of Cellular Messaging

The Short Message Service (SMS) protocol is fundamentally stateless and store-and-forward. When an end-user sends a Mobile Originated (MO) message, the cellular network makes zero guarantees regarding delivery order, immediate processing, or session continuity. Yet modern enterprises routinely demand stateful user experiences over cellular channels: conversational banking, automated customer onboarding, interactive mVAS trivia, and instant Two-Factor Authentication (2FA).

Bridging this gap requires software engineers to construct resilient Finite State Machines (FSMs) capable of coordinating inbound MO triggers with outbound MT responses while gracefully handling network latency, out-of-order packet delivery, and session timeouts.

The Anatomy of a 2-Way MO-Triggered MT Interaction

A standard 2-way cellular workflow operates as a continuous loop of user prompts and system dispatches:

1. Inbound Event (MO): The user sends a keyword (e.g., "LOAN" or "BALANCE") to a dedicated shortcode.
2. Ingestion & Normalization: The gateway strips carrier-specific whitespace, normalizes unicode/emojis, maps the destination shortcode to an active application tenant, and retrieves the subscriber’s historical state.
3. State Transition: The FSM evaluates the payload against current state rules, moves to the next conversation node (e.g., AWAITING_ACCOUNT_PIN), and persists an expiry timer (TTL).
4. Outbound Event (MT): The system generates a personalized, tariff-compliant SMS prompt (e.g., “Please reply with your 4-digit PIN to confirm your balance request.”) and transmits it via SMPP submit_sm.

Architecting the State Machine

A resilient conversational state machine requires a clear state transition table and automatic dead-letter queueing for unrecognized inputs:

+---------------+           MO "APPLY"           +------------------------+
|     IDLE      | -----------------------------> | AWAITING_NATIONAL_ID   |
+---------------+                                +------------------------+
        ^                                                     |
        | Session Expired (TTL = 15m)                         | MO [Valid ID]
        |                                                     v
+---------------+           MO "YES"             +------------------------+
|   COMPLETED   | <----------------------------- | AWAITING_CONFIRMATION  |
+---------------+                                +------------------------+
                                                              |
                                                              | MO [Invalid / Other]
                                                              v
                                                 +------------------------+
                                                 | RETRY_PROMPT (Max 3)   |
                                                 +------------------------+

State Machine Implementation with Redis TTL

By coupling state persistence with Redis key expiration, sessions automatically reset back to IDLE without requiring background polling crons:

// Node.js / TypeScript Example: Managing 2-Way Cellular State
interface ConversationState {
    stage: 'IDLE' | 'AWAITING_ID' | 'AWAITING_CONFIRMATION';
    data: Record<string, any>;
    retryCount: number;
}

async function handleInboundMo(msisdn: string, text: string): Promise<string> {
    const cleanText = text.trim().toUpperCase();
    const sessionKey = `session:${msisdn}`;
    
    // Retrieve current state from Redis
    const rawState = await redis.get(sessionKey);
    let state: ConversationState = rawState 
        ? JSON.parse(rawState) 
        : { stage: 'IDLE', data: {}, retryCount: 0 };

    let outboundPrompt = '';

    switch (state.stage) {
        case 'IDLE':
            if (cleanText === 'START' || cleanText === 'JOIN') {
                state.stage = 'AWAITING_ID';
                outboundPrompt = "Welcome to MV Tech Club! Reply with your 6-digit Member ID to proceed.";
                await redis.set(sessionKey, JSON.stringify(state), 'EX', 900); // 15-min TTL
            } else {
                outboundPrompt = "Welcome! Reply JOIN to start your subscription or HELP for support.";
            }
            break;

        case 'AWAITING_ID':
            if (/^\d{6}$/.test(cleanText)) {
                state.stage = 'AWAITING_CONFIRMATION';
                state.data.memberId = cleanText;
                outboundPrompt = `Member ID ${cleanText} accepted. Reply YES to confirm daily updates ($0.50/day).`;
                await redis.set(sessionKey, JSON.stringify(state), 'EX', 900);
            } else {
                state.retryCount++;
                if (state.retryCount >= 3) {
                    await redis.del(sessionKey);
                    outboundPrompt = "Too many invalid attempts. Session expired. Reply JOIN to try again.";
                } else {
                    outboundPrompt = "Invalid ID format. Please reply with exactly 6 digits.";
                    await redis.set(sessionKey, JSON.stringify(state), 'EX', 900);
                }
            }
            break;

        case 'AWAITING_CONFIRMATION':
            if (cleanText === 'YES') {
                state.stage = 'IDLE';
                await redis.del(sessionKey);
                // Trigger downstream Direct Carrier Billing (DCB) subscription
                await triggerDcbSubscription(msisdn, state.data.memberId);
                outboundPrompt = "Success! You are now subscribed. Access your portal at https://mvtechlabs.com. Reply STOP to cancel.";
            } else {
                outboundPrompt = "Subscription not confirmed. Reply YES to confirm or STOP to cancel.";
            }
            break;
    }

    return outboundPrompt;
}

USSD vs. SMS: When to Use Unstructured Supplementary Services

In developing markets across Africa, Southeast Asia, and Latin America, Unstructured Supplementary Service Data (USSD, e.g. *123*45#) is frequently paired with SMS pipelines. While SMS is asynchronous store-and-forward, USSD establishes a dedicated real-time session (up to 180 seconds) directly between the mobile handset and the Home Location Register (HLR).

Feature	2-Way SMS (MO → MT)	Session-Based USSD (*123#)
Session Nature	Asynchronous, stateless store-and-forward	Real-time, dedicated synchronous session
Typical Latency	2 to 10 seconds per turn	<500 milliseconds instant menu update
Data Retention	Stored in phone inbox for future reference	Transient (disappears once session closes)
Hardware Support	100% of GSM/LTE/5G devices	100% of devices (including basic 2G feature phones)

The gold-standard architectural pattern uses USSD for real-time authentication and menu navigation, followed immediately by an MT SMS containing the permanent transaction receipt and content link.

Conclusion

Stateful 2-way cellular experiences unlock massive engagement and monetization across both smartphones and feature phones worldwide. By enforcing strict state machines with Redis TTL expirations, handling out-of-order packet arrivals, and deploying USSD failover paths, platform engineers can deliver bulletproof interactive telecom services that convert reliably at scale.