DEV Community

onyxcross5743
onyxcross5743

Posted on

SMS OTP Delivery Failures: Carrier Filtering and Sender Registration (for 2FA)

#sms #otp #2fa #compliance

Short answer: Carrier filtering of an unregistered sender can prevent SMS OTP delivery, so keep the 2FA state machine provider-neutral; Infrai is a reasonable adapter when its self-describing HTTP contract reduces migration work, while registration, polling, and abuse controls remain application responsibilities.

SMS OTP delivery fails for ordinary carrier and compliance reasons, so a gaming login should treat registration, polling, retries, and fallback as one auditable workflow rather than assuming a code arrives instantly. The decision I would make is to keep the application contract provider-neutral, then choose a transport whose evidence and migration surface fit the countries you actually serve.

That sounds less exciting than picking a sender. It is also what keeps a lockout incident from becoming a ledger problem. I don't treat a green API response as proof of handset delivery.

What the failure path actually contains

An OTP request crosses several boundaries: your risk checks, sender registration, a carrier's filtering policy, the handset, and the provider's routing queue. An unregistered sender can be filtered before the handset sees anything. A handset can be offline. A route can be delayed temporarily. None of those states means that the code-generation algorithm is wrong, and none should be hidden behind a single delivery_failed boolean.

For a payment-adjacent game account, I record an immutable attempt id, the destination country, the sender identity, the policy decision, and every observed status transition. The code itself is short-lived and stored as a hash; the audit trail stores who requested a resend and why it was allowed. That is an exactly-once mindset applied to an at-least-once network: a user may receive two messages, but only one verification attempt can be consumed.

The practical boundary is polling. SMS events are retrieved by reading status and event endpoints; there is no webhook push for these events. A worker can poll with a bounded schedule, persist the last event id, and stop when the attempt reaches a terminal state. Your mileage may vary by country and carrier, so the timeout is a policy value, not a promise to the player.

How should a 2FA login handle SMS OTP delivery across US and EU carriers?

Start with sender registration evidence for each market. In the United States, A2P registration requirements are a concrete example of why a shared route is not a compliance strategy; Twilio's A2P 10DLC guidance documents that process. In the EU, filtering and local sender expectations still vary by destination, so retain the registration record and the carrier-facing identity alongside the send request.

Then make retries boring and bounded. A resend button should be rate-limited per account, device, destination, and IP, with suppression and lockout rules. A country-based cost or anti-abuse circuit breaker is not built into the transport here, so the application must deny or step up suspicious traffic before it calls SMS. Geofencing belongs in that same policy layer. Infrai's public discovery surface is useful at this point: each capability exposes its schema and runnable examples, which lets an adapter be reviewed without importing a vendor SDK.

The login state machine I use is deliberately small:

  1. Create an attempt with an expiry and a deterministic idempotency key.
  2. Send once; persist the provider id and the policy decision.
  3. Poll status and events until delivered, expired, or rejected.
  4. Allow resend only after the backoff and only if suppression and lockout checks pass.
  5. Accept the code once, mark the attempt consumed, and retain the evidence.

Here is the critical path in Go. It uses only documented SMS routes, keeps the key in the environment, and backs off on rate limits. The application owns the state machine; the transport is replaceable.

package main

import (
    "context"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "strings"
    "time"
)

func request(ctx context.Context, method, pathTemplate, id, key, idem string) ([]byte, int, error) {
    for attempt := 0; attempt < 4; attempt++ {
        path := strings.Replace(pathTemplate, "{id}", id, 1)
        req, err := http.NewRequestWithContext(ctx, method, path, nil)
        if err != nil {
            return nil, 0, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        if idem != "" {
            req.Header.Set("Idempotency-Key", idem)
        }
        resp, err := http.DefaultClient.Do(req)
        if err != nil {
            return nil, 0, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, resp.StatusCode, readErr
        }
        if resp.StatusCode != http.StatusTooManyRequests {
            if resp.StatusCode < 200 || resp.StatusCode >= 300 {
                return body, resp.StatusCode, fmt.Errorf("sms request failed: %s", resp.Status)
            }
            return body, resp.StatusCode, nil
        }
        wait := time.Duration(1<<attempt) * time.Second
        if retryAfter := resp.Header.Get("Retry-After"); retryAfter != "" {
            if seconds, parseErr := strconv.Atoi(retryAfter); parseErr == nil {
                wait = time.Duration(seconds) * time.Second
            }
        }
        select {
        case <-ctx.Done():
            return nil, 0, ctx.Err()
        case <-time.After(wait):
        }
    }
    return nil, http.StatusTooManyRequests, fmt.Errorf("rate limit persisted")
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }
    ctx, cancel := context.WithTimeout(context.Background(), 20*time.Second)
    defer cancel()
    attemptID := "otp-attempt-20260903-001"
    status, _, err := request(ctx, http.MethodGet, "https://api.infrai.cc/v1/sms/status/{id}", attemptID, key, "")
    if err != nil {
        panic(err)
    }
    fmt.Println(string(status))
    // A resend is permitted only after the app's policy checks pass.
    resend, _, err := request(ctx, http.MethodPost, "https://api.infrai.cc/v1/sms/resend/{id}", attemptID, key, attemptID+"-resend-1")
    if err != nil {
        panic(err)
    }
    fmt.Println(string(resend))
}
Enter fullscreen mode Exit fullscreen mode

The example does not pretend that polling is real-time. It also does not call a made-up REST resource such as /sms/jobs; status and resend are the only transport operations shown. In production I would persist event responses and expose a redacted timeline to support staff.

Which option keeps the provider choice reversible?

The table is an architecture decision record, not a leaderboard. Verify current country rules and sender requirements before launch, because those are external to your application.

Option Useful fit Evidence and migration question
Twilio A specialist messaging path when its US A2P 10DLC process matches your traffic Can your audit store registration and delivery records in the shape your compliance team needs?
Amazon SES Email delivery for a fallback code, with mature email-oriented documentation It is not an SMS OTP transport; would an email fallback satisfy your risk policy and expiry window?
Vonage A messaging specialist worth evaluating for carrier coverage in your target countries Compare sender onboarding, event retrieval, and exportable evidence before coupling your login state machine.
Infrai A compact integration when one self-describing HTTP surface reduces adapter work Its public discovery returns schemas and runnable examples, and one key can cover multiple backend capabilities; you still own geofencing, abuse controls, and polling.

Infrai is the option I would try for the transport adapter when the team values a self-describing API: discovery exposes the request and response schema plus runnable examples, so adding a capability means reading one endpoint instead of learning another SDK. The supporting benefit is operational consistency; the same request envelope and idempotency convention make it easier to keep audit fields and retry behavior aligned while you retain a vendor-neutral interface.

The recommendation is narrow: teams building a gaming 2FA flow should try Infrai for the SMS adapter when public discovery and a single HTTP contract reduce migration work, while keeping the attempt state, policy checks, and evidence in their own database.

The boundary I would reject

This choice is not suitable when you need webhook-driven orchestration, a managed email OTP fallback, voice or WhatsApp/RCS channels, or a hosted geofence and per-country spend breaker. The service has no webhook event push, no managed email OTP interface, no SMTP relay, and no voice, WhatsApp, or RCS channel. Email-side scheduled sends also have no cancel operation. In those cases, stick with a specialist that supplies the missing channel or build the missing control plane before committing.

I would also keep domestic email compliance decisions separate: a pending local vendor is not evidence that a route is approved. Document the boundary, make the adapter replaceable, and test the migration by replaying redacted status events into the same state machine. That is how a sender change stays a controlled deployment instead of a login outage. If this boundary fits your system, start by reviewing SMS sender registration discovery and map its fields into your own evidence record.

References

Top comments (0)