How SMS OTP Works: The Path of One Code, From App to Phone (2026)

The short answer
- An app's server makes a random code, stores a hashed copy with an expiry[3], and sends it as A2P SMS through aggregators and your carrier's message center to your phone.
- Codes are short-lived: NIST treats an out-of-band login as invalid after 10 minutes, and Twilio Verify's default token lifetime is also 10 minutes.[3][4]
- Autofill is safest when the SMS ends with a line binding the code to a domain, like @example.com #123456 (Apple, WebOTP); Android apps can use an app hash instead.[5][8][6]
- SMS pumping and revenue share fraud abuse OTP forms to farm fees; Juniper Research put 2023 enterprise losses to fake A2P traffic at $2.1 billion.[12]
- So apps filter numbers, and the app, not whoever supplies the number, decides who gets a code.[9][10]
How SMS OTP works, in one paragraph: when you type your phone number into an app, its server makes a random one-time code, saves a hashed copy with an expiry time (often 10 minutes at most[3][4]), and hands a text message to an SMS API. The message travels as A2P traffic through aggregators to your mobile carrier's message center, which delivers it to your phone. You type or autofill the code, the server checks that it matches, hasn't expired and hasn't been used, and you're in. Everything else is detail, and the detail is where codes get lost, delayed or abused.
TwoLine, which I built, sits at the last hop of this path: the handset. It sells one-time phone numbers that receive one SMS code for one app, so I've had good reason to learn the rest of the chain. Below I follow one code from creation to check using the official specs, then cover the abuse side: SMS pumping, revenue share fraud, and why apps filter numbers so hard.
What is SMS OTP?
A one-time password (OTP) is a code that works once, for a short time. SMS OTP is an OTP that a service sends to your phone number as a text message, so typing it back proves you can receive texts at that number right now. A2P messaging (application-to-person) is any text that software sends to a person, as opposed to texts between people, and verification codes are the classic example.
NIST, the US standards body, calls this out-of-band authentication over the public phone network. Its 2025 guidelines list it as the one "restricted" authenticator: allowed, but only with extra safeguards such as offering users an unrestricted alternative[15]. It's still the most common way apps check a phone number, because almost every phone can receive a text.
SMS OTP vs authenticator codes (HOTP and TOTP)
People mix these up because both produce short numeric codes. They're built very differently.
- HOTP (IETF RFC 4226, December 2005) makes a code from a shared secret key and a counter that goes up with each use. The spec says the HOTP value must be at least a 6-digit value[1].
- TOTP (IETF RFC 6238, May 2011) swaps the counter for the clock. It recommends a default time step of 30 seconds, which is why the code in your authenticator app keeps changing[2].
- SMS OTP usually isn't either. The server picks a fresh random code for each login and sends it to you. NIST requires random codes of at least six decimal digits[14], made by an approved random generator and accepted only once[16].
- Email OTP works the same way over email: it avoids carrier filters and SIM swaps, but it's only as safe as your inbox.
The practical difference is where the secret lives. With TOTP, the secret is shared once (usually as a QR code) and your phone computes codes offline. With SMS OTP, a new code crosses several companies' networks every time, and anyone who can receive your texts, say after a SIM swap, gets the code too. I've collected the SIM swap statistics separately.
How SMS OTP works step by step
The path of one code, in the order things happen:
- You enter a phone number. The app converts it to international format and decides whether to send anything at all. Many apps check the number's type and carrier, count recent requests from that number, IP address and prefix, and refuse countries they don't serve. It's the first filter, and it's entirely the app's call.
- The server creates a code. It draws digits from a secure random generator, never from the time or the phone number, and stores a hash of the code plus the number, an expiry time and an attempt counter. Lots of apps hand this job to a verification API instead; Twilio Verify keeps tokens valid for a default of 10 minutes[4].
- The SMS API takes the message. The app sends an HTTPS request with the number and the text. From here on it's A2P traffic, and the provider picks a route to the destination country.
- Aggregators pass it along. An aggregator is a wholesale middleman with connections into many carriers. A message can cross several of them, and the network that finally delivers it charges a fee. Keep that fee in mind; it's what fraudsters go after.
- The carrier's SMSC stores and forwards it. The Short Message Service Center (SMSC) is the carrier system that holds a text, finds your phone on the network and delivers it. If your phone's off, it keeps retrying for a while. Carrier firewalls may block A2P traffic that looks like spam or fraud.
- A delivery receipt comes back. The receiving network reports a status, such as delivered or undelivered, back up the chain. Receipts can be late or missing, and "delivered" means the handset got it, not that you saw it.
- Your phone shows the code, and maybe fills it in. More on autofill below.
- The server checks it. This is SMS OTP verification proper: the server compares your entry with the stored hash, confirms the code hasn't expired or been used, and counts failed attempts so nobody can guess every combination. NIST requires that a code be accepted only once during its validity period[16].
Most "code not received" complaints start in step 1 or in steps 3 to 5. The app might never send to your number, or the message might die at a carrier firewall, and neither shows up as an error. I go through the fixes in verification code not received.
Stage, who handles it, what can go wrong
| Stage | Who handles it | What can go wrong |
|---|---|---|
| Number entry and checks | The app, sometimes with a number-lookup service | Number type refused, country not served, too many requests from that number or prefix |
| Code creation and storage | App server or a verification API | Weak randomness, codes stored in plain text, expiry set too long |
| Hand-off to the SMS API | The app's SMS provider (a CPaaS, or communications platform) | Destination country switched off in the account, API errors, cost spikes from pumping |
| Routing | Aggregators and carrier interconnects | Delays, cheap "grey" routes that drop messages, spam filtering |
| Delivery to the handset | The recipient carrier's SMSC | Phone off or out of coverage, sender blocked by a carrier firewall, SIM swapped to an attacker |
| Delivery receipt | Carriers, reporting back up the chain | Late or missing receipts, a "delivered" status with nothing on screen |
| Reading the code | The phone's operating system, then the user | Autofill skips a badly formatted message, the user types the code into a phishing site |
| Verification | App server or verification API | Code expired, too many wrong tries, a resend replaced the old code |
Retries and rate limits
Every "resend code" tap is another paid message, so apps throttle it. You'll usually see a countdown before you can resend, a cap on requests per number, and a lockout after several wrong entries. Some providers send the same code again on a resend: Twilio says the token stays the same during its validity period until the verification succeeds[4]. Others issue a new code and cancel the old one. If two codes arrive and the app doesn't say which counts, try the newest one first.
OTP expiry time: how long does a code last?
Not long, and that's on purpose. The longer a code lives, the longer a stolen or phished one stays useful. The official documents say:
- NIST SP 800-63B-4 (2025): an out-of-band authentication is invalid unless it's completed within 10 minutes[3].
- Twilio Verify: tokens are valid for a default of 10 minutes once generated[4].
- TOTP in authenticator apps: a new code every 30 seconds by default[2].
- Android SMS User Consent: once an app starts listening, Play services watches for a code-bearing SMS for the next five minutes[7]. That's how long the phone waits, not how long the code lives.
Chart data
| Rule | Minutes |
|---|---|
| TOTP time step (RFC 6238) | 0.5 min |
| Android consent listener | 5 min |
| NIST out-of-band limit | 10 min |
| Twilio Verify default | 10 min |
So when an app says your code expires in 10 minutes, it's sitting right at the NIST ceiling, and apps can set shorter windows. What should you take from this? Request the code when you're ready to type it.
One more clock matters if you use a temporary number: the number's own window. On TwoLine a number lasts long enough for one code, usually 10 to 20 minutes and sometimes shorter, and the order page shows the end time. Ask the app for the code early in that window, not near the end.
SMS OTP autofill on iPhone, Android and the web
Autofill saves typing, and it can block phishing. The modern schemes share one trick: they tie the code to the app or site that asked for it.
Apple: security code AutoFill and domain-bound codes
On iPhone, a code from Messages is offered above the keyboard in fields the developer has marked as one-time-code fields: textContentType set to oneTimeCode in apps, or autocomplete="one-time-code" on websites. Apple adds domain-bound codes on top. In iOS 14 or later and macOS Big Sur or later, a service can bind its code to its DNS domain by ending the SMS with a line like @example.com #123456. AutoFill then offers the code only when the website open in Safari, or an associated domain of the app, matches that domain, which makes it harder to trick someone into typing the code into a phishing site[5].
Android: SMS Retriever and SMS User Consent
Google offers two APIs. With the SMS Retriever API, the server puts an 11-character hash string that identifies the app into the message, and the matching message goes straight to that app with no typing[6]. With the SMS User Consent API, the app starts listening, and for the next five minutes a message containing a one-time code triggers a prompt asking the user to let the app read that one message[7]. The first is invisible to the user; the second asks every time.
The web: the WebOTP API
The WebOTP API lets a website ask the browser for the code in an incoming SMS, so the user taps once instead of switching apps. It reads the same last-line format, for example @www.example.com #123456, works only over HTTPS, and is still marked experimental with limited browser support[8].
If you build an app: end your OTP message with your domain and the code on their own last line, like
@yourdomain.com #123456. It costs nothing, it lets iPhones and WebOTP browsers match the code to your domain, and it adds a phishing check for free.
SMS OTP fraud: SMS pumping and revenue share fraud
Now the uncomfortable part. Because each delivered text earns somebody a fee, a form that sends texts on demand is worth money to anyone who can make it send more.
SMS pumping, also called SMS toll fraud, is an attack in which bad actors request a high volume of text messages from unprotected endpoints such as OTP and sign-up forms[9]. Bots submit numbers at scale, and the business pays for every message. Artificially inflated traffic (AIT) is the industry's umbrella term for non-genuine A2P SMS traffic generated to raise volumes and costs[12]. International revenue share fraud (IRSF) is the older telecom version. Microsoft describes criminals registering premium-rate numbers, using scripts to request texts or calls to them, sharing the profit with telecom providers, and rotating across region codes to avoid detection[10].
Microsoft's documentation says the most common IRSF attack vector is end-user MFA that relies on text or voice calls[10]. Put plainly, the login code you're waiting for is exactly what these schemes exploit.
How big is it?
Estimates vary because nobody sees all the traffic. Juniper Research found that enterprise losses to AIT peaked at $2.1 billion in 2023, and it expects them to fall as A2P SMS traffic moves to other channels[12]. A report by Enea and Mobilesquared put the cost of fraudulent messages to brands at $1.16 billion[13], though the release doesn't say which year that covers. One large provider, Twilio, says its Fraud Guard feature saved customers $62.7 million in fraudulent costs between June 2022 and October 2024[9].
Chart data
| Estimate | US$ billions |
|---|---|
| Juniper Research (2023) | $2.10B |
| Enea and Mobilesquared | $1.16B |
The best-known single case is Twitter. In February 2023, as it limited SMS two-factor login to paying subscribers, Elon Musk replied "Yup" to a post saying the company was losing $60 million a year on scam SMS[11]. It's a claim, not an audited figure, but it's the kind of loss that makes companies rethink SMS altogether.
SMS OTP in numbers
The figures from this guide in one place, with what each one actually measures.
| Figure | What it measures | Source |
|---|---|---|
| 6 digits[1] | Minimum HOTP code length | IETF RFC 4226, 2005 |
| 30 seconds[2] | Default TOTP time step | IETF RFC 6238, 2011 |
| 10 minutes[3] | Longest an out-of-band login may take before it's invalid | NIST SP 800-63B-4, 2025 |
| 10 minutes[4] | Default Twilio Verify token lifetime | Twilio docs |
| 5 minutes[7] | Android SMS User Consent listening window | Google for Developers |
| 6 decimal digits[14] | NIST minimum length for a random out-of-band code | NIST SP 800-63B-4, 2025 |
| 11 characters[6] | App hash inside an SMS Retriever message | Google for Developers |
| $2.1 billion[12] | Peak enterprise losses to AIT, 2023 | Juniper Research, 2024 |
| $1.16 billion[13] | Cost of fraudulent messages to brands (year not stated) | Enea and Mobilesquared, 2024 |
| $62.7 million[9] | Fraud costs Twilio says Fraud Guard saved customers, June 2022 to October 2024 | Twilio, 2026 |
| $60 million a year[11] | Twitter's claimed loss to scam SMS (unaudited) | NBC News (Reuters), 2023 |
Why apps filter phone numbers
Put yourself in the app's seat. Every code costs money, some share of requests is fake, and the fake ones cluster around certain countries, prefixes and number types. So apps do what the fraud guides tell them to do:
- Switch off countries they don't serve. Twilio's advice includes disabling geo permissions for countries where you don't do business and rate-limiting messages to the same number range or prefix[9].
- Slow down repeats. A delay between OTP requests from the same number or IP limits how fast bots can cycle through attempts[9].
- Make risky regions opt-in. Microsoft Entra needs a support request before SMS and voice verification work in a long list of region codes, throttles phone-based sign-in for new tenants in their first few days, and watches for abuse of free or metered number services[10].
- Check the number type. Many apps look up whether a number is mobile, landline or VoIP before sending, and some refuse virtual or VoIP numbers outright. They rarely publish their rules, and they change them without notice.
The side effect is collateral damage: real people in blocked regions, travelers, and anyone on a number type the app distrusts can end up with no code and no error. Twilio itself warns that blunt rules like rate limits, geo-restriction and prefix bans can catch real customers[9]. If you're choosing a number to verify with, my OTP verification number risk checklist goes through what apps tend to check, and you can test your own line with how to check if a number is VoIP.
Alternatives to SMS OTP
Whether SMS codes are safe enough has its own post, is SMS 2FA safe?, where I rank every factor. The short version: NIST keeps SMS on its restricted list[15] and tells verifiers to consider risk signals such as a device swap, SIM change or number porting before sending a code over the phone network[17]. Domain-bound codes help against phishing, but only where autofill is doing the work.
Passkeys and authenticator apps send nothing over the phone network. Twilio Verify, for one, also offers codes by WhatsApp, voice call and email, plus push notifications[9]. Microsoft's advice to its own admins works for everyone: set up more than one sign-in method, with at least one that doesn't depend on the phone network[10]. Still, SMS isn't going away. Almost everyone has a number and it needs no app install, which is why it's still the default.
Where a one-time number fits in this path
Look back at the chain: app, code, SMS API, aggregators, carrier, handset. A one-time number sits at the last step; it's just another handset at the end of the path. The app makes the code, pays for the message and decides whether to send it at all, exactly as it would for your own SIM. So nobody selling numbers can promise you a code. The app decides. Numbers sold for verification are one of the types some of these filters are built to catch, so expect some apps to say no.
TwoLine works on one number per code. Any code the app sends appears on your private order page. Lines carry labels such as "Premium · Non-VoIP", "Standard+" and "Virtual", but the app being verified still decides whether it accepts the number. As of November 2, 2026, when I checked the catalog, it listed 443 apps across about 190 countries, the cheapest line anywhere was $0.39, and US Telegram numbers started at $0.93. Prices are live and change, so check pricing for today's. The one-code SMS verification service page compares this model with rentals from other providers.
If no code arrives by the end of the window, the full price returns to your TwoLine balance, not your card; the refund page has the details. The limits:
- One code, then the number ends. It's not for accounts you'll need to recover; see how long before a phone number is reused.
- Apps may refuse any number, ours included, and their rules change.
- No numbers for banks, payment apps, money transfer, crypto exchanges, securities accounts or government identity services.
- No published success rate. TwoLine doesn't publish a delivery or success rate.
Comparing services? The SMS verification service buyer guide lists what to check before you pay, and one-time phone numbers for verification covers when a single-use number makes sense.
Signing up somewhere you'd rather not give your number?
Search the app, pick a country and see the live price before you sign up. The app still decides whether to send a code, and if no code arrives in the window, the full price goes back to your TwoLine balance.
Check live pricesFAQ
What is SMS OTP verification?
SMS OTP verification is when a service texts a one-time code to your phone number and asks you to type it back, which proves you can receive texts at that number right now. The code is random, works once and expires quickly; NIST treats an out-of-band login as invalid if it isn't completed within 10 minutes.[3]
How long is an SMS OTP valid?
Often 10 minutes or less. NIST's ceiling for out-of-band codes is 10 minutes, and Twilio Verify's default token lifetime is also 10 minutes.[3][4] Apps can pick shorter windows, so ask for the code when you're ready to type it.
How does SMS OTP autofill work?
On iPhone, AutoFill offers codes in fields marked as one-time-code fields, and domain-bound messages ending with a line like @example.com #123456 are offered only on the matching site or app.[5] On Android, apps use the SMS Retriever API, which needs an 11-character app hash in the message, or the SMS User Consent API, which asks you to allow reading one message.[6][7]
What is SMS pumping?
SMS pumping, also called SMS toll fraud, is an attack where bots request large volumes of texts from an app's OTP or sign-up forms, and the business pays for every message.[9] Juniper Research put enterprise losses to this kind of artificially inflated traffic at $2.1 billion in 2023.[12]
Why did I get the same SMS code twice?
Some verification providers resend the same code while it's still valid: Twilio says a token stays the same during its validity period until the verification succeeds.[4] Others issue a new code and cancel the old one, so if two different codes arrive and the app doesn't say which counts, try the newest one first.
Can a one-time number receive an SMS OTP?
It can, if the app sends one. A one-time number is just another phone at the end of the delivery path, but the app decides whether it will send a code to it, and some apps refuse certain number types. TwoLine numbers receive one code for one app and then end, so they're not for accounts you'll need to recover later. If no code arrives in the window, the full price returns to your TwoLine balance.
About this article
Written by Serhat Doğan, founder of TwoLine. He's a London-based software developer who has built SMS verification tools full-time since early 2026. Disclosure: I built TwoLine, which sells one-time numbers for a single SMS code, so I have a stake in this topic. Every outside number in this guide links to its source below. TwoLine doesn't publish delivery measurements of its own, and no app promises to accept any number, ours included.
Find me on GitHub, LinkedIn and X. Read the refund policy, privacy policy and terms, or contact support.
Sources
- Internet Engineering Task Force (IETF), “RFC 4226: HOTP: An HMAC-Based One-Time Password Algorithm”, 2005-12. datatracker.ietf.org/doc/html/rfc4226 (accessed 2026-11-02)
- Internet Engineering Task Force (IETF), “RFC 6238: TOTP: Time-Based One-Time Password Algorithm”, 2011-05. datatracker.ietf.org/doc/html/rfc6238 (accessed 2026-11-02)
- National Institute of Standards and Technology (NIST), “SP 800-63B-4: Digital Identity Guidelines, Authentication and Authenticator Management”, 2025-07. pages.nist.gov/800-63-4/sp800-63b.html (accessed 2026-11-02)
- Twilio, “Verify: Rate Limits and Timeouts”. www.twilio.com/docs/verify/api/rate-limits-and-timeouts (accessed 2026-11-02)
- Apple Developer Documentation, “Enabling AutoFill for domain-bound SMS codes”. developer.apple.com/documentation/security/enabling-autofill-for-domain-bound-sms-codes.md (accessed 2026-11-02)
- Google for Developers, “Perform SMS Verification on a Server (SMS Retriever API)”. developers.google.com/identity/sms-retriever/verify?hl=en (accessed 2026-11-02)
- Google for Developers, “Request one-time consent to read an SMS verification code”, 2024-10-31. developers.google.com/identity/sms-retriever/user-consent/request?hl=en (accessed 2026-11-02)
- MDN Web Docs (Mozilla), “WebOTP API”, 2025-10-30. developer.mozilla.org/en-US/docs/Web/API/WebOTP_API (accessed 2026-11-02)
- Twilio, “What Is SMS Pumping Fraud and How to Stop It”, 2026-09-10. www.twilio.com/en-us/blog/sms-pumping-fraud-solutions (accessed 2026-11-02)
- Microsoft Learn, “Telephony Fraud Protections and Throttles - Microsoft Entra ID”, 2025-07-28. learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-regional-opt-in (accessed 2026-11-02)
- NBC News (Reuters), “Twitter to limit use of text messages for two-factor authentication to paid subscribers”, 2023-02-18. www.nbcnews.com/tech/tech-news/twitter-limit-use-text-messages-two-factor-authentication-paid-subscri-rcna71305 (accessed 2026-11-02)
- Juniper Research, “Global Enterprise Losses to Artificially Inflated Traffic (AIT) to Halve Over Next Five Years”, 2024-10-22. www.juniperresearch.com/press/enterprise-losses-to-ait-to-halve-over-next-five-years (accessed 2026-11-02)
- Enea, “A2P Messaging Under Threat: Joint Report by Enea and Mobilesquared Reveals 20 Billion Fraudulent Messages Sent in 2023”, 2024-02-14. www.enea.com/news/press-releases/a2p-messaging-under-threat-joint-report-by-enea-and-mobilesquared-reveals-20-billion-fraudulent-messages-sent-in-2023 (accessed 2026-11-02)
- National Institute of Standards and Technology (NIST), “SP 800-63B-4: Digital Identity Guidelines, Out-of-Band Verifiers”, 2025-07. pages.nist.gov/800-63-4/sp800-63b.html (accessed 2026-11-02)
- National Institute of Standards and Technology (NIST), “SP 800-63B-4: Digital Identity Guidelines, Restricted Authenticators”, 2025-07. pages.nist.gov/800-63-4/sp800-63b.html (accessed 2026-11-02)
- National Institute of Standards and Technology (NIST), “SP 800-63B-4: Digital Identity Guidelines, Out-of-Band Verifiers (replay resistance)”, 2025-07. pages.nist.gov/800-63-4/sp800-63b.html (accessed 2026-11-02)
- National Institute of Standards and Technology (NIST), “SP 800-63B-4: Digital Identity Guidelines, Authentication Using the PSTN”, 2025-07. pages.nist.gov/800-63-4/sp800-63b.html (accessed 2026-11-02)