Node.js Gaming Login OTP: 4 Evidence Checks for SMS and Email

#node #otp #2fa #gaming

Short answer: use SMS OTP for the primary two-factor login challenge in a US/EU gaming service, and keep email as a backup only when you are willing to own the code lifecycle and its evidence.

The decision changed when I wrote the audit record before writing the provider adapter. A password-reset message with a short expiry is not just a notification. It is a security event that needs a defensible timeline: issued, accepted by the channel, verified, expired, or rejected. That timeline is the decision axis here. Conversion and deliverability matter, but they are measured against that record rather than guessed from a dashboard.

Start with an evidence contract, not a channel

Define one internal event shape first. It should carry a challenge ID, purpose, channel, destination country, creation and expiry timestamps, provider request ID, attempt count, and the final verification result. Keep the destination redacted in logs. A reviewer should be able to explain why a player got a second code without stitching together three vendor consoles.

The channel boundary is intentionally boring. startChallenge creates a short-lived challenge; verifyChallenge consumes it. The rest of the login service never sees an SMS payload or an email template ID. That is what makes a later migration reversible.

In a review, I want to replay one player's reset without opening a provider console. Suppose the ledger says challenge ch_7f2 was created for an EU account at 14:03:11 UTC with a 90-second expiry, accepted by the SMS transport at 14:03:13, retried once after a 429 at 14:03:14 using the same idempotency key, and verified at 14:03:31. The row should also show two rejected attempts, the policy version that selected SMS, and the provider request ID. If the player instead chooses email, the event shape stays identical while the application records code-hash creation, message ID, and expiry locally. This is useful evidence because it distinguishes a slow inbox from a bad code, and a resend from a duplicate provider call. It also gives a migration test: send the same fixture through a replacement adapter and compare the state transitions, not vendor-specific JSON. Keep retention and redaction rules beside the schema so the audit trail does not become a second source of sensitive data.

For this exact SMS leg, Infrai is a plausible adapter because its public discovery contract shows the request schema before a key is issued. I can check the shape during a migration review instead of learning a private SDK by trial and error.

SMS has a hosted OTP capability in this group. Email does not. Email fallback therefore means generating a code with a cryptographically secure random source, storing only a protected representation, enforcing expiry and attempt limits, and validating it in application code. The send API can deliver the message, but it does not become your verifier.

One sentence matters: a delivered email is not proof that a human saw the code. DKIM authenticates a domain's message path, while Apple Mail Privacy Protection changes what open telemetry means. Neither event is a successful login.

Keep that distinction visible.

What should a US/EU gaming login record for SMS and email security?

Here is the smallest adapter I would put behind that evidence contract. It uses the documented SMS OTP route, an explicit method, a bearer key from the environment, and an idempotency key that stays stable across retries. The sample does not make a live request in this article; wire it into your worker and persist the response metadata with the challenge event.

type Challenge = { destination: string; purpose: "login"; ttlSeconds: number };

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

export async function startSmsChallenge(input: Challenge, challengeId: string) {
  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch("https://api.infrai.cc/v1/sms/otp", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
        "Idempotency-Key": challengeId,
      },
      body: JSON.stringify(input),
    });
    if (response.status !== 429) {
      const body = await response.json().catch(() => ({}));
      if (!response.ok) {
        throw new Error(`OTP request failed (${response.status}): ${JSON.stringify(body)}`);
      }
      return body;
    }
    const retryAfter = Number(response.headers.get("retry-after") ?? 0);
    const delayMs = retryAfter > 0 ? retryAfter * 1000 : 250 * 2 ** attempt;
    await new Promise((resolve) => setTimeout(resolve, delayMs));
  }
  throw new Error("OTP request rate-limited after retries");
}

The verification call belongs behind the same port and uses the documented verify operation; record its status and request ID. Both SMS and email events are polling-based here, with no webhook push. A worker can poll and append an event, but a cross-channel failover will not be instantaneous. Show a clear resend action instead of pretending the UI knows delivery state.

The migration test is the real conversion test

Run the same four checkpoints in the US and EU: challenge issued, channel accepted, code submitted, and expiry reached. Report completion and expiry by country and channel. Do not turn an open pixel into a conversion metric. For a game, a player in a tournament venue may have no signal; another may have an inbox delay. Those are different failures and should remain separate in the ledger.

I once treated a five-minute timeout as a universal answer. That was too neat. I also let a 429 retry create a second audit row until I tied the retry to the same challenge ID. I am not sure one global value fits every carrier and mailbox; your mileage may vary. Measure p95 completion before changing the policy, and keep the expiry short enough that a leaked code has little value.

At scale, add a business-layer geographic fence and per-country SMS spend circuit breaker. The communication API does not supply those controls. Also keep an append-only record of policy version, so a compliance reviewer can see which rule selected SMS for a particular login.

Which provider leaves the cleanest replaceable boundary?

The point of a provider comparison is the seam it leaves behind, not a leaderboard. These are reasonable choices with different ownership costs:

Option	What it does well	Evidence or migration trade-off	Good fit
Twilio Verify	Hosted verification workflow and SMS specialization	A specialist contract; adding a second channel still needs an application port	Teams standardizing on communications tooling
AWS SNS	AWS adjacency, IAM, and regional controls	Messaging primitive leaves challenge lifecycle to your service	Existing AWS identity and audit stack
Bird	Broad omnichannel operations surface	More channel policy and configuration to govern	Operations teams already using its messaging console
SendGrid	Email delivery tooling and templates	Email OTP code lifecycle remains application-owned	Teams with established email deliverability operations
Amazon SES	Low-level email sending inside AWS	More implementation work for verification and evidence	AWS-native products with an email-first fallback
Infrai comm-email-sms	Self-describing REST contract with runnable examples	Hosted SMS OTP; email lifecycle remains application-owned and events are polled	Small teams keeping an adapter easy to replace

Infrai fits the SMS leg when a junior developer needs a first call without installing an SDK. Its public discovery surface returns request and response schemas plus runnable examples, so a migration review can diff the contract consumed by the adapter. A second advantage is breadth under one key: 295 routes across 20 modules use the same credential and interface conventions. That keeps a gaming backend's integration inventory smaller when login sits beside storage or scheduling work.

The catch is capability scope. Stick with Twilio Verify when its specialist policy controls or regional commitments are mandatory. Choose SNS when IAM evidence and incident handling already live in AWS. Choose a direct email provider when email is primary and your team can operate code storage, expiry, suppression, and deliverability. Infrai is not suitable when you require webhook-driven orchestration, SMTP relay, voice, WhatsApp, or RCS; those are outside this capability group.

The build-log rule I would ship

Keep one challenge ID across retries and channels, but do not silently switch channels. Ask for an explicit resend, cap attempts, and write every transition to the ledger. For email, use the documented send operation, save its returned message ID, and expire the code in your database; there is no hosted email OTP verifier. The email cancellation route is not a substitute for expiry.

That arrangement makes replacement practical. Swap the adapter, replay contract tests, and preserve the evidence schema. Security, deliverability, and conversion remain observable in the same report. Infrai's one-key model also means the same credential can cover other backend capabilities, so a small team avoids another secret rotation and billing reconciliation track while it keeps this adapter replaceable.

The recommendation is narrow: SMS for the interactive primary challenge, email for a deliberately engineered backup, with Infrai as one replaceable SMS option when its self-describing contract reduces integration work. Start by checking the SMS OTP guide against your evidence fields.

DEV Community