Prevent OTP request abuse by making an explicit decision before sending each one-time code. Bound resend behavior, monitor which destinations receive messages, and compare accepted sends with completed verification attempts.
A sudden SMS bill or a falling verification rate deserves investigation. Neither, on its own, proves SMS pumping: delivery failures, a broken resend button, and changed signup traffic can produce similar symptoms.
Twilio's Verify fraud-prevention guidance describes delayed retries, rate controls, destination restrictions, and monitoring completed verifications relative to sends. Apply the mechanisms your provider supports rather than assuming every service has the same features.
Map issuance and verification separately
An OTP workflow has at least two decisions: whether to issue a code and whether a submitted code is valid. Protecting the second does not control the cost of the first.
Inventory each issuance route, including signup, login, phone changes, and recovery. Include alternative channels such as voice calls if the interface offers them. A restricted SMS path is incomplete if an unrestricted “call me” action reaches another provider operation.
Keep a correlation ID for the verification attempt. Record delivery state and verification outcome without retaining the code itself. Treat phone numbers as sensitive operational data, with restricted access and a retention limit.
Read the funnel before blocking destinations
Use counts from the same cohort and time window. A person who receives a code late may verify after the reporting interval ends.
| Stage | Useful question |
|---|---|
| Issuance requested | Did one flow suddenly begin requesting more codes? |
| Send allowed | Which application controls accepted the work? |
| Provider accepted | Was a billable or queued operation created? |
| Delivery reported | Is there a channel or destination delivery problem? |
| Verification completed | Did recipients finish the intended workflow? |
Choose and label your denominator. “Verified attempts divided by accepted sends” differs from “verified users divided by signup sessions.” Do not call both numbers conversion without qualification.
Put resend policy on the server
Show the user when another code can be requested, but enforce the decision server-side. Group related requests under the verification attempt where possible. Also consider account, destination, and source budgets so rotating one identifier does not reset every allowance.
Document what the application does when a send has an unknown outcome. Blindly retrying a provider request can create duplicate delivery work; blindly refusing can strand the user. Use the provider's supported retry semantics and keep an operator-visible state for unresolved delivery.
OWASP API6 explains why a legitimate workflow needs limits when excessive automated use creates harm. OTP sending is a useful place to apply that review.
Keep a legitimate path through the controls
Before restricting a destination region, compare it with the countries the application actually serves. A new marketing campaign or expansion may change the expected population. Escalate unexplained concentration to the delivery provider with a bounded time window and relevant references.
Check a traveler, a user on a shared network, a delayed delivery, and a retry after reopening the app. These cases should have intentional outcomes. Do not let repeated requests made by somebody else permanently prevent an account owner from recovering access.
Bot classification can inform the pre-send decision in a supported integration. It does not prove who controls a telephone number or whether a carrier relationship is fraudulent.
Close the investigation with a stage-level result
After a change, inspect accepted sends, actual delivery, completed verification, and support contacts. A reduction in messages is not a success if legitimate verification also stops.
For password-link delivery problems, see password-reset flooding. The account takeover use case is the relevant broader protection discussion. Bring the issuance path and provider behavior to that review so traffic controls do not become a substitute for correct verification logic.