Phone verification is one of the few parts of an app you cannot fully test with mocks. Your code might be perfect, yet real users still fail because a carrier filtered the message, the number format was rejected, or the code arrived after the screen timed out. Testing against real numbers on real networks is the only way to catch those failures before customers do.
This playbook shows how teams use temporary numbers to build a repeatable, affordable SMS-verification test suite.
Why mocks are not enough
Unit tests and stubbed SMS providers verify your logic: that a code is generated, stored, expired and compared correctly. They cannot tell you:
- whether your SMS provider actually delivers to a given country today;
- whether your phone-number input accepts that country's format (leading zeros, nine- versus ten-digit mobiles,
+handling); - how long delivery really takes, and whether your resend timer is sensible;
- whether the message body renders correctly in the recipient's language and character set;
- whether your fraud rules accidentally block legitimate traffic from a region.
A temporary number answers each of these with a real handset-equivalent on a real carrier.
Structure your test plan by risk, not by country count
You do not need 200 countries in every regression run. Group markets by revenue and risk:
| Tier | What to include | How often |
|---|---|---|
| Core | Your top 3–5 markets by signups | Every release |
| Growth | Markets you are actively expanding into | Weekly |
| Edge | Countries with unusual formats or strict carriers | Monthly or on provider change |
Edge-tier candidates usually include India (DLT-registered templates), the United States (10DLC filtering), Brazil (eleven-digit mobiles with area codes) and any country where you saw a support spike.
The test cases that matter
For each country in a run, cover more than the happy path:
- Happy path — rent number, request code, receive, submit, account created.
- Slow delivery — does the UI keep waiting gracefully? Is the resend button disabled for a sensible period?
- Resend — request a second SMS. Does the old code stop working? Does the new one arrive? Many temp-number activations support a second SMS while the rental is open.
- Wrong code — attempts counter increments, lockout triggers at the threshold, error copy is clear.
- Expired code — wait past your expiry and submit; the server must reject it.
- Format variants — paste with spaces, with and without
+, with a national leading zero. - Message content — the brand name, code position and language are correct; on Android the message matches your SMS Retriever hash if you use auto-fill.
Record delivery time for each run. A gradual increase is often the first sign that a route is degrading.
Keep costs predictable
Temporary numbers are cheap, but a careless suite can still burn money. A few rules keep spend flat:
- Only rent when the app is ready to send. Rental windows are limited — renting a number and then waiting for a slow build wastes it.
- Cancel numbers you no longer need. On OTP Bolt an activation with no SMS is refunded automatically, and cancelling early returns the money straight away.
- Use a developer plan if you run more than a handful of tests a week; plans lower the per-OTP price for their term.
- Cache nothing — never reuse a temp number across test runs. It is single-use by design and may belong to someone else tomorrow.
Automate it
Manual testing is fine for exploratory work, but regression suites should run themselves. With the OTP Bolt REST API a test step becomes:
# rent a number for Telegram in the UK
curl -s -X POST https://otpbolt.com/api/v1/activations \
-H "Authorization: Bearer $OTPBOLT_KEY" \
-H "Content-Type: application/json" \
-d '{"service":"telegram","country":"gb"}'
Your test framework types the returned phone into the app, then polls GET /api/v1/activations/{id} until status is received and reads code. We walk through a full Playwright example in testing SMS verification in CI.
When a temp number is the wrong tool
Temporary numbers are designed for one verification. They are a poor fit when:
- the account you create needs repeated logins over weeks — the number will not be yours later;
- you need to test inbound calls or long SMS conversations;
- your QA scenario involves number porting or carrier-specific features.
For those cases use a dedicated number you keep for the whole project. OTP Bolt's My Numbers gives you a US or Canada line with a persistent SMS inbox and browser calling, billed on a flat term.
Checklist
- Tier your markets and test the core tier every release.
- Cover resend, expiry, wrong-code and format variants — not just the happy path.
- Measure delivery time and watch the trend.
- Rent late, cancel early, never reuse.
- Automate with the API and keep a dedicated number for long-lived test accounts.