TL;DR — Real carrier SIM numbers from VirtualSMS pass every line-type check that WhatsApp, Telegram, Google, and Discord run before dispatching an OTP — the same check that rejects Google Voice, TextNow, and most free virtual number services. Single-use activations start from $0.05 across 2500+ services in 145+ countries, with auto-refund if no SMS arrives in 20 minutes. A REST API and a first-of-class MCP server (18 tools) let you pull OTP codes directly inside your test runner or AI agent. Success rate on real-SIM orders: Consistently high.
An indie developer shipped a customer-service Telegram bot and assigned it a phone number from a single-use OTP service. Seven days in, the bot account got logged out — the number had been rotated to another buyer by the OTP provider and the old session invalidated. He switched to a 30-day Full Access rental from VirtualSMS, the bot stayed authenticated for the whole rental window, and he renewed for a 90-day tier afterward. That sequence captures the core problem with disposable OTP services for developer workflows: they are designed for human one-time verification, not for accounts or sessions that need to persist.
If you are building any app with SMS-based authentication, you will need real phone numbers for testing — not mock codes that never leave your infrastructure, not Google Voice numbers that fail Twilio line-type checks, and not shared free SMS inboxes that leak codes to every visitor. This guide covers what works, what does not, and how to integrate virtual number procurement directly into your test pipelines via the VirtualSMS REST API and MCP server.
Key Takeaways
- Real carrier SIM numbers pass HLR and line-type checks — the same checks WhatsApp, Google, and Telegram run before sending any OTP
- Single-use activations auto-refund after 20 minutes if no code arrives — no cleanup step needed in CI pipelines
- Full Access rentals give you a dedicated SIM inbox for 1–30 days — correct for persistent accounts and multi-session tests
- The VirtualSMS REST API returns order IDs and phone numbers in one call; OTP extraction is a simple GET poll
- VirtualSMS is the only SMS verification provider with a production MCP server — zero competitors had one as of May 2026
Why Real Phone Numbers Fail for App Testing
Every app developer building SMS-based authentication eventually hits the same wall: they run out of personal phone numbers. You can burn your own number on the first test environment, use a team member’s number for staging, and use a Google Voice number for a third environment — and at that point you are stuck, because Google Voice numbers fail line-type checks on WhatsApp, Telegram, and Google itself.
The line-type check is the root cause. Before WhatsApp dispatches an OTP, it queries a number intelligence API — Twilio Lookup V2 or a comparable service — that classifies every number as “mobile,” “fixed-line,” or “Non-Fixed VoIP.” Numbers from Google Voice, TextNow, Skype, and most free virtual number services classify as Non-Fixed VoIP. That flag triggers an automatic rejection before any OTP sends. The error message says “verification failed” — it does not say “VoIP blocked” — so most developers try the same number several more times before realizing the rejection is structural.
Why VoIP numbers fail verification checks — the full technical breakdown →Personal phone numbers create a different set of problems:
- Account association: once a personal number is used in a staging environment and receives an OTP, some platforms associate that number with the test account. Re-using it in another environment or test run may produce “this number is already in use” errors.
- Rate limits: platforms impose per-number OTP request limits. Hitting a rate limit on your personal number during a test run locks you out of verification for minutes or hours.
- Team scale: a five-person QA team cannot share two personal phone numbers across parallel test runs.
- CI/CD incompatibility: automated test pipelines cannot interactively receive SMS on a team member’s phone.
Virtual numbers with a clean REST API solve all four. The question is which virtual numbers actually work on the platforms you are testing against.
What Makes a Virtual Number Work for SMS-Based Authentication Testing
The answer is carrier registration. A real SIM card is registered on a licensed carrier network — Vodafone, O2, T-Mobile, Lebara, or another carrier — and appears in that carrier’s HLR (Home Location Register). When a platform runs an HLR lookup or line-type check on the number, it returns “mobile.” That is the result that clears the pre-OTP filter.
VoIP virtual numbers — and most free SMS sites — have no physical SIM, no carrier registration, and no HLR entry. They return “Non-Fixed VoIP” in line-type databases, regardless of how long you have held the account or how many previous verifications succeeded. The classification is per-number, not per-session.
Opinion: Cheapest-per-number is the wrong metric when you are testing authentication flows. The real question is cheapest-per-successful-verification. At 45% success on a VoIP number, you need roughly 2.2 attempts per verified account. At a consistently high success rate on a real-SIM activation from VirtualSMS, you need roughly 1.05. The math inverts the apparent price advantage well before you factor in the time cost of failed attempts and retrying.
VirtualSMS activations run on real carrier-issued SIM cards. Each number that appears in an API response has an IMSI, routes over SS7, and appears in carrier HLR records — the same infrastructure a live user’s phone uses. The consistently high success rate on real-SIM orders reflects that: the only failures are carrier-side delivery issues, not line-type rejections.
Browse 2500+ services available for activation →Key Testing Scenarios That Need Virtual Numbers
Six scenarios come up repeatedly in developer and QA workflows. Each has a different optimal number type.
Signup Flow Integration Tests
The standard end-to-end signup test: create an account, receive OTP, enter OTP, confirm account. Single-use activations are correct here. Each test run creates a fresh order, gets a new number, receives the OTP, and the order auto-expires — no cleanup needed. The 20-minute window is generous enough for most CI pipelines; if your signup flow has a sub-5-minute completion path, most orders will close in under 2 minutes.
What to use: Single-use activation via REST API. POST to create order, GET to poll for SMS, extract OTP with a regex on the sms_text field.
Two-Factor Authentication Re-verification
Some platforms send a 2FA challenge when they detect a new device, unusual login location, or after a password change. Testing this flow in staging requires the same number to receive SMS across two separate sessions: the initial account creation and the subsequent 2FA trigger. A single-use activation will not work — it expires after the first code arrives. A Platform Rental or Full Access rental keeps the same number active across both sessions.
What to use: Platform Rental (locks SIM to one service for 1, 3, or 7 days) or Full Access Rental (entire SIM, any service, 1–30 days).
Number Re-use Rejection Tests
Many platforms block a phone number if it has been used to create an account that was later suspended or deleted. Testing this edge case requires a number that has never been used on the target platform. Fresh activations from VirtualSMS are provisioned from inventory with prior-use filtering — numbers with known-bad history on high-rejection platforms are excluded from the pool for that service. This is not something you can guarantee with a free SMS site or a Google Voice number that has an unknown prior history.
What to use: Single-use activation. Use the service parameter to target a specific platform — this routes to the best-quality inventory for that service.
Multi-Region Regression Testing
Global apps behave differently by region — carrier delivery speeds vary, platform-specific rules around number formatting differ, and some services have region-specific verification flows. Testing all regions in a single CI run requires one number per country per test, provisioned programmatically. VirtualSMS covers 145+ countries via API.
What to use: Single-use activations parameterized by country code. Build a country matrix in your test config and iterate over it in CI.
Persistent Account Sessions (Bots, Integrations, Staged Rollouts)
Some developer use cases are not testing at all — they need a real persistent phone number associated with an account that will run for days or weeks. Telegram bots, WhatsApp Business integrations, verification workers in a staged rollout, or a dedicated test account that holds its session across deployment cycles all require a number that stays valid for the account lifetime.
What to use: Full Access Rental (1, 3, 7, 14, or 30 days). The SIM is exclusively yours for the rental period — no rotation, no expiry until the end of the window.
Production Smoke Tests
After a deployment, a smoke test suite validates that the live signup flow still works end-to-end on production. This differs from staging tests: you are hitting real platform infrastructure, real carrier routing, and real OTP delivery. The number needs to be real enough to pass production line-type checks. A staging mock will not catch a production-only regression in the OTP delivery path.
What to use: Single-use activation against production service IDs. Keep a small pre-purchased credit balance for smoke test runs — $5 covers roughly 50–100 smoke test activations depending on the service and country mix.
API Integration for Automated OTP Testing
The VirtualSMS REST API is designed for programmatic number procurement. The core flow for a single-use activation is three calls:
# 1. Create an order — specify service and country
POST /api/v1/orders
{
"service": 14, # service ID (WhatsApp = 14, Telegram = 1, Google = 5, etc.)
"country": 22 # country ID (UK = 22, Germany = 1, France = 12, etc.)
}
# Response: order ID + phone number
{
"orderId": "ord_abc123",
"phoneNumber": "+447911123456",
"expiresAt": "2026-07-01T12:20:00Z"
}# 2. Poll for incoming SMS
GET /api/v1/orders/ord_abc123/sms
# When the OTP arrives:
{
"status": "received",
"smsText": "Your WhatsApp code: 847-291 Do not share this code"
}
# While waiting:
{
"status": "pending"
}# 3. Extract OTP with a regex in your test runner
# Python example:
import re, requests, time
def get_otp(order_id, api_key, timeout=300):
headers = {"Authorization": f"Bearer {api_key}"}
deadline = time.time() + timeout
while time.time() < deadline:
r = requests.get(
f"https://virtualsms.io/api/v1/orders/{order_id}/sms",
headers=headers
).json()
if r["status"] == "received":
match = re.search(r"\d{6}", r["smsText"])
return match.group(0) if match else r["smsText"]
time.sleep(3)
raise TimeoutError("OTP not received within window")Auto-refund fires automatically when the 20-minute window expires without an SMS delivery — no explicit cancel call needed. This matters for CI: a failed activation does not require a cleanup step in your teardown, and the credit is immediately available for the next order in the queue.
For high-volume test suites, webhooks eliminate polling entirely. Register a webhook endpoint and the platform pushes the SMS payload to your URL on delivery — no loop required in the test runner.
MCP server for AI agents — 18 tools including order creation and OTP retrieval →Supported Testing Frameworks
The API is HTTP + JSON, so it integrates with any framework that can make HTTP calls:
| Framework | Integration pattern |
|---|---|
| Playwright | page.evaluate() + fetch() for order creation; poll before page.fill() on OTP input |
| Cypress | cy.request() for order creation + SMS polling; cy.wrap() to wait for OTP |
| Jest / Vitest | axios or node-fetch in beforeEach; extract OTP in setup step |
| Pytest | requests in fixture; pytest-asyncio for async poll loop |
| Selenium | Standard HTTP client in test setup; inject OTP via send_keys() |
| Appium (mobile) | HTTP client in test class; OTP entered via driver.find_element().send_keys() |
The MCP server (18 tools) is the path for AI-agent-driven testing — workflows where an AI agent handles the full signup interaction and needs to retrieve the OTP without a separate polling loop in the test harness. No other SMS verification provider had a production MCP server as of May 2026.
Testing Across Staging, Dev, and Production Environments
Different environments have different requirements for phone number procurement.
Development Environment
Goal: fast iteration, low cost, not hitting real platform rate limits.
In a local dev environment, mock SMS delivery for most tests. Use a mock OTP service (your own stub endpoint that returns a hardcoded code) for unit tests of the OTP input component, form validation, and error states. Reserve real virtual number calls for the tests that must cover real platform behavior — specifically, anything that exercises the platform’s OTP dispatch itself.
When you need real numbers in dev: single-use activations are fine. Keep a small balance for dev testing and track activation counts per developer. At $0.05–$0.10 per activation, a developer running 20 test activations per day spends $1–$2/day — a reasonable line item that does not require a shared staging account.
Staging / QA Environment
Goal: full end-to-end coverage against real platform APIs, reproducible across test runs, parallelizable across the QA team.
Staging is where virtual numbers pay off most. Maintain a service ID map in your staging config — each platform you test maps to a VirtualSMS service ID and a country preference. Your CI pipeline creates a new activation order at the start of each test run, uses the number for the OTP step, and the order auto-expires. No shared credentials, no contention, no rate limit pooling.
For tests that require a number to persist across multiple steps in the same suite run — for example, a test that covers account creation, then a settings change that triggers re-verification — use a Platform Rental scoped to the test run duration.
# Example CI config (GitHub Actions)
env:
VSMS_API_KEY: ${{ secrets.VSMS_API_KEY }}
VSMS_SERVICE_WHATSAPP: 14
VSMS_SERVICE_TELEGRAM: 1
VSMS_COUNTRY_UK: 22
VSMS_COUNTRY_DE: 1Production Smoke Testing
Goal: validate live OTP delivery after each production deployment.
Smoke tests against production are the highest-value use of real virtual numbers. They catch delivery regressions — carrier routing issues, platform OTP sender changes, delivery delays above your SLA threshold — that staging environments cannot reproduce because they use mocked delivery paths.
Keep smoke tests minimal: one number per platform per deployment, one OTP extracted and verified per number. A five-platform smoke test costs $0.25–$0.50 in activations and takes 90–120 seconds in CI. That is a reasonable cost for catching a production OTP delivery regression before users do.
Country Strategy for Global App Testing
Platform behavior varies by country. These patterns come up often enough to warrant explicit guidance:
| Scenario | Recommended countries | Notes |
|---|---|---|
| WhatsApp OTP testing | UK, Germany, France | Strong carrier delivery on WhatsApp; consistent OTP format |
| Telegram verification | UK, France, Netherlands | Telegram’s SMS delivery is reliable across Western Europe |
| Google / Gmail account creation | UK, Germany | Google’s line-type checks are strict; these countries have clean HLR results |
| App with US-specific flows | United States | Some platforms have US-specific OTP templates or rate limits; test with a real US number |
| Southeast Asia regional testing | Indonesia, Philippines, Malaysia | High-traffic app markets with different carrier stacks |
| Latency-sensitive smoke tests | Country closest to your CI runners | Reduces OTP delivery latency; UK or Germany for EU-based CI, US for US-based |
Avoid testing the same country+service combination in parallel at high concurrency — carrier pools for a given country+service combination have finite inventory. For parallelism above 20–30 concurrent orders in the same country+service combination, distribute orders across multiple countries for the same service.
VirtualSMS vs Other Testing Solutions
The comparison that matters is not price-per-number but whether the solution actually works on the platforms you are testing against.
| Solution | Number type | Works on WhatsApp / Telegram / Google? | CI/CD compatible? | Auto-refund |
|---|---|---|---|---|
| Personal phone numbers | Real SIM | Yes | No | n/a |
| Google Voice / TextNow | Non-Fixed VoIP | No — fails line-type check | No (manual) | n/a |
| Free SMS sites (receive-sms.com etc.) | Shared pool, mixed type | Inconsistent — numbers burned fast | No (no API) | No |
| Twilio / AWS SNS | Programmable number | Yes (carrier-registered) | Yes | No — you pay per number regardless |
| SIM device farm (self-hosted) | Real SIM | Yes | Yes (custom infra) | n/a — capital cost |
| VirtualSMS | Real carrier SIM | Yes — consistently high success | Yes (REST API + webhooks) | Yes — 20-min auto |
Twilio and AWS SNS provision real carrier-registered numbers but charge for the number reservation regardless of whether an OTP arrives. They also require upfront number provisioning rather than on-demand order creation, and their cheapest numbers are orders of magnitude more expensive per activation than the $0.05 floor for VirtualSMS. For integration testing at scale, on-demand provisioning with auto-refund on failure is a materially better cost structure.
Self-hosted SIM device farms give you full control but require capital (hardware), maintenance (firmware updates, SIM rotation, carrier contracts), and ops overhead that is disproportionate for a testing tool. They are justified for very high-volume production verification pipelines but not for a QA environment.
Full VoIP vs real SIM comparison →Practical QA Workflow with Virtual Numbers
For Manual QA Testers
- Go to virtualsms.io/verifications — no account required to browse available services
- Select the service you are testing (e.g. WhatsApp, Telegram, Discord, Google)
- Select a country
- Purchase the activation — you need an account and a credit balance
- The assigned phone number appears immediately — enter it in the app you are testing
- The incoming SMS appears in your VirtualSMS inbox, typically within 30–90 seconds
- Copy the OTP into the app
- If no SMS arrives within 20 minutes, the order auto-refunds — try a different country
For manual testers running a regression pass, the dashboard is the fastest path. API integration is only necessary when you are automating the OTP extraction step inside a test runner.
For Automated Test Suites
The high-level pattern, language-agnostic:
1. TEST SETUP
- Load VSMS_API_KEY from environment
- Map test platform to service ID and preferred country ID
- POST /api/v1/orders → receive {orderId, phoneNumber}
- Store phoneNumber in test context
2. TEST EXECUTION
- Fill phone number field with test context phoneNumber
- Submit form / trigger OTP dispatch
- Poll GET /api/v1/orders/{orderId}/sms until status = "received" or timeout
- Extract OTP from smsText with regex (typically \d{4,8})
- Fill OTP field with extracted code
- Assert on expected post-verification state
3. TEST TEARDOWN
- On success: order has likely auto-expired; no cleanup needed
- On timeout: order auto-refunds after 20-minute window; no manual cancel needed
- Log orderId for debugging failed runsFor the MCP server path — used when an AI agent is driving the browser interaction rather than a deterministic test script — the order creation and SMS retrieval are MCP tool calls within the agent’s tool loop. The agent calls create_order, fills the phone number field, waits, then calls get_sms to retrieve the OTP. This is the pattern for AI-agent testing frameworks like those built on Playwright’s agent mode or custom agent harnesses.
Frequently Asked Questions
Can I use virtual numbers in automated CI/CD pipelines?
Yes. The VirtualSMS REST API lets you create an order, poll for the incoming SMS, extract the OTP, and cancel unused orders programmatically — all within a test run. You send a POST to create the order, receive a number and order ID in the response, and poll GET /api/v1/orders/{orderId}/sms until your OTP arrives or the 20-minute window closes. Auto-refund fires on expiry, so failed orders do not need manual cleanup. The API is stateless and returns JSON; it slots into any test runner that can make HTTP requests — Playwright, Cypress, Jest, Pytest, RSpec, or a CI script. For higher call volumes, webhooks let the platform push the SMS to your endpoint instead of polling.
How many test numbers can I get at once?
There is no documented hard cap on concurrent orders via the API. In practice, developers run 10–50 parallel activations without throttling. For large-scale test suites that need hundreds of numbers simultaneously, Full Access rentals give you dedicated SIMs for the duration of your test run — each rental is a private inbox, so you can run N rentals in parallel with no cross-contamination. For parallelism above 20–30 concurrent orders against the same country+service combination, distribute across countries to avoid hitting inventory limits in a single pool.
What is the difference between a virtual number for testing and a sandbox environment?
A sandbox environment simulates SMS delivery with mock codes that never leave your infrastructure — useful for unit tests but useless for testing real platform integrations. WhatsApp, Telegram, Google, and Discord send OTPs to real carrier numbers, not to sandbox endpoints. A virtual number from VirtualSMS is a real SIM card on a real carrier network — Vodafone, O2, T-Mobile, Lebara, or another licensed carrier. The OTP travels the same path it would for a live user. This is the only way to test authentication flows that involve real platform anti-fraud checks — line-type validation, HLR lookup, and delivery confirmation all behave identically to production because you are in production from the platform’s perspective.
My app needs to test in multiple regions. Can I get numbers from different countries?
Yes. VirtualSMS covers 145+ countries. For each order you specify the country code and the service — for example, a UK number for WhatsApp or a French number for Telegram. The API accepts country IDs (the full list is at /api/countries) and a numeric service ID (the full list is at /api/services). For global regression testing, a typical pattern is to maintain a country matrix in your test config — one number per region per test run — and parameterize the order creation step. Full Access rentals are particularly useful here: rent a SIM per region and run all regional tests against the same dedicated number for the duration, avoiding repeat activation fees across test runs.
Will the same virtual number work for multiple test runs?
Single-use activations expire after one OTP code is delivered or after 20 minutes, whichever comes first — correct for integration tests that cover the signup flow end-to-end. For tests that need the same number to receive SMS across multiple sessions or test runs, use a Full Access rental: the SIM stays active and the inbox stays open for the full rental period (1, 3, 7, 14, or 30 days). A Platform Rental is the middle option — a shared SIM locked to one specific service for 1, 3, or 7 days, cheaper than Full Access when you only need SMS from one platform.
How does auto-refund work for failed verifications in a test suite?
For single-use activations, auto-refund fires automatically when the 20-minute order window closes without an SMS delivery — no API call required from your side. The credit returns to your account immediately and is available for the next order. This matters for test suites: failed activations do not require a cleanup step or manual refund request, so your CI pipeline cannot get stuck waiting on refund processing. For Full Access and Platform Rentals, refund requires a user cancel within the first 20 minutes if no SMS has arrived — after the first SMS arrives, the rental runs for the full period.
The Bottom Line
Testing SMS-based authentication properly requires real carrier-registered phone numbers — not VoIP numbers that fail line-type checks, not shared free inboxes that leak OTP codes to every visitor, and not personal phone numbers that accumulate rate limits and account associations across test runs.
VirtualSMS gives you real SIM card activations from $0.05 across 2500+ services in 145+ countries, with a REST API and MCP server that integrate directly into automated test pipelines. Auto-refund on failed activations means your CI pipeline has no cleanup overhead. Full Access rentals cover the cases where you need a stable, dedicated phone number for days or weeks — persistent bot accounts, multi-session test flows, or per-region dedicated numbers in a global regression suite.
Browse available services and countries → · View the MCP server documentation → · See pricing →
