OTP & Number Verification

A one-time password (OTP) is a code valid for a single login or transaction. It is the second factor in two-factor authentication: something the user receives, proving control of a phone number or an authenticator, on top of a password they know.

OTPs are the highest-stakes messages most businesses send. A late or missing code is a failed login, an abandoned signup, or a lost sale, so OTP traffic is treated as a distinct class with tight latency budgets and short validity windows.

Number verification is the related task of proving a user actually controls a given phone number — the foundation of account security, fraud reduction, and clean contact data.

HOTP (RFC 4226) generates a code from a shared secret and a counter using HMAC. Each use increments the counter, so codes don't repeat. It underlies event-based tokens.

TOTP (RFC 6238) replaces the counter with the current time divided into fixed steps (commonly 30 seconds), so both sides derive the same code from the same secret and clock. This is what authenticator apps use, and it works offline because no message needs to be delivered.

For SMS-delivered OTPs, the code is usually a short random numeric value generated server-side, bound to the session or device, and expired after first use or a timeout. Six digits is the common default, balancing usability against guessing resistance.

SMS is the default OTP channel because of its universal reach, but it is not the only one. Voice OTP reads the code aloud and helps in markets with poor SMS deliverability or for accessibility. WhatsApp and RCS can deliver codes richly where the user is reachable there.

Flash-call verification is a cost-efficient alternative: the platform places a call that the app detects and auto-dismisses, verifying the number from the calling number's last digits without the user answering. It removes the SMS cost and the manual code entry entirely.

A channel waterfall combines these: try channel one, and if delivery isn't confirmed within a few seconds, escalate to the next. The waterfall must be time-boxed and must avoid sending the same code across two channels at once, which doubles cost and fraud exposure.

Well-designed OTP messages convert better. Keep the body minimal, branded, and consistent so it passes content filters, and support platform autofill conventions — such as the origin-bound one-time-code format on the last line — so the code is entered automatically.

Never place the code inside a clickable link that could be phished; keep it copy-or-type only. Localise the surrounding text while keeping the code and brand token stable so autofill and user recognition still work.

Measure end-to-end latency to the handset (submit to DLR), not just submit-accept time, and set a short validity period so a delayed code expires rather than arriving stale. Trigger fallback on a missing DLR within your latency budget, not only on an explicit failure.

Artificially inflated traffic (AIT), also called SMS pumping, is fraud where attackers trigger genuine-looking OTP sends to numbers they control, inflating your bill with no real user behind them. It is the single highest-ROI area to defend for most senders.

The core controls are rate limits — per phone number, per IP, per device fingerprint, per account — plus a cap on resends per session and added friction (a challenge or CAPTCHA) when velocity spikes from one source.

Watch conversion per destination: pumped traffic shows a flood of requests with near-zero code entry, and a sudden surge to an unusual country range is the classic signature. Validating numbers with an HLR / number-intelligence lookup before sending rejects invalid and high-risk numbers up front.