DEV Community: Temp SMS

SMS Pumping Fraud Prevention: A Practical Guide for Developers

Temp SMS — Thu, 05 Nov 2026 17:03:34 +0000

SMS pumping fraud prevention comes down to one rule: never let an anonymous request trigger an SMS without limits. Attackers abuse open "send code" endpoints to fire large numbers of messages at phone number ranges that earn them a share of the fees, and you pay the bill. The defence is layered: restrict the countries you send to, rate-limit by phone number, number range, IP and session, put a bot check in front of the send action, and watch your verification conversion rate. Below is how each layer works, plus a small rate limiter you can adapt.

What SMS pumping is

SMS pumping, also called SMS toll fraud or artificially inflated traffic (AIT), targets any feature that sends a text on request: sign-up codes, login OTPs, password resets, "text me a download link" widgets. The pattern:

The attacker finds an endpoint that texts any number submitted to it.
A script submits numbers in ranges where a complicit party in the delivery chain earns money per message, often in expensive destinations.
The fees are shared; nobody ever enters a code.

Each message is cheap on its own, so the damage tends to show up on an invoice rather than as an outage.

Signs you're being pumped

Sudden volume spikes to countries where you have few real users
Many numbers with the same prefix, differing only in the last few digits
A sharp drop in verification completion for one country or prefix
Requests with no prior page views, identical user agents or rotating IPs

Layer 1: geo permissions

The cheapest control is an allowlist. If you serve a handful of countries, refuse everything else before calling your SMS provider, and disable unused destinations in the provider's console too.

Be careful with +1. It isn't only the US and Canada: the North American Numbering Plan includes many Caribbean countries, so a prefix check would let them all through. Check the region instead:

import phonenumbers

ALLOWED_REGIONS = {"US", "CA", "GB", "NL", "SE"}

def region_allowed(e164: str) -> bool:
    number = phonenumbers.parse(e164, None)
    return phonenumbers.region_code_for_number(number) in ALLOWED_REGIONS

Layer 2: rate limits on several keys

A per-IP limit alone is easy to dodge with proxies. Limit several dimensions at once:

Key	What it stops	Starting point
Phone number	Repeated sends to one number	a few per hour
Number range	Sequential-number attacks	tens per hour
IP address	Single-source scripts	around 10 per hour
Session	Sends without a real browsing session	a few per session
Global	Worst-case spend	above your normal peak

Tune them to your traffic. Here's a fixed-window limiter in Python with Redis that checks every key in one round trip:

import time
import redis

r = redis.Redis(decode_responses=True)

# (scope, max sends, window in seconds)
RULES = [
    ("phone", 3, 3600),
    ("range", 20, 3600),
    ("ip", 10, 3600),
    ("global", 2000, 3600),
]

def sms_allowed(phone: str, ip: str) -> bool:
    subjects = {
        "phone": phone,
        "range": phone[:-3],  # same number minus its last 3 digits
        "ip": ip,
        "global": "all",
    }
    now = int(time.time())
    pipe = r.pipeline()
    for scope, _, window in RULES:
        key = f"otp:{scope}:{subjects[scope]}:{now // window}"
        pipe.incr(key)
        pipe.expire(key, window)
    counts = pipe.execute()[0::2]  # keep INCR results, skip EXPIRE results
    return all(count <= limit for count, (_, limit, _) in zip(counts, RULES))

A few notes:

Every attempt counts, including refused ones, so a script hammering one number stays blocked.
Fixed windows allow bursts at boundaries; a sliding window or token bucket is smoother.
Log which rule fired so you can tune the limits later.

Layer 3: a bot check before the send

Put a CAPTCHA or invisible bot challenge in front of the "send code" action, not after it. You can show it only when risk signals appear: a new IP, an unusual country, several recent sends.

Make the SMS the last step of the form. Validate everything else first and require a token issued when the page loads, so a script can't simply POST to your send endpoint.

Layer 4: monitor conversion, not just volume

The clearest signal is the ratio of verified codes to sent codes. Genuine users enter most codes they request; pumped traffic enters almost none. Track it per country every hour (PostgreSQL):

SELECT country,
       COUNT(*) AS sent,
       COUNT(*) FILTER (WHERE verified_at IS NOT NULL) AS verified,
       ROUND(100.0 * COUNT(*) FILTER (WHERE verified_at IS NOT NULL) / COUNT(*), 1) AS pct
FROM otp_requests
WHERE created_at > now() - interval '1 hour'
GROUP BY country
ORDER BY sent DESC;

Alert when a country falls well below its usual rate, and keep a kill switch that stops sending to one country without a deploy. Many SMS providers also offer built-in fraud protection; treat it as one layer, not the whole defence.

SMS pumping fraud prevention without blocking real users

After tightening limits, confirm that real people still get their codes. Send to genuine numbers in every country you allow; the free public numbers on Temp SMS are handy for quick manual checks of delivery and message text. If several testers use the same shared number, your per-number limit may kick in. That's the limiter working, not a bug.

FAQ

Is SMS pumping the same as SMS spam?
No. Spam targets the recipient. Pumping targets the sender's wallet by generating paid traffic nobody reads.

Does a CAPTCHA alone stop SMS pumping?
It raises the attacker's cost, but solving services exist. Combine it with geo rules, rate limits and monitoring.

Which endpoints are at risk?
Any that send an SMS on request: sign-up, login, password reset, phone number change and "send me a link" forms.

More in this series on SMS verification:

SMS Verification UX Best Practices: 10 Tips for Better OTP Screens

Temp SMS — Thu, 05 Nov 2026 17:01:36 +0000

Most people who drop out of a phone sign-up don't mean to. They mistype the number, wait for a code that went somewhere else, or fight a six-box input that won't accept paste. SMS verification UX best practices come down to three things: collect the number cleanly, get the code into the field with as little typing as possible, and say clearly what to do when something goes wrong. Here are ten tips, with code.

1. Use the right input for the phone number

Phone numbers aren't numbers in the maths sense. Use type="tel" so mobile keyboards show a dial pad, and let the browser offer the user's saved number.

<label for="phone">Mobile number</label>
<input id="phone" name="phone" type="tel"
       autocomplete="tel" inputmode="tel">

Pair it with a country selector that defaults to the user's likely country, and normalise to E.164 on the server instead of forcing a format in the field.

2. Accept whatever people type

Spaces, dashes, brackets, a leading 00 or a national 0: people paste numbers from contacts and email signatures. Strip formatting characters before validating, and only show an error for numbers that are actually impossible, never for punctuation.

3. Show where the code went, and make it easy to fix

After sending, echo the number back: "We sent a code to +1 416 555 0199. Wrong number?" The link should return to the previous step with the number pre-filled. Many "code never arrived" tickets are really typos the user never noticed.

4. Let the OS fill in the code

The autocomplete="one-time-code" attribute does more for completion than any custom widget. Safari on iOS and macOS suggests the code from an incoming SMS, and many Android keyboards offer it as a suggestion too.

<label for="otp">6-digit code</label>
<input id="otp" name="otp" type="text"
       autocomplete="one-time-code"
       inputmode="numeric" pattern="[0-9]*"
       maxlength="6" required>

Use type="text" with inputmode="numeric", not type="number": number inputs can drop leading zeros, show spinner arrows and accept values like 1e5.

5. Bind the code to your domain

Ending the SMS with an origin-bound line tells browsers which site the code belongs to, so it's only offered there, which also makes phishing pages less effective:

Your Example code is 482913. It expires in 10 minutes.

@example.com #482913

In Chromium browsers on Android you can go further with the WebOTP API and fill the field after the user consents:

if ('OTPCredential' in window) {
  const input = document.querySelector('#otp');
  const ac = new AbortController();
  input.form.addEventListener('submit', () => ac.abort());

  navigator.credentials
    .get({ otp: { transport: ['sms'] }, signal: ac.signal })
    .then((otp) => {
      input.value = otp.code;
      input.form.requestSubmit();
    })
    .catch(() => { /* dismissed or timed out: manual entry still works */ });
}

Treat this as progressive enhancement. The plain input must always work on its own.

6. One field beats six boxes

Split digit boxes look neat but break paste, autofill and screen readers unless you handle every edge case. A single input with wide letter spacing gives a similar look:

#otp { font-size: 1.5rem; letter-spacing: 0.5em; font-variant-numeric: tabular-nums; }

If you must use boxes, support pasting the full code into the first one and moving back on Backspace.

7. Add a resend cooldown with a visible countdown

Users press "Resend" after five seconds if nothing tells them to wait. Disable it briefly, show the remaining time, and lengthen the delay after each resend, which also limits abuse.

function startCooldown(button, seconds) {
  const label = button.textContent;
  button.disabled = true;
  const tick = () => {
    if (seconds <= 0) {
      button.disabled = false;
      button.textContent = label;
      return;
    }
    button.textContent = `Resend in ${seconds--}s`;
    setTimeout(tick, 1000);
  };
  tick();
}

8. Write error messages that say what to do next

"Invalid OTP" tells the user nothing. Compare:

Wrong code: "That code doesn't match. Use the latest message; older codes stop working when you request a new one."
Expired: "This code has expired. We can send you a new one."
Too many attempts: "Too many tries. You can request a new code in 10 minutes."

Keep the typed value in the field after an error so people can spot a swapped digit.

9. Make it accessible

Use a visible <label>; a placeholder vanishes as soon as someone types.
Announce "Code sent", the end of the countdown and errors through a polite live region, e.g. <p id="otp-status" aria-live="polite"></p>, and connect errors to the field with aria-describedby.
Don't expire codes so fast that slower users can't finish. State how long the code is valid and make a fresh one easy to get (WCAG's "Timing Adjustable" criterion covers this).

10. Test real delivery, not just staging

Mocks and provider test numbers prove you call the API correctly, not that a real handset receives a readable message. Before launch, send to real numbers in each country you support and check timing, sender name and rendering. For quick manual checks, the free public numbers on Temp SMS show incoming texts on a web page with no account. Use them only for disposable test accounts, because anyone can read those messages.

SMS verification UX best practices in short

A clean number input, one autofill-friendly code field, the number echoed back, a visible cooldown, specific errors and real-device tests per country.

FAQ

What does autocomplete="one-time-code" do?
It tells the browser and OS that the field expects a one-time code, so they can suggest the code from a recent SMS instead of making the user switch apps.

How long should an SMS code stay valid?
A few minutes up to around ten is common. Show the expiry in the message and on screen.

Should the OTP field be type="number"?
No. Use type="text" with inputmode="numeric" to get a numeric keyboard without losing leading zeros.

More in this series on SMS verification:

E.164 Phone Number Format: A Developer Cheat Sheet

Temp SMS — Thu, 05 Nov 2026 16:56:39 +0000

The E.164 phone number format is the standard way to write any phone number as one unambiguous string: a plus sign, the country code, then the national number with no spaces, punctuation or leading trunk zero, for example +442079460958. It has at most 15 digits (the + doesn't count). If you store, compare or text phone numbers, E.164 is the format your database and your SMS API should agree on. This cheat sheet covers the rules, country examples, normalisation code in Python and JavaScript, and the mistakes behind most phone number bugs.

The rules in one minute

E.164 is an ITU-T recommendation (official text). In practice a valid E.164 string:

starts with +
continues with a country code of 1 to 3 digits, which never starts with 0
ends with the national significant number: area or mobile code plus subscriber number, without the national trunk prefix (usually 0)
contains only digits after the +
is 15 digits long at most

A quick structural check:

^\+[1-9]\d{1,14}$

This only checks shape. +19999999999 passes but isn't a real number, which is why you also want a library that knows each country's numbering plan.

E.164 phone number format examples by country

Country	Code	Written locally	E.164
United States	+1	(202) 555-0143	+12025550143
Canada	+1	(416) 555-0199	+14165550199
United Kingdom	+44	020 7946 0958	+442079460958
Netherlands	+31	06 12345678	+31612345678
Finland	+358	040 123 4567	+358401234567
Sweden	+46	070-123 45 67	+46701234567
Belgium	+32	0470 12 34 56	+32470123456

The examples are for illustration only. Notice the pattern: where the national format starts with 0, that zero disappears in E.164. The US and Canada share +1, so the country code alone can't tell you which one a number belongs to; the area code can.

Normalising in Python with phonenumbers

phonenumbers is a Python port of libphonenumber (pip install phonenumbers).

from typing import Optional

import phonenumbers
from phonenumbers import NumberParseException, PhoneNumberFormat

def to_e164(raw: str, default_region: Optional[str] = None) -> Optional[str]:
    """Return an E.164 string, or None if the input isn't a valid number."""
    try:
        number = phonenumbers.parse(raw, default_region)
    except NumberParseException:
        return None
    if not phonenumbers.is_valid_number(number):
        return None
    return phonenumbers.format_number(number, PhoneNumberFormat.E164)

default_region is a two-letter region code such as "GB" or "NL", used when the input has no +. Parsing a national number with the right region removes the trunk zero for you:

>>> n = phonenumbers.parse("020 7946 0958", "GB")
>>> phonenumbers.format_number(n, PhoneNumberFormat.E164)
'+442079460958'
>>> n = phonenumbers.parse("06 12345678", "NL")
>>> phonenumbers.format_number(n, PhoneNumberFormat.E164)
'+31612345678'

For +1 numbers, phonenumbers.region_code_for_number(number) tells you whether a valid number belongs to the US, Canada or another country in the North American Numbering Plan.

Normalising in JavaScript with libphonenumber-js

import { parsePhoneNumberFromString } from 'libphonenumber-js';

export function toE164(raw, defaultCountry) {
  const phone = parsePhoneNumberFromString(raw, defaultCountry);
  if (!phone || !phone.isValid()) return null;
  return phone.number; // already E.164
}

toE164('0470 12 34 56', 'BE'); // '+32470123456'

phone.country gives you the two-letter country, which is handy for telling US and Canadian numbers apart.

Common pitfalls

Keeping the trunk zero. +4407700900123 is wrong; +447700900123 is right. Italy is the classic exception: its landline numbers keep their leading 0 after +39. That's one more reason to use a library instead of replace(/^0/, '').
The UK "(0)". Websites often show +44 (0)20 7946 0958. Stripping non-digits gives +4402079460958, which is wrong. Parsing libraries handle it; naive regexes don't.
International dialling prefixes. 0044 (dialled from much of Europe) and 011 44 (dialled from North America) are dialling instructions, not part of the number. Convert them to +44.
Storing numbers as integers. You lose the + and invite overflow and formatting bugs. Store a string; VARCHAR(16) holds any E.164 value.
Invisible characters. Pasted numbers can contain non-breaking spaces or direction marks. Normalise before comparing or looking up users, or the same person can register twice.
Extensions. ext. 204 isn't part of E.164. Keep it in a separate field.
Stale metadata. Numbering plans change. Update your phone library regularly or new number ranges will start failing validation.

Checking the result on a real network

Unit tests catch parsing bugs, but it's worth confirming that a number normalised from user input actually receives an SMS. Free public test numbers from Temp SMS show incoming texts on a web page. For example, a UK number for receiving test SMS online lets you check that a +44 mobile round-trips through your form, your database and your SMS provider. Keep it to throwaway test accounts, since anyone can read those messages.

FAQ

How many digits can an E.164 number have?
Up to 15, counting the country code but not the plus sign.

Should I store the plus sign?
Yes. +447700900123 is unambiguous and matches what most SMS APIs expect.

Is E.164 the same as "international format"?
Close, but not identical. International display format adds spaces (+44 20 7946 0958); E.164 has none.

Do US and Canadian numbers both start with +1?
Yes, along with other countries in the North American Numbering Plan. Use the area code or a library's region lookup to tell them apart.

More in this series on SMS verification:

How to Test SMS OTP Verification Without a Real Phone Number

Temp SMS — Thu, 05 Nov 2026 16:22:12 +0000

If your app sends one-time passwords by SMS, sooner or later you need to test the whole flow: the user types a phone number, your backend sends a code, the user enters it. Using your own phone for every test run is slow, burns through your SMS budget, and puts your personal number into test databases. Here are four practical ways to test SMS OTP verification without a real phone, from fully mocked to fully real.

1. Mock the SMS provider in unit tests

The fastest option: don't send anything. Wrap your SMS provider behind an interface and swap in a fake during tests.

import re

class SmsSender:
    def send(self, to: str, body: str) -> None: ...

class FakeSmsSender(SmsSender):
    def __init__(self):
        self.outbox = []

    def send(self, to, body):
        self.outbox.append((to, body))

def test_signup_sends_code():
    sms = FakeSmsSender()
    signup(phone="+15550100", sms=sms)
    to, body = sms.outbox[-1]
    assert to == "+15550100"
    assert re.search(r"\b\d{6}\b", body)

Good for: unit tests and CI. Misses: formatting problems, carrier filtering, delivery delays.

2. Use your provider's test mode

Most providers have a sandbox. Firebase Authentication lets you register fictional test phone numbers with a fixed code in the console (Authentication → Sign-in method → Phone → Phone numbers for testing); no SMS is sent and no quota is used. Twilio offers test credentials and "magic" numbers that simulate success and error responses for API calls without delivering real messages.

Good for: integration tests against the real SDK. Misses: what actually happens on a real network.

3. Use a temporary public number for end-to-end checks

Before a launch, or when a user reports "I never got the code", you want a real SMS on a real network. A free temporary number service such as Temp SMS shows incoming messages for public numbers in several countries on a web page, with no account required.

A typical manual check:

Pick a number from the country you are testing, e.g. a US temporary number or a Canada receive SMS number.
Enter it in your staging sign-up form.
Open the number's page and confirm the message arrives, how long it took, and that the text renders correctly (sender ID, encoding, link previews).

This catches problems mocks never will: country-specific sender ID rules, Unicode characters turning into ?, messages over 160 characters splitting, or a carrier silently filtering your template.

Important: the messages on these numbers are public. Only use them for test accounts, never for real user data, admin accounts or anything protected by 2FA.

4. Use a dedicated private virtual number

For automated end-to-end tests that need real SMS, rent a private virtual number from your SMS provider and read incoming messages through its webhook or API. It costs a little each month, but messages are private and your test can assert on them programmatically.

Which approach when?

Goal	Best option
Fast feedback in CI	Mock the sender
Test the real SDK without cost	Provider test mode / test numbers
Check real delivery in a country before launch	Temporary public number
Automated real-network E2E tests	Private virtual number with webhook

Checklist for your SMS OTP flow

Codes expire (5–10 minutes is typical) and are single-use
Rate-limit code requests per number and per IP
Accept common input formats: with or without +, spaces and dashes
Message under 160 GSM-7 characters so it isn't split
Clear sender name and app name in the text
A "resend code" button with a cooldown
Test at least one number per country you launch in

FAQ

Can I test SMS verification for free?
Yes. Mocks and provider test numbers cost nothing, and free temporary numbers let you check real delivery without buying a SIM.

Why does my OTP SMS arrive in one country but not another?
Carriers apply different rules: some require registered sender IDs or templates, and some filter messages that look like spam. Test with a real number in each target country.

Is it safe to use public temporary numbers?
For throwaway test accounts, yes. Never use them for production admin accounts or real customer data, because anyone can read the messages.

More in this series on SMS verification: