Phone Verification Abuse: When OTP Costs Become an Attack Vector

Phone verification can be attacked for profit: bots request one time codes to premium or revenue sharing numbers, or flood the endpoint to run up your messaging bill. Defences combine per number and per IP rate limits, country allow lists matched to your market, and risk based challenges before any code is sent.

The attack that bills you for participating

SMS pumping turns your verification system into someone else's revenue. Fraud operators control ranges of numbers, often through complicit or careless carriers, that pay them a share of termination fees. Their bots request codes to those numbers from your signup flow at scale. The codes are real, the messages are delivered, your provider bills you for all of them, and a cut flows back to the attacker. Your funnel shows thousands of verifications started and almost none completed.

For more on this, see this related guide and our earlier explainer on the same theme.

A second motive is pure cost imposition: competitors or extortionists flood the endpoint to inflate your messaging spend and degrade the service. Either way, the signature is similar, and the damage lands in a budget line, messaging, that many teams review monthly in arrears. By the time finance asks why the bill tripled, the attack has usually been running for weeks.

Patterns that reveal pumping early

Geography is the loudest signal. Verification requests concentrating in countries where you have no customers, no marketing, and no plans are not a growth story. Completion rate completes the picture: legitimate traffic finishes verification at a fairly stable rate, while pumped traffic barely completes at all, because nobody is waiting for those codes. Requests per number, per IP range, and per device clustering far beyond human patience point the same way.

Alert on the combination in near real time: request volume by country, completion rate by country, and cost per completed verification overall. That last metric is the one executives understand instantly. When it moves, something is wrong regardless of which specific attack is running, and it deserves a threshold alarm like any other production metric.

Defences that stop the billing, not the user

Put a challenge before the send. A lightweight bot check or proof of interaction ahead of the code request breaks most pumping economics, because the attack needs cheap, unlimited sends. Rate limit aggressively by number, IP, and device, and limit resends with growing delays. Real users mistype and retry once or twice. Nothing human needs forty codes in an hour.

Readers also found this companion piece from our archive useful.

Match your country list to your market. If you serve three countries, the verification endpoint should send to three countries, reviewed when expansion plans change. Where you must send widely, apply stricter limits and monitoring to high cost destinations, and choose messaging providers with fraud controls such as pumping detection and destination based caps. Also consider channel alternatives for risky contexts: authenticator apps, email codes, or voice fallback where the cost profile differs.

Designing verification to be worth attacking less

Step back and ask how much of your flow needs SMS at all. Phone verification is often cargo culted into signups that would be fine with email confirmation plus later step up checks for sensitive actions. Moving SMS to the moments that truly need it, such as account recovery or high value transactions, shrinks the attack surface and the baseline bill at the same time.

Where SMS stays, make the economics visible: a small dashboard of sends, completions, and cost per completion, reviewed weekly by the team that owns signup. Abuse of verification thrives in the gap between the security team, which does not own the bill, and the growth team, which does not own the risk. One shared number closes that gap faster than any single control.

Frequently asked questions

What is SMS pumping?

A fraud where bots trigger one time codes to numbers whose operators share in the messaging termination revenue. The victim business pays its provider for thousands of delivered but never used codes, and part of that money flows back to the attackers.

How can we spot verification abuse quickly?

Watch requests and completion rates by country, requests per number and IP, and cost per completed verification. A surge of requests from countries outside your market with near zero completions is the classic pumping signature.

Will a CAPTCHA before sending codes hurt conversion?

A lightweight challenge placed only before the SMS send has a small effect on real users and a large effect on attack economics, which depend on cheap unlimited requests. Risk based challenges, shown only to suspicious traffic, reduce the friction further.

Should we remove phone verification entirely?

Not necessarily, but scope it to where it earns its cost, such as recovery and high risk actions, rather than every signup. Narrower use means a smaller bill, a smaller attack surface, and verification that still protects the moments that matter.

See your own numbers.

A free bot-traffic audit shows the human-automated split in your live traffic - no code changes, no commitment.

Get a free bot-traffic audit

Do allowlists stop mint bots?

They stop the lazy ones. A strict allowlist with real verification, wallet age, activity history, or off-chain identity, filters out stages one and two. Determined operators buy or farm allowlisted wallets, which is why the allowlist is the start of the defense, not the whole of it.

Should mints just accept that bots will get some supply?

Some leakage is realistic, but 'accept' is the wrong frame. Every percentage point of supply that reaches real collectors instead of bots is community goodwill and secondary-market health. The projects that treat bot defense as ongoing maintenance keep more supply in the right hands than the ones that ship one check and move on.

>