IOSOR

IOSOR Learn

Inbound auto-reply loops: how echo bots drain the prepaid wallet

How B2B teams keep two-way SMS honest — STOP/HELP as policy, caps on auto-reply, inbound webhook discipline, and why unbounded echo burns prepaid before anyone notices.

An inbound auto-reply that always answers is not "great CX." On a rented DID it is a prepaid drain: two bots, two humans with auto-ack, or a HELP script that quotes the original message can bounce until the wallet is empty. Product sees "engagement." Finance sees a hole. Ops inherits a 02:00 incident with no owner.

IOSOR keeps inbound on the same white-label prepaid surface as outbound: MO events, keyword replies, and debit lines live in your account. Near USD 1,000+ monthly platform usage, loop samples and per-thread debit become commercial review material. Catalog live without a loop cap is a promise finance cannot defend. A number still in setup is not a two-way inbox.

Auto-reply loops drain prepaid

Pattern What it looks like Wallet effect
Bot ↔ bot echo Two auto-acks bounce forever Unbounded outbound debit
HELP that quotes the inbound Payload replayed as a new send Duplicate segments
After-hours ping-pong "We got your message" on every retry Night burn with no human
Webhook retry storm Same MO processed twice Double reply, double debit

Inbound retries happen. If your consumer is not idempotent, every webhook retry becomes another auto-reply. See inbound webhook retries. Pair loop detection with low-balance stop controls so the wallet can halt remaining echoes.

STOP/HELP versus unbounded echo

STOP and HELP are policy, not cute bots. STOP must honor opt-out and stop the thread — including auto-replies. HELP must be a short, brand-safe path with real hours, not an echo of the customer's last sentence. Unbounded "we received your SMS" on every MO is not HELP. Write the keyword page before the first conversational send; see STOP and HELP policy. If STOP "usually works," you have luck, not a policy.

Caps product and finance can defend

  1. Per-thread outbound cap — max auto-replies per DID + customer id per window.
  2. Idempotent MO handling — one inbound event, one reply, even when webhooks retry.
  3. Quiet after STOP — no marketing, no "are you sure," no second HELP.
  4. Low-balance halt — remaining auto-replies stop before silent overdraft theatre.

Export one incident: inbound event → auto-reply → ledger line. If you cannot pull that chain, you do not have two-way control. Name an owner for the cap; without an owner it disappears next sprint.

Two-way inbox honesty

Two-way is an operating system, not a toggle. Who reads first, which numbers can receive and send, what never lands in a shared channel, how after-hours works.

Red flags

  • Auto-reply with no per-thread cap
  • HELP that repeats the inbound payload
  • STOP that still triggers a marketing ack
  • Webhook retries that double-send replies
  • Catalog live with no loop owner
  • Errors that dump foreign brand names
  • After-hours echo with no human path

Start with IOSOR

Write STOP and HELP copy that support can read aloud. Set a per-thread auto-reply cap in staging, then force a duplicate MO webhook and confirm the wallet sees one reply, not two. Simulate a bot echo until spend stops. Export one inbound-to-debit chain so finance can see where the loop would have emptied the prepaid balance.

IOSOR takeaway

An inbound echo is a wallet fire. One MO must produce one reply; a duplicate webhook or a bot ping-pong must stop spend, not multiply it.

Do: cap replies per thread and kill the loop on echo. Don't: run unlimited auto-reply on inbound or debit the same MO twice.

Was this guide helpful?

Related guides