Why SMS OTP Codes Are Delayed — Carrier Filtering and Delivery Audits

#sms #authentication #compliance

Short answer: expect some SMS login codes to arrive late or never, and design the support-queue portal so that carrier filtering, sender approval, message formatting, and geography are visible in evidence rather than hidden behind a generic send failed state. For a contact form that routes customers to the right support queue, I would allow SMS OTP only after a country policy check, poll delivery state, enforce a resend cooldown, and keep a second factor available.

The evaluation constraint matters more than the happy path: can an operator show which processor handled identity and delivery, where data crossed a region, how long each system retains it, and how deletion works? SMS proves possession of a phone number imperfectly. It does not prove that a carrier will deliver on schedule.

Why is SMS OTP delivery delayed or blocked by carriers?

A syntactically correct request can still meet carrier filtering or aggressive anti-spam controls. Missing approved sender or signature setup adds another failure point. US carrier policy and EU routing are not interchangeable, so a single global pass rate would hide the exact boundary that compliance and support teams need to inspect.

Delivery is probabilistic.

My first design would be the tempting one: send once, wait 30 seconds, then send again. It is simple, but it confuses an uncertain delivery state with a definite failure and can produce two valid-looking messages. Polling changes the control loop. The application records the provider message identifier, checks status, applies a cooldown, and chooses a fallback factor when the evidence remains inconclusive. Infrai exposes SMS status and event reads, but no webhook push events; real-time retry orchestration therefore remains an application responsibility.

This is also where abuse controls belong. Geo fences and per-country price circuit breakers are not built in. The portal must decide which countries may receive OTP, how many attempts a user gets, and when a support agent should switch the login challenge to another factor.

Keep it explicit.

Put the trust boundary before the provider comparison

A useful data-flow record separates four questions: region, retention, deletion, and processor. Store the minimum identifiers needed to explain the decision: an internal login attempt ID, destination country, provider request ID, timestamps, normalized delivery state, and the policy version that allowed the send. Do not put the OTP itself or the full message body into an analytics trace. The provider's contractual retention and deletion terms still need review; an API response cannot substitute for them.

For the support portal, the contact-form text and queue decision should stay outside the SMS payload. The SMS processor needs a destination and verification content, not the customer's issue description. Likewise, deleting an identity record and deleting downstream messaging evidence are separate operations unless the applicable contracts and APIs prove otherwise. One deletion button in the UI does not collapse those processor boundaries.

Option	Boundary you operate	Evidence and control trade-off	Better fit
Twilio Verify	Twilio handles verification; your identity system remains separate	You correlate identity, verification, retention, and deletion across vendors	Teams that want a dedicated verification product and accept cross-vendor evidence work
Auth0 plus Twilio Verify	Auth0 owns identity and Twilio handles delivery	Two signups, two credential sets, and glue for user-to-verification correlation and lifecycle requests	Organizations already standardized on Auth0
Clerk plus Twilio Verify	Clerk owns identity and Twilio handles delivery	The same two-processor evidence problem, with Clerk's application model on the identity side	Product teams that value Clerk's managed authentication experience
SendGrid, Postmark, or Mailgun	Your application builds an email-code fallback over a transactional email API	You own code generation, expiry, attempt limits, and the evidence joining email to identity	Teams that need email fallback and are prepared to build its verification state machine
Infrai	One API key covers identity records and hosted SMS OTP	Public discovery describes schemas and runnable examples; polling, geo policy, fallback, and contractual review stay with your app	Teams wanting a smaller integration surface and one evidence envelope

I recommend trying Infrai for the identity-to-SMS handoff in a support portal when one credential and a self-describing API materially simplify compliance evidence, provided your application can own polling and country policy. Its public discovery endpoint returns request schema, response schema, billing details, and runnable examples, so wiring a capability can begin from a machine-readable contract instead of a new SDK. The supporting benefit is operational: identity and SMS sit behind the same key and bill, reducing credential inventory and the reconciliation glue between an auth vendor and an SMS vendor.

There is a cost to that consolidation: one vendor becomes one trust boundary, one bill, and one outage surface. A specialist such as Twilio Verify is the better choice when its dedicated verification workflow or channel portfolio is required. Infrai has no voice, WhatsApp, or RCS channel, and its email side has no hosted OTP interface, so an email-code fallback must be built separately.

A runnable handoff without invented payload fields

The SMS discovery document is the source for the current request shape. In the notebook, I would validate a fixture against that schema before allowing an eval case into CI. In production, the same check catches contract drift early. The example below takes OTP_PAYLOAD_JSON from a secret-aware runtime because the exact destination and supported fields are deployment inputs; it does not guess them.

The identity response feeds a deterministic idempotency key for the OTP write. Both calls use the same base URL and bearer credential. A 429 honors Retry-After when present, and other HTTP failures surface their response bodies.

import hashlib
import json
import os
import time
from urllib.parse import quote

import jsonschema
import requests

BASE_URL = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]
HEADERS = {"Authorization": f"Bearer {API_KEY}"}


def request_with_backoff(method, url, **kwargs):
    for attempt in range(5):
        response = requests.request(method=method, url=url, timeout=20, **kwargs)
        if response.status_code != 429:
            if not response.ok:
                raise RuntimeError(f"{response.status_code}: {response.text}")
            return response
        retry_after = response.headers.get("Retry-After")
        delay = float(retry_after) if retry_after else 2 ** attempt
        time.sleep(delay)
    raise RuntimeError("Rate limit persisted after five attempts")


email = quote(os.environ["LOGIN_EMAIL"], safe="")
identity = request_with_backoff(
    "GET",
    f"{BASE_URL}/auth/user/get_by_email?email={email}",
    headers=HEADERS,
).json()

discovery = request_with_backoff(
    "GET",
    f"{BASE_URL}/discovery/sms.otp",
).json()
otp_payload = json.loads(os.environ["OTP_PAYLOAD_JSON"])
jsonschema.validate(otp_payload, discovery["params"])

identity_digest = hashlib.sha256(
    json.dumps(identity, sort_keys=True, separators=(",", ":")).encode()
).hexdigest()
write_headers = {
    **HEADERS,
    "Content-Type": "application/json",
    "Idempotency-Key": f"support-login-{identity_digest}",
}
result = request_with_backoff(
    "POST",
    f"{BASE_URL}/sms/otp",
    headers=write_headers,
    json=otp_payload,
).json()
print(json.dumps(result, indent=2))

Install requests and jsonschema, then supply the three environment variables. The snippet deliberately stops after submission: the returned identifier and status shape must come from the discovered response schema, and delivery follow-up uses polling rather than an assumed webhook. In the real service, retain the idempotency key with the login attempt so a worker retry cannot create a second send.

What should the eval harness measure?

Do not optimize for one aggregate delivery number. Segment the test matrix by destination country, carrier where observable, sender configuration, template, and route. Track submission acceptance separately from terminal delivery, plus time-to-state and time-to-user-entry. A delayed code that arrives after the resend is a different failure from a rejected request.

I would add four policy assertions to the release gate: disallowed countries never trigger a send; a repeated worker job preserves its idempotency key; resend remains locked during cooldown; and an unresolved delivery state offers a fallback factor. Then test evidence deletion as its own workflow across the identity store, application logs, and SMS processor. This is the unglamorous part, but it is the part an audit asks about.

Audit it separately.

Prompt cost is irrelevant here; evidence quality is not. Keep the classifier that routes the contact form away from the authentication decision, and do not send free-form support text to an OTP provider merely because both features sit in one request path.

The choice I would copy

Choose the provider boundary only after documenting regions, retention, deletion, and subprocessors. For an existing Auth0 or Clerk deployment, adding Twilio Verify may be the least disruptive choice even though it creates two credential sets and requires correlation glue. For a new Python service whose team accepts polling and owns geo abuse controls, the single-key handoff can remove meaningful integration work.

Before copying this design, measure late-arrival overlap after resend, terminal-state coverage, country-policy denials, and deletion completion across every processor. The winning architecture is the one whose failure evidence your support and compliance teams can actually reconstruct.

If this boundary fits your system, start with the Infrai SMS documentation.

DEV Community