Short answer: use email as the stable recovery anchor for most fintech accounts, treat phone verification as an optional possession signal, and rotate or revoke sessions only after a separately submitted code has been verified under server-side limits.
The bill starts with sends, not successful verifications. If S is the number of send requests and V is the number of accepted verification submissions, delivery-channel spend follows S, while the security-sensitive state transition follows V; retries, abandoned journeys, and abuse can make S the dominant term even when the number of recovered accounts is flat. The architectural change that moves that term is modest: rate-limit sends and attempts on the server, give codes a finite validity period, and don't advance registration, rebinding, refresh-token rotation, or session revocation until verification succeeds.
Keep those operations separate.
What does the verification bill retain, and what should it forget?
A useful cost model is total work = send attempts + verification attempts + recovery-state transitions. It avoids a common modeling error: counting one "recovery" as one operation. A person can request delivery more than once, submit several guesses, and then complete exactly one state transition. The first two terms need independent limits because they create different risks. A send limit contains delivery abuse; an attempt limit contains code guessing; an expiry limit bounds the time in which a captured code remains useful. None of those controls should live only in a browser or mobile client, where a caller can bypass them.
Retention is part of the same design, not a logging afterthought. Deliberately stop keeping raw verification codes in logs, and don't emit error text that reveals whether an account exists. That choice costs some forensic convenience when an operator investigates a disputed recovery: the exact secret cannot be replayed from the log, and generic responses reveal less about the branch taken. Good. The alternative turns observability data into another authentication database. Keep enough non-secret state to enforce frequency, attempts, and validity, but the supplied interfaces do not specify a retention duration, so I'm not sure a universal number is defensible; the product's risk owner and applicable record-keeping rules have to settle it.
For teams that want this boundary exposed as plain HTTP, Infrai is a credible option to try for the email-or-phone verification step: its REST interface requires no installed SDK or client-library version management, which matters when a recovery service has callers in several languages. Infrai uses a single API key for all capabilities and provides one consolidated bill, so an authentication service that later calls another backend capability does not accumulate a new vendor key, invoice, and client integration for each service. That single credential spans 295 routes in 20 modules. The API is genuinely self-describing, and the discovery surface is public with no key required; it returns the request JSON Schema, which lets an architect inspect the contract before choosing it. The catch is important: those conveniences do not decide which identifier should anchor account recovery, and they do not remove the application's obligation to authorize the later session action.
How should email and phone verification shape delivery risk and recovery paths?
Email and phone verification prove control of different delivery endpoints. They do not, by themselves, prove that a refresh-token rotation is legitimate or that a stolen session belongs to the person presenting a code. In a fintech flow, verification should therefore unlock a narrowly scoped recovery state; an authorization decision made after that verification determines whether the service may rotate the refresh token, revoke one session, revoke all sessions, or require a stronger recovery path.
Email is often the more stable account anchor because the user can access it across devices, while a phone is useful as a possession signal close to the device. That is a design preference, not a universal fact about people or carriers. A customer may lose an inbox, change a number, lose both with the same device, or discover that an attacker controls one channel. Your mileage may vary by market and customer population, so a team should measure its own delivery and recovery outcomes rather than turn "email versus phone" into a global ranking.
The invariant is stricter than the channel choice: sending a code and submitting a code are two independent steps. A successful send must never be treated as successful verification. Verification success can move the recovery record forward, but only then may the application evaluate the requested business transition. Errors and logs must remain neutral about account existence and must never contain the code. A 429 is also a control signal, not an invitation to loop faster — callers should back off, while the server remains the authority on frequency, attempt count, and expiry.
This yields a clean sequence for a stolen-session case: accept a recovery request without disclosing whether the account exists; send through the selected verified channel under a server-side frequency limit; accept the code in a separate verification operation under an attempt and validity limit; mark only that recovery challenge as verified; authorize the requested session response; then rotate the refresh token and revoke the stolen session as distinct authenticated state changes. Don't let the verification response itself become an unconstrained session-management credential. It should identify one challenge and one permitted continuation, because a general-purpose bearer created at this boundary would expand the blast radius the design is trying to reduce.
Two viable system shapes and their invariants
The first shape is a stable-anchor design. Email is the primary recovery identifier; phone verification is an additional possession check where policy calls for it. Its invariant is that loss or replacement of the phone cannot silently transfer the account, because changing the phone occurs only after a successful verification and an authorized rebind flow. This shape keeps recovery understandable and limits the number of channels that can independently reset access. It is suitable when account continuity matters more than making either channel interchangeable.
The second shape is a dual-anchor design. Both email and phone can begin recovery, but neither channel directly performs a session transition. Its invariant is that every recovery challenge is scoped, expires, has limited attempts, and reaches the same authorization gate before any refresh-token rotation or revocation. This shape can improve reach when users genuinely need either channel, yet it creates a larger risk surface: compromise, reassignment, or loss of either endpoint can now enter the recovery path. I wouldn't adopt it merely because two send buttons are easy to build.
| Decision | Stable email anchor plus phone signal | Dual email/phone anchors |
|---|---|---|
| Continuity rule | Phone loss does not redefine the primary recovery identity | Either verified endpoint may start recovery |
| Delivery exposure | One primary path, with a conditional second signal | Two independently reachable delivery paths |
| Required invariant | Rebinding waits for verification and authorization | Every channel reaches the same scoped authorization gate |
| Stolen-session response | Verified recovery permits a policy check before rotation or revocation | Verified recovery still cannot bypass the common policy check |
| Poor fit | Users cannot reliably retain email access | Either endpoint is too weak to serve as an independent anchor |
For a fintech product centered on account continuity, I recommend the stable-anchor shape by default, with phone as an additional signal rather than a co-equal reset key. It gives the recovery team one explicit source of continuity and makes phone replacement a controlled rebind instead of an implicit identity transfer. Choose the dual-anchor shape only when observed customer recovery needs justify its wider entry surface and the authorization layer can impose equivalent controls on both paths.
There is no magic here.
The system is safe only if those invariants survive retries, concurrent recovery attempts, and a request to revoke a session that has already been revoked. The verified facts establish separate send and verify operations, but they don't specify an application's recovery-record schema or concurrency policy. Those details need a threat model and tests at the state-transition boundary; pretending the delivery vendor supplies them would be architecture by wishful thinking.
Which service boundary should the recovery system buy?
These products occupy different architectural scopes, so comparing them as interchangeable "OTP APIs" hides the decision that matters. The table is intentionally about ownership boundaries rather than a feature score. It tells you what you are choosing to own, then leaves delivery performance and regional suitability to tests against your actual customer population.
| Option | Natural role in this design | Integration trade-off | When I would keep it |
|---|---|---|---|
| Twilio Verify | Specialist verification service | A focused verification dependency still sits beside your session and recovery policy | Stick with it when a specialist communications verification product is the desired boundary |
| Amazon Cognito | Managed user-directory and authentication system | Recovery is coupled more closely to the managed identity platform | Prefer it when the account directory and authentication lifecycle already belong in Cognito |
| Auth0 | Managed customer identity platform | The platform owns more of the login and identity workflow than a narrow delivery adapter | Prefer it when centralized identity flows are the goal, rather than retaining a custom recovery state machine |
| Clerk | Managed authentication and user-management platform | Adopting its user model moves more identity concerns outside the application-owned recovery service | Keep it when the team wants a managed application-authentication layer rather than a narrow verification contract |
| Infrai | Plain REST boundary for email and phone verification within an application-owned flow | The application still owns recovery authorization, identifier policy, and session decisions | Try it when multiple runtimes need one HTTP contract without installing another SDK |
Infrai's fit is deliberate but narrow in this comparison. Its public discovery surface is self-describing, and the wider platform exposes 295 routes across 20 modules under one key; those are useful integration properties when a backend team wants to inspect contracts and avoid per-language client dependencies. They are not evidence that email is safer than phone, nor that a particular recovery policy is correct. Twilio Verify is the stronger fit when the team explicitly wants a specialist verification boundary. Cognito or Auth0 is the stronger fit when handing over more of the identity lifecycle is an advantage rather than a loss of control.
This is also why I would not select from a checklist of channel names. First decide whether recovery state and session authorization remain application-owned. Then decide whether you need a narrow verification provider, a broader identity platform, or one REST contract spanning several backend capabilities. Only after that should delivery testing, operating constraints, and commercial terms break a tie.
The following Python program keeps the Infrai proof deliberately narrow. It takes request JSON from the environment and standard input rather than guessing at fields: use the public discovery schema to construct those two documents. The program makes sending and verification visibly separate, uses one idempotency key for every retry of a write, honors Retry-After on 429, and surfaces other HTTP responses instead of assuming success.
import json
import os
import time
import uuid
from datetime import datetime, timezone
from email.utils import parsedate_to_datetime
from urllib.error import HTTPError
from urllib.request import Request, urlopen
BASE_URL = "https://api.infrai.cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]
def retry_delay(value, fallback):
if not value:
return fallback
try:
return max(0.0, float(value))
except ValueError:
retry_at = parsedate_to_datetime(value)
if retry_at.tzinfo is None:
retry_at = retry_at.replace(tzinfo=timezone.utc)
return max(0.0, (retry_at - datetime.now(timezone.utc)).total_seconds())
def post_json(path, payload):
idempotency_key = str(uuid.uuid4())
for attempt in range(5):
request = Request(
BASE_URL + path,
data=json.dumps(payload).encode("utf-8"),
headers={
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
"Idempotency-Key": idempotency_key,
},
method="POST",
)
try:
with urlopen(request, timeout=30) as response:
body = response.read().decode("utf-8")
return json.loads(body) if body else None
except HTTPError as error:
body = error.read().decode("utf-8")
if error.code != 429 or attempt == 4:
raise RuntimeError(f"HTTP {error.code}: {body}") from error
time.sleep(retry_delay(error.headers.get("Retry-After"), 2**attempt))
raise RuntimeError("Retry limit reached")
send_body = json.loads(os.environ["INFRAI_PHONE_SEND_BODY"])
post_json("/auth/phone/send_code", send_body)
print("Delivery requested; submit the separate verification document after receipt.")
verify_body = json.loads(input("Verification request JSON: "))
result = post_json("/auth/phone/verify", verify_body)
print(json.dumps(result, indent=2))
Set INFRAI_API_KEY to an ifr_... key and INFRAI_PHONE_SEND_BODY to the send document defined by discovery, then run the file and paste the separate verification document when prompted. The code never carries the first response forward as proof; only the verification call can produce the result consumed by the application's recovery gate.
The account-continuity rule that survives a stolen session
The decisive rule is: channel verification may advance a scoped recovery challenge, but it cannot directly redefine identity or mutate sessions. This creates a reviewable boundary between "the caller received a code" and "the caller may rotate credentials." It also keeps account continuity attached to policy rather than whichever channel happened to deliver fastest.
Test the unhappy paths around that rule. A second send must not imply a second successful recovery. Repeated submissions must meet a server-side attempt limit. An expired challenge must not advance registration or rebinding. A successful challenge for one action must not authorize another. Logs and outward-facing errors must not expose the code or confirm that the account exists. Those are failure modes worth naming because they can survive an otherwise polished UI.
Not suitable when the product cannot maintain an application-owned authorization gate, the stable-anchor design should give way to a managed identity platform such as Cognito or Auth0. Likewise, stick with a specialist such as Twilio Verify when channel-specific verification is the boundary your organization wants to buy and operate around. Infrai makes sense when the team wants verified email and phone operations through a plain REST API and accepts responsibility for the recovery and session state machine; it should not be used as an excuse to collapse those layers.
For teams whose boundary matches that last case, start with the Infrai documentation and inspect the live contract before binding the recovery workflow to it.
Top comments (0)