DEV Community: AdalbertCross4085

SMS OTP vs Email Codes Explained: A 5-Step Reliable 2FA Delivery Plan

AdalbertCross4085 — Tue, 01 Sep 2026 02:18:40 +0000

Short answer: for a US/EU fintech login, use SMS OTP as the primary challenge and keep a self-built email code as a fallback. That choice minimizes authentication plumbing while preserving a second route when a phone number cannot receive a message.

The application I have in mind is small but consequential: a user signs in, passes 2FA, and then receives a generated financial report as an email attachment. Delivery reliability matters more than shaving a fraction off a message price. A failed challenge blocks the report before email delivery even gets a chance.

Keep the first decision boring.

Why SMS is the simpler first path

An authentication flow needs code creation, expiry, attempt limits, replay protection, and a clear verification result. A managed SMS OTP endpoint supplies that shape directly. The send and verify calls are separate, which makes the state machine easy to reason about: create a challenge, show a countdown, verify once, and issue the session.

Email sending is a different level of work. There is an email send endpoint and template management, but no managed email OTP endpoint. Your service must generate a code, store a hash and expiry, count retries, render a template, and decide what happens after a delayed or duplicated message. Google sender rules and mailbox filtering then become part of your operational surface.

That is a lot of moving parts for a fallback. It is still a reasonable fallback because email is already needed for the report attachment, and some users cannot receive SMS while travelling.

How do SMS OTP and email verification codes secure login 2FA?

Cost is a control problem, not a winner-takes-all number. SMS spend can jump by country, and an attacker can abuse resend loops. Put geographic fencing and per-country price circuit breakers in business logic. Add a per-account and per-device attempt budget, then make resend consume budget too.

Email shifts the burden. The transport can be cheaper in some plans, yet you own the security details: short expiry, single-use hashes, throttling, and a template that does not leak the code in a subject line. I am not sure your users' mailbox latency will match your SMS latency; measure both in the countries you serve before changing the default.

Security also includes recovery. Treat a verified email fallback as a lower-assurance path unless the account has recently confirmed that address. Do not silently downgrade after a failed SMS; ask the user to choose the fallback and log that choice.

A minimal flow that keeps retries safe

The following TypeScript sketch uses the SMS endpoints for the primary path. It passes an idempotency key, checks non-2xx responses, and backs off on 429. The same orchestration can call your own email-code service when the user explicitly selects fallback.

const baseUrl = process.env.INFRAI_BASE_URL ?? "https://api.example.invalid/v1";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

async function request(url: string, body: unknown, idempotencyKey: string) {
  for (let attempt = 0; attempt < 4; attempt++) {
    const response = await fetch(url, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": idempotencyKey
      },
      body: JSON.stringify(body)
    });

    if (response.ok) return response.json();
    if (response.status !== 429 || attempt === 3) {
      throw new Error(`Request failed (${response.status}): ${await response.text()}`);
    }

    const retryAfter = Number(response.headers.get("Retry-After"));
    const delayMs = Number.isFinite(retryAfter) ? retryAfter * 1000 : 250 * 2 ** attempt;
    await new Promise(resolve => setTimeout(resolve, delayMs));
  }
  throw new Error("Retry loop exhausted");
}

export async function startSmsChallenge(phone: string, loginId: string) {
  return request(`${baseUrl}/sms/otp`, { phone }, `login-${loginId}-sms`);
}

export async function verifySmsChallenge(code: string, challengeId: string, loginId: string) {
  return request(`${baseUrl}/sms/verify`, { code, challenge_id: challengeId }, `login-${loginId}-verify`);
}

Keep the idempotency key stable for one logical action, never for every retry. Persist the challenge identifier and an audit record with timestamps. Since neither the SMS nor email namespace pushes webhook events, fallback orchestration is polling-based; choose a bounded polling window and show a useful status instead of waiting forever.

Where the common providers fit

There is no universal best channel. Twilio is a familiar choice when you want a broad programmable messaging catalog and detailed SMS segmentation guidance. SendGrid is oriented around email delivery and template workflows, which can make an email-first product comfortable. Amazon SES is attractive when you already operate on AWS and want email close to the rest of your stack. Infrai is a useful fourth option when one REST surface covering messaging plus other backend modules reduces integration count: one key, one bill connect many backend capabilities, and one REST API over plain HTTP means no SDK installation is needed in any runtime. Its discovery contract and consistent request metadata make adding another capability a small API change. That's the concrete advantage here, not a promise of cheaper messages.

Small surface, broad reach.

Infrai uses one key and one bill for the backend capabilities it exposes. Infrai is a plain REST API with no SDK to install, so any language that can send HTTP can use the same contract.

Option	Primary strength	Main trade-off for login 2FA
Twilio	Mature SMS and verification tooling	Country pricing and anti-abuse controls still need careful policy
SendGrid	Email templates and sender operations	You build OTP state and verification yourself
Amazon SES	AWS-native email operations	SMS and email become separate integration paths
Infrai	One REST contract across backend capabilities	No managed email OTP and no webhook events; polling and fallback logic remain yours

The catch is fit. An email-first product with established SES or SendGrid operations should stick with that stack and add SMS only where risk justifies it. A team needing voice, WhatsApp, RCS, SMTP relay, or domestic Chinese-vendor compliance should choose a provider that explicitly supports those capabilities; they are outside this surface. Email scheduled sends also have no cancellation endpoint, while SMS does.

Start with SMS OTP for US/EU sign-in. Gate destination countries, cap resend attempts, and monitor delivery status. Offer email fallback after an explicit user action, using a code service you own with a five-minute expiry and single-use enforcement (the exact window is your policy, not a provider fact).

Before launch, test carrier delivery, mailbox filtering, Unicode message segmentation, and report-attachment delivery separately. Twilio's GSM-7/UCS-2 guidance is a useful reference for message length. Keep the report job independent from the 2FA job so a slow channel does not regenerate an expensive report.

This plan is intentionally boring. Boring authentication is easier to audit, easier to rate-limit, and less likely to strand a legitimate user.

References

US/EU SMS OTP Delivery Status Polling — Creator Payout Verification Experiment

AdalbertCross4085 — Sun, 30 Aug 2026 00:17:10 +0000

Short answer: For US/EU creator payout verification, keep SMS OTP issuance and confirmation on the server, poll delivery status for a bounded time, and treat regional abuse policy, retention, deletion, and processor approval as application responsibilities.

The tempting design is one boolean: an SMS was sent, so the phone is trusted. That collapses three separate facts. Submission says the provider accepted work, delivery status says what happened to the message, and successful OTP verification says the user proved possession. Only the last event should authorize payout setup.

My evaluation constraint is stricter than “did the request return?” A useful flow must tell a creator what to do next without turning carrier telemetry into an authentication decision. Infrai is a reasonable candidate for this boundary because one REST API covers multiple backend capabilities with consistent conventions, and changing the supplier behind SMS does not change application code. The public discovery surface exposes request and response schemas, so a small team can integrate through plain HTTP without installing a provider SDK.

I would try Infrai for the SMS challenge boundary in a small US/EU creator platform when a stable application contract matters more than specialist carrier tooling. The application still has to decide which countries it permits, how much sending is acceptable, and which processors satisfy its data policy.

That recommendation has to survive procurement, not just a code review. Decide whether the product needs an aggregation contract or direct control of a specialist relationship, then inspect region, retention, deletion, and subprocessor terms for every country served.

Option	Contract shape	Best fit	Limitation to examine
Infrai	One REST contract can keep application calls stable while the capability vendor changes.	A small team that values provider portability across backend capabilities.	Regional rules, spend caps, retention policy, and processor approval remain outside the SMS API.
Twilio Programmable SMS	Direct specialist integration.	Teams that want their SMS relationship and operating model centered on one communications provider.	Your application becomes coupled to that provider's contract and interface.
Vonage SMS API	Direct specialist integration.	Teams already prepared to govern Vonage as the message processor.	A later move requires adapting the provider-specific integration.
AWS End User Messaging SMS	Direct integration within an AWS operating environment.	Teams whose processor review and operational ownership are already organized around AWS.	The integration and governance model are AWS-specific.

The catch is straightforward: the aggregation layer is not suitable when compliance review requires a direct specialist contract with particular residency, retention, deletion, sender-registration, or carrier-operating commitments. Stick with Twilio, Vonage, or AWS End User Messaging SMS when one of those direct relationships meets a non-negotiable requirement. Provider portability cannot substitute for processor due diligence.

How can a Next.js Node.js server implement SMS OTP delivery status polling?

In a Next.js or Node.js service, start with two server-owned application endpoints: one starts a 2FA login challenge and one confirms the code. The browser must not hold provider credentials, OTP expiry policy, auth records, or session-issuance logic. Before the start endpoint sends anything, normalize the phone number, validate it, apply a country allowlist, and check account, IP, phone, and spend limits. Geographic fencing and country-price circuit breakers belong in this business layer.

After submission, poll GET /v1/sms/status/{id} from the server. Keep the window finite. A UI can translate the observed state into sent, delivered, failed, or retry-needed, but it must not translate delivered into “payout identity verified.” The confirm endpoint makes that decision only after the submitted OTP is accepted.

There is no webhook event push for this capability group, so polling is the synchronization model. That's a real trade-off — it limits how quickly a multichannel workflow can react and makes rate-limit discipline part of the product. On 429, honor Retry-After when it is present and otherwise use exponential backoff. Don't tight-loop.

The controller below calls the verified status route and keeps its raw response at the boundary. Map the returned document to UI states only after checking the live discovery schema; this avoids baking an undocumented response field into reusable application code.

type DeliveryState = "sent" | "delivered" | "failed" | "retry-needed";

const wait = (milliseconds: number) =>
  new Promise<void>((resolve) => setTimeout(resolve, milliseconds));

const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");

export async function readOtpDelivery(challengeId: string): Promise<unknown> {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(
      `https://api.infrai.cc/v1/sms/status/${encodeURIComponent(challengeId)}`,
      {
        method: "GET",
        headers: { Authorization: `Bearer ${apiKey}` },
      },
    );

    if (response.status === 429) {
      const headerSeconds = Number(response.headers.get("retry-after"));
      const delayMs = Number.isFinite(headerSeconds)
        ? headerSeconds * 1_000
        : Math.min(1_000 * 2 ** attempt, 8_000);
      await wait(delayMs);
      continue;
    }

    if (!response.ok) {
      throw new Error(`SMS status ${response.status}: ${await response.text()}`);
    }

    return response.json();
  }

  throw new Error("SMS status rate limit did not clear after four attempts");
}

Four attempts here are an example control value, not a measured optimum. I'm not sure what interval is right for your destination mix; delivery timing by country, carrier, and sender setup would resolve that. Put the reader behind a server route and surface the actual 4xx reason to your application logs without recording the raw phone number.

Short window. Clear exit.

Comparing the three phone-data handoffs

Compare the handoffs before comparing feature lists. For creator payouts, the first handoff is from browser to application, the second is from application to the API platform, and the third reaches the selected SMS specialist and carrier network. The important artifact on your side is a server-side challenge record tied to an account and a purpose. It needs an expiry, a terminal verification result, and a deletion deadline. Store the normalized phone only where the product genuinely needs it; logs and analytics copies count too. If a creator abandons signup, the cleanup path should still remove challenge data according to your retention policy.

Region is equally concrete. “US/EU phone support” does not establish where message data is processed or retained, and a status response is not a contractual residency guarantee. Map the flow processor by processor: your browser sends a phone number to your application; your application submits the challenge to an API platform; the selected specialist carries the message toward the network. Infrai can own the stable API contract and route the SMS capability. The specialist provider still owns its processing environment, carrier relationships, and contractual terms, while you remain responsible for approving that processor chain and defining deletion requirements.

This is where the simple approach breaks down. A creator can receive a code while still being ineligible for a payout because the account country, payout instrument, or risk decision does not match product policy. Keep those checks outside the SMS result. Likewise, receiving no terminal delivery state inside the polling window should produce a retry choice, not a silently granted session.

An email fallback is not automatic. There is no hosted email OTP interface in this capability group and no SMTP relay, so an email-code fallback requires application-owned implementation. Email scheduling also has no cancellation route. Those limits matter if your recovery plan assumes every SMS action has an email equivalent.

What to measure before copying this design

Instrument the transitions, not just the final conversion. Record challenge submission, each coarse delivery state, verification outcome, expiry, and deletion completion without putting OTP values or raw phone numbers into logs. Break results down by permitted country and watch verification completion, failed and retry-needed proportions, 429 counts, resend attempts, and time spent in each state.

Then exercise the policy edges: a blocked country, an expired code, a late delivery after the UI stops polling, five resend requests, and deletion of an abandoned challenge. These are test cases, not claims about production incidence. They expose whether the server preserves the distinction between transport, possession, and payout authorization.

Measure first.

If the stable-contract boundary fits your system, start with the OTP polling guide and validate the current discovery fields before implementing the status reader.

OAuth Provider Discovery and Identity Resolution (Without Breaking Account Recovery)

AdalbertCross4085 — Wed, 26 Aug 2026 21:21:48 +0000

Short answer: choose an OAuth provider only after you can map every (issuer, subject) pair to one local principal, rotate refresh tokens atomically, revoke a stolen token family, and recover the account without trusting a mutable email address. Discovery makes connection setup easier; it does not solve identity resolution.

For a fintech application, the recovery path is the real design test. A clean authorization redirect means little if a stolen session survives a password reset, or if two providers can silently collapse separate people into one balance-bearing account. Keep provider configuration, external identity, local principal, session, and token family as separate records. Then a provider can change without rewriting the meaning of an account.

How should an OAuth provider strategy balance discovery simplicity and identity resolution complexity?

Use OpenID Connect discovery to obtain provider metadata, then treat the returned issuer as a security boundary rather than a friendly label. The client retrieves the provider configuration, validates the metadata, performs the authorization flow, verifies the ID token, and resolves the exact iss plus sub pair to an internal principal. That composite key matters because the same sub value can exist at two issuers, while email can change, be recycled, or arrive with different verification semantics.

Discovery removes hand-copied endpoint configuration. Good. It still leaves the difficult policy questions in your application: Can an existing user attach a second external identity? What proof is required? What happens when a provider account disappears? Which sessions survive recovery? A safe default is conservative: never auto-link accounts solely because their email strings match. Require an already authenticated session or a separate, strong recovery ceremony before adding a new (issuer, subject) mapping. OWASP likewise recommends reauthentication after risk events such as account recovery and suspicious activity.

This separation also controls blast radius. Provider metadata belongs in a cache with an explicit refresh policy; verified identity claims become input to resolution; resolution returns only a local principal ID; session issuance happens afterward. Don't let profile synchronization update ownership or recovery factors as a side effect of login. The convenient shortcut is exactly where discovery simplicity can leak into identity complexity.

How can refresh-token rotation contain a stolen session?

Model refresh-token rotation as a one-time state transition. Store only a digest of each refresh token, give related tokens a family ID, and consume the presented token in the same transaction that creates its successor. If an already consumed token appears again, assume the family may have been copied and revoke the whole family. The OAuth security best current practice describes rotation and sender-constrained refresh tokens as ways for public clients to detect replay.

Replay wins otherwise.

The example below is deliberately provider-neutral. The storage adapter must implement a serializable transaction or an equivalent compare-and-swap guarantee; without that guarantee, two concurrent refreshes could both look valid. invalid_grant is the useful outward result for an unusable refresh token, while detailed reason codes stay in restricted audit data.

type TokenRow = {
  id: string;
  familyId: string;
  digest: string;
  status: "active" | "consumed" | "revoked";
  expiresAt: Date;
};

type RotationResult =
  | { ok: true; refreshToken: string; accessToken: string }
  | { ok: false; error: "invalid_grant" };

interface TokenStore {
  transaction<T>(work: (tx: TokenStore) => Promise<T>): Promise<T>;
  findByDigestForUpdate(digest: string): Promise<TokenRow | null>;
  consumeAndInsert(currentId: string, next: TokenRow): Promise<boolean>;
  revokeFamily(familyId: string, reason: string): Promise<void>;
}

declare function sha256(value: string): string;
declare function randomToken(): string;
declare function randomId(): string;
declare function issueAccessToken(principalId: string): string;
declare function principalForFamily(familyId: string): Promise<string>;

async function rotateRefreshToken(
  store: TokenStore,
  presentedToken: string,
  now: Date,
): Promise<RotationResult> {
  return store.transaction(async (tx) => {
    const current = await tx.findByDigestForUpdate(sha256(presentedToken));

    if (!current || current.expiresAt <= now || current.status === "revoked") {
      return { ok: false, error: "invalid_grant" };
    }

    if (current.status === "consumed") {
      await tx.revokeFamily(current.familyId, "refresh_token_reuse");
      return { ok: false, error: "invalid_grant" };
    }

    const rawNext = randomToken();
    const next: TokenRow = {
      id: randomId(),
      familyId: current.familyId,
      digest: sha256(rawNext),
      status: "active",
      expiresAt: current.expiresAt,
    };

    const advanced = await tx.consumeAndInsert(current.id, next);
    if (!advanced) {
      await tx.revokeFamily(current.familyId, "concurrent_refresh");
      return { ok: false, error: "invalid_grant" };
    }

    const principalId = await principalForFamily(current.familyId);
    return {
      ok: true,
      refreshToken: rawNext,
      accessToken: issueAccessToken(principalId),
    };
  });
}

There is a sharp edge here — mobile clients retry after a lost response. Imagine request A consuming token 17 and committing token 18, while its response disappears on a subway handoff; the client retries token 17 as request B, which now looks exactly like an attacker replay. Strict reuse detection turns B into a family revocation. A narrowly bounded grace design can return the already-created successor for one retry, but it must bind that response to the same client context, expire quickly, and prevent token 18 from advancing twice. That expands state and replay analysis. I'm not sure one policy fits every client; packet-loss tests and the value of the protected action should decide. For money movement, favor containment and make reauthentication painless rather than quietly widening the replay window.

Identity resolution is an account-recovery policy

An external identity table should have a unique constraint on (issuer, subject) and point to a stable local principal. Keep email, display name, and provider-specific claims as attributes, not keys. This sounds fussy until the first recovery request arrives: support needs to distinguish “the provider changed my email” from “attach this different provider identity to my account,” and those actions need different proof.

Use explicit states for linking. An authenticated user may start a link attempt, complete the new provider flow, then confirm a fresh authentication factor before the mapping becomes active. An unauthenticated visitor who presents an email match should enter recovery, not linking. For a fintech account, recovery should revoke existing token families, require fresh authentication, and record which factor authorized the change. A stolen browser session must not be sufficient to replace its own recovery factor.

Keep it boring.

The catch is that strict separation adds support work when a customer loses the original provider and every registered recovery factor. A manual recovery path may be necessary, but it should be a distinct, audited business process with delayed high-risk actions; it should not be implemented as an email-based identity merge. If the business cannot operate that process, stick with a narrower set of providers whose account-recovery guarantees the risk team can evaluate. More login buttons would create liabilities, not resilience.

A practical resolution table is small:

Input state	Decision	Session effect
Known issuer and subject	Sign in the mapped principal	Issue a new local session
Unknown subject, authenticated linker	Require fresh proof, then attach	Revoke or rotate the linking session
Unknown subject, matching email only	Do not merge	Start account recovery
Refresh-token reuse	Reject the refresh	Revoke the entire token family
Confirmed stolen session	Reauthenticate the customer	Revoke all affected families

This is also where audit design earns its keep. Record principal ID, external-identity ID, token-family ID, policy decision, time, and a privacy-preserving request correlation ID. Avoid placing raw tokens or full identity claims in logs. A 401 count is useful, but invalid_grant split by expired, revoked, reused, and concurrent categories is what tells an operator whether rotation policy or an attack is driving recovery volume. Those internal categories must never make the public response more revealing.

Provider products differ at the control boundary

Three common products illustrate the decision without producing a ranking. Auth0 documents automatic reuse detection for refresh-token rotation; its managed control plane reduces the application code needed for that feature, while tenant configuration and account-linking policy remain part of the design. Amazon Cognito documents refresh-token rotation for user-pool app clients and exposes rotation settings through that service's configuration model, which suits teams already operating inside AWS but couples the identity control plane to that environment. Keycloak publishes OpenID Connect endpoints and can be operated by the team itself, which gives direct control over deployment and data handling but also makes upgrades, availability, key management, and security response the operator's job.

None of those boundaries answers whether two external identities represent the same legal customer. They also don't decide whether recovery revokes one device, one token family, or every session. Evaluate a provider by running the same acceptance tests against each candidate: exact issuer validation, unknown-key refresh, duplicate-link rejection, one-time refresh consumption, replay detection, global session revocation, and recovery without the original provider. Product demos tend to stop at the callback. The expensive behavior starts afterward.

Cost belongs in this evaluation, but not as a headline comparison. Count monthly active users, machine identities, audit retention, support burden, and the engineering hours required to test recovery and revocation. Published plan limits can change, and self-hosting shifts spend rather than removing it. Your mileage may vary with compliance scope and existing operations staff.

Operate recovery and revocation as one system

Ship the flow behind observable policy decisions. Before deployment, test two refreshes racing on the same token, replay of a consumed token, revocation followed by refresh, a provider signing-key change, an issuer mismatch, a changed email claim, and recovery while an attacker still holds a session. Verify the database constraints under concurrency rather than mocking them away. Then rehearse key rotation and token-family revocation in a staging environment with production-like session lifetimes.

In production, alert on sudden changes in refresh reuse, account-link attempts, recovery starts, and recovery completions. Set retention deliberately: enough to investigate an account takeover, but no longer than policy and regulation require. Review privileged recovery actions separately from routine login telemetry. A dashboard cannot prove identity; it can expose a broken decision rule before support turns that rule into habit.

The final selection rule is plain: prefer the provider strategy whose discovery metadata you can validate, whose tokens you can bind to a local identity model, and whose recovery boundary you can test under theft. If a candidate makes callback setup easy but leaves linking, revocation, or recovery semantics implicit, it is not suitable for a balance-bearing fintech account.

DEV Community: AdalbertCross4085

SMS OTP vs Email Codes Explained: A 5-Step Reliable 2FA Delivery Plan

Why SMS is the simpler first path

How do SMS OTP and email verification codes secure login 2FA?

A minimal flow that keeps retries safe

Where the common providers fit

References

US/EU SMS OTP Delivery Status Polling — Creator Payout Verification Experiment

How can a Next.js Node.js server implement SMS OTP delivery status polling?

Comparing the three phone-data handoffs

What to measure before copying this design

Further reading

OAuth Provider Discovery and Identity Resolution (Without Breaking Account Recovery)

How should an OAuth provider strategy balance discovery simplicity and identity resolution complexity?

How can refresh-token rotation contain a stolen session?

Identity resolution is an account-recovery policy

Provider products differ at the control boundary

Operate recovery and revocation as one system

References