You built an AI agent that onboards to a new service, creates an account, fills in a form, and gets all the way to SMS verification — then hits a wall.
"This phone number cannot be used for verification."
Or worse: the code is never sent and no error appears at all. Your agent just sits there waiting.
This is the VoIP blocking problem. It affects every AI agent that needs a real phone identity, and it's getting worse as fraud rates on virtual numbers rise. This guide explains exactly what's happening, why every major service blocks VoIP numbers, and what the working alternatives are.
The Problem: VoIP Numbers Fail Production Verification
Most developers building phone-capable AI agents reach for the obvious choices: Google Voice, TextNow, Twilio programmable numbers, Telnyx, or Vonage. These are cheap, API-accessible, and work fine in development. They fail in production.
The services your agent needs to verify with — Stripe, Google, Amazon, WhatsApp, Microsoft, financial institutions — all run carrier lookup checks before sending verification codes. If the lookup returns nonFixedVoip or fixedVoip, the request is rejected. The code is never sent.
Here's the list of confirmed blockers, with the evidence:
| Service | Block Type | User-Facing Message |
|---|---|---|
| Stripe | Hard error | "This phone number cannot be used for verification" |
| Silent or vague | "Something went wrong" / "This number cannot be used" | |
| Amazon | Silent delivery failure | Code simply never arrives |
| Hard error | "Unsupported phone numbers, such as VoIP, landlines..." | |
| Microsoft Entra ID | Risk-based block | Error 399287 "BadReputation" |
| Vercel | Hard block at signup | Registration rejected |
| DocuSign | Hard block at signup | Registration rejected |
| Banks (BMO and others) | Silent or misleading | Codes not delivered, vague errors |
These aren't edge cases. They're deliberate product decisions backed by fraud data, and the blocking is accelerating.
A fintech security professional on Hacker News described Stripe's logic directly:
"We reject VoIP phone numbers due to proven fraud activity. VoIP numbers can be obtained with no identity verification, recycled instantly after use, and are disproportionately associated with account takeover attempts."
WhatsApp's official FAQ states it explicitly:
"Unsupported phone numbers, such as VoIP, landlines, and premium rate numbers, are not eligible for registration."
Microsoft's documentation lists VoIP support status plainly:
"Phone extensions and VOIP numbers are not supported for MFA."
For AI agent developers, this creates a hard requirement: your agent needs a number that carrier lookup APIs classify as mobile, not voip. Understanding how that classification works is the first step to solving it.
How Carrier Lookup Works: The Technical Infrastructure
When Stripe, Google, or WhatsApp receives a phone number for verification, they don't just check a blocklist. They query a carrier lookup API that interrogates multiple interconnected telecom databases. Here's how the chain works.
Step 1: Parse NPA-NXX
Every US phone number in E.164 format starts with the country code (+1), followed by a 10-digit number. The first 6 digits — the NPA (Numbering Plan Area, aka area code) and NXX (exchange code, aka the first 3 of the 7-digit local number) — form the lookup key.
For example, +14155551234: NPA = 415, NXX = 555.
Step 2: Query the LERG
The Local Exchange Routing Guide (LERG) is a database published by iconectiv, the FCC-designated North American Numbering Plan Administrator. It maps every NPA-NXX block to an Operating Company Number (OCN).
The LERG contains multiple tables:
- LERG1 — OCN information including carrier name, type, and state
- LERG6 — NPA NXX assignments (which carrier owns which blocks)
- LERG7 — Switch data
- LERG12 — LRN (Location Routing Number) assignments
The OCN lookup tells you which carrier was originally assigned the number block.
Step 3: Check NPAC for Porting
Number portability changed everything. Under FCC LNP (Local Number Portability) rules, any US number can be ported from one carrier to another. The Number Portability Administration Center (NPAC), also operated by iconectiv, records every porting event.
When a number is ported, NPAC stores:
- The current SPID (Service Provider ID)
- The LRN (Location Routing Number) for routing
- The porting date and history
The SPID is critical: it encodes the line type directly.
| SPID Carrier Type | Line Type |
|---|---|
| Type 0 | Wireline (ILEC) |
| Type 1 | Wireline (CLEC) |
| Type 2 | Wireless / Mobile |
| Type 3 | VoIP |
If NPAC shows a porting event and the current SPID has carrier type 3, the number is VoIP — even if the original LERG assignment was to a mobile carrier.
Step 4: Look Up OCN Type
Each OCN has a carrier type classification assigned by the FCC:
- ILEC — Incumbent Local Exchange Carrier (traditional landline providers: AT&T, Verizon wireline)
- CLEC — Competitive Local Exchange Carrier (alternative wireline providers)
- WIRELESS — Mobile Network Operators (AT&T Mobility, T-Mobile, Verizon Wireless)
- VOIP — Voice over IP providers (Google Voice, Twilio, Bandwidth, Lingo)
- CABLE — Cable companies offering phone service (Comcast Xfinity, Cox)
Step 5: Classify and Return
The carrier lookup API combines the LERG OCN type and the NPAC porting data:
if current_spid_type == 3 → VoIP (ported to VoIP)
else if ocn_type == WIRELESS → mobile
else if ocn_type == VOIP → VoIP (never ported)
else if ocn_type == ILEC/CLEC/CABLE → landline
The result propagates into two major sub-categories for VoIP:
fixedVoip — VoIP numbers tied to a specific physical location or device. Examples: Comcast Business Voice, enterprise PBX systems, some CLEC offerings. These require a physical installation at a premises address. They're considered more legitimate and some services allow them.
nonFixedVoip — VoIP numbers that can be obtained online with no physical address or device requirement. Examples: Google Voice, TextNow, Vonage, Twilio programmable numbers, Telnyx numbers. These can be created with a credit card, no identity verification, and cancelled instantly. This is the category most aggressively blocked.
Additional Signals
Beyond the core LERG/NPAC/OCN chain, carrier lookup APIs may also query:
- HLR (Home Location Register) — Mobile carrier subscriber databases. A failed HLR lookup for a supposedly mobile number is a strong VoIP indicator.
- CNAM databases — Caller Name databases. VoIP numbers frequently show unusual or generic names.
- ANI/SS7 Information Digits — In real-time call signaling, Information Digits classify the call origin. VoIP calls carry digit codes that differ from mobile calls.
- Proprietary fraud databases — IPQS, Telesign, and others maintain additional lists of numbers with fraud history.
The Carrier Lookup API Ecosystem
There are eight major APIs developers use to perform carrier lookup. Understanding their differences helps you predict how the services your agent needs to verify with are classifying your numbers.
| API | Provider | Pricing | Line Type Field | Notes |
|---|---|---|---|---|
| Twilio Lookup | Twilio | $0.008/req ($0.00385 volume) |
line_type_intelligence.type: landline, mobile, fixedVoip, nonFixedVoip, personal, tollFree, premium, unknown
|
Industry standard; real-time NPAC; Stripe and Vercel use this |
| Telnyx Number Lookup | Telnyx | Pay-as-you-go; free tier |
carrier.type: voip, mobile, landline + OCN, SPID, LRN, ported_status |
Exposes raw OCN/SPID data; good for debugging |
| IPQS Phone Validation | IPQualityScore | Free tier + volume |
VOIP (boolean) + line_type: mobile, landline, VoIP, prepaid + fraud_score (0–100) |
Includes fraud scoring; claims 99%+ accuracy |
| Vonage Number Insight | Vonage (Ericsson) | Tiered: Basic/Standard/Advanced |
network_type: mobile, landline, virtual, unknown, pager
|
"Virtual" maps to VoIP; Vonage uses it to block VoIP on their own platform |
| Abstract Phone Validation | AbstractAPI | Free 250/mo → tiered paid |
phone_carrier.line_type: Wireless, Landline, VOIP + is_voip boolean |
Good free tier; 190+ countries |
| Numverify | apilayer | Free 100/mo → $9.99–$99.99/mo |
line_type: mobile, landline, special_services
|
No dedicated VoIP type; limited granularity |
| Ekata Phone Intelligence | Ekata (Mastercard) | Enterprise/custom | Carrier info, prepaid check, validity, velocity | 200M+ monthly queries; enterprise fraud context |
| Telesign Phone ID | Telesign (TransUnion) | Pay-as-you-go; free trial |
phone_type: landline, mobile, VoIP + carrier name, registration status |
TransUnion identity network; banks and fintech use this |
Code Example: Running Your Own Carrier Lookup
Before building anything, verify how your number is classified. Here's how to query Twilio's API directly:
from twilio.rest import Client
client = Client(account_sid, auth_token)
phone_number = client.lookups.v2.phone_numbers("+14155551234").fetch(
fields="line_type_intelligence"
)
lti = phone_number.line_type_intelligence
print(f"Line type: {lti['type']}") # e.g., "nonFixedVoip"
print(f"Mobile country code: {lti.get('mobile_country_code')}")
print(f"Mobile network code: {lti.get('mobile_network_code')}")
print(f"Error code: {lti.get('error_code')}")
import twilio from "twilio";
const client = twilio(accountSid, authToken);
const number = await client.lookups.v2
.phoneNumbers("+14155551234")
.fetch({ fields: "line_type_intelligence" });
const lti = number.lineTypeIntelligence;
console.log(`Line type: ${lti?.type}`); // e.g., "nonFixedVoip"
console.log(`MCC: ${lti?.mobileCountryCode}`);
console.log(`MNC: ${lti?.mobileNetworkCode}`);
Run this on any number you plan to use with your agent. If you see nonFixedVoip or fixedVoip, that number will fail verification on Stripe, Google, WhatsApp, and most financial services.
Why Every Major Service Blocks VoIP: Service-by-Service Breakdown
Stripe
Stripe's phone verification runs during identity verification (Stripe Identity), account security setup, and certain high-risk payment flows. The technical mechanism combines:
- Carrier lookup (Twilio Line Type Intelligence or equivalent)
- Rejection if
line_type_intelligence.typeisfixedVoipornonFixedVoip - Additional risk scoring: velocity checks, geographic mismatch between IP and carrier region, and number reputation
The error is explicit: "This phone number cannot be used for verification."
There's no workaround via retry or different country codes. The check is at the carrier level, not the number level. Using a different Twilio number won't help — all Twilio programmable numbers share the same OCN (Bandwidth, BW Communications, or similar CLEC/VoIP providers), and those OCNs are classified as VoIP.
Google's blocking is more nuanced and less consistent than Stripe's, which makes it harder to debug. The mechanisms include:
Line-type checking at account creation. New Google account registrations check carrier type. Numbers classified as nonFixedVoip fail with "Something went wrong" or "This number cannot be used for verification."
Carrier range blacklisting. Google maintains its own reputation database of carrier OCN ranges with abuse history. Even mobile numbers from certain prepaid carriers or MVNOs with high abuse rates get blocked.
eSIM complications. A March 2026 Reddit thread in r/GMail documented widespread blocking of Philippine eSIM numbers despite them technically registering as mobile. Google appears to apply additional geographic and carrier-origin checks beyond the basic line-type lookup.
Amazon OTPs stopped routing to Google Voice. As documented in Google Support forum posts from May 2024: "Amazon will no longer send OTP codes to Google Voice numbers." This means Amazon specifically targeted the Google Voice OCN range for SMS filtering.
Amazon
Amazon's blocking operates at the SMS routing layer through AWS SNS (Simple Notification Service), which Amazon uses to send OTP codes for its verification flows.
The mechanism is carrier-type filtering: SNS checks the carrier type of the destination number before routing. If the number is VoIP, the message is silently dropped. No error is returned to the sender, and no code arrives for the recipient.
For AI agents, this is the worst type of failure: the agent triggers the verification request, receives a success response from the API call, then waits indefinitely for a code that was discarded before it left Amazon's infrastructure.
WhatsApp's policy is explicit and documented. From their official FAQ:
"Unsupported phone numbers, such as VoIP, landlines, and premium rate numbers, are not eligible for registration on WhatsApp."
The technical check happens at WhatsApp account registration. The carrier lookup is performed before the verification SMS is sent. VoIP numbers receive an immediate rejection error.
WhatsApp also blocks verification via short-code SMS to VoIP numbers as a secondary mechanism — even if a VoIP number somehow passed the initial registration check, the short-code routing would filter it.
Microsoft Entra ID (Azure AD MFA)
Microsoft's multi-factor authentication blocks VoIP via error code 399287, classified as "BadReputation" in their carrier reputation database.
Microsoft Learn documentation (updated March 2026) is direct:
"Phone extensions and VOIP numbers are not supported for MFA."
Microsoft applies per-number reputation tracking, not just per-OCN classification. A number that passes carrier lookup as "mobile" but has been associated with fraud attempts on other Microsoft accounts may still receive a BadReputation score.
Vercel and DocuSign
Both Vercel and DocuSign use Twilio Lookup's Line Type Intelligence directly in their onboarding flows. The code path is approximately:
register(phone) → lookup(phone).line_type_intelligence →
if type in ["nonFixedVoip", "fixedVoip"] → reject("Invalid phone number")
Banks and Financial Institutions
Banks present a more heterogeneous blocking landscape because each institution implements its own carrier check. The patterns are:
Silent blocking: The verification SMS is simply never sent. The bank's UI shows a spinner and eventually times out. No error message indicates the phone type issue.
Misleading errors: BMO's documented case (Reddit r/PersonalFinanceCanada, February 2026): "BMO seems to have blocked 2FA verification from a landline VoIP number." The user received a generic error that didn't indicate the carrier type issue.
Post-enrollment blocking: Some banks validate at SMS routing time rather than at enrollment. This means an agent may successfully register a VoIP number, only to find that OTP codes are never delivered at login time.
Technical Alternatives: What Actually Works
1. Physical SIM Cards
How it works: Physical SIM cards inserted in modems or smartphones. AT&T, Verizon, T-Mobile SIM cards register the OCN in LERG as WIRELESS. HLR lookups succeed. Carrier lookup returns mobile across all APIs.
Classification result: Mobile on 100% of carrier lookup APIs. Passes all verification services.
Problems for agents: Requires physical hardware, $50–$80/month per number, no programmatic provisioning API, scale limited by hardware.
2. eSIM (Embedded SIM)
How it works: eSIM profiles provisioned remotely via the SM-DP+ protocol. Connects to the carrier's mobile network exactly like a physical SIM.
Classification result: Functionally identical to physical SIM for LERG/NPAC classification.
Problems for agents: Google has documented blocking eSIM numbers from certain carriers. Not all carriers support programmatic eSIM provisioning.
3. MVNO Numbers
How it works: MVNOs (Mint Mobile, Google Fi, Tracfone) lease network capacity from MNOs. Numbers registered on LERG as WIRELESS.
Classification result: Generally classified as mobile.
Problems for agents: Some MVNO OCN ranges are specifically blacklisted by high-fraud services. No programmatic provisioning API.
4. Number Porting (VoIP to Mobile)
How it works: Under FCC LNP rules, any US number can be ported from one carrier to another. Porting a VoIP number to a mobile carrier reclassifies it in NPAC.
Classification result: The number becomes mobile permanently.
Problems for agents: Takes hours to days. One-time operation per number. Not suitable for dynamic provisioning at scale.
5. Silent Network Authentication (SNA)
How it works: Carrier-level authentication that verifies phone number ownership using the SIM's authenticated data session — invisible in 1–4 seconds.
Classification result: Requires a real mobile SIM. Cannot be spoofed by VoIP.
Problems for agents: Requires mobile data (not Wi-Fi). Not universally supported yet. Only an authentication mechanism, not provisioning.
6. Real SIM Number APIs (The Programmatic Solution)
How it works: Services like AgentSIM operate physical SIM cards in carrier-connected modems, and expose those numbers via API. Provision a number, receive an OTP via API webhook or long-poll, release when done.
Classification result: mobile on all carrier lookup APIs. Passes Stripe, Google, Amazon, WhatsApp, Microsoft Entra, and bank verifications.
AgentSIM: Real Mobile Numbers via API
AgentSIM is built specifically for this use case. Every provisioned number is backed by a physical SIM on a US carrier network. Carrier lookup returns mobile.
Python: Complete OTP Flow
import agentsim
client = agentsim.AgentSimClient()
# 1. Provision a real mobile number
session = await client.provision(agent_id="stripe-onboarding", country="US")
print(f"Phone number: {session.number}")
# e.g. +14085551234 — carrier lookup returns "mobile"
# 2. Enter session.number into the service that will send the OTP
# 3. Wait for the OTP (blocks until received, up to 60s)
try:
result = await session.wait_for_otp(timeout=60)
print(f"OTP code: {result.otp_code}")
except agentsim.OtpTimeoutError:
print("Timeout — retry with new number")
finally:
# 4. Always release the number when done
await session.release()
TypeScript: Complete OTP Flow
import { provision, OtpTimeoutError, PoolExhaustedError } from "@agentsim/sdk";
async function verifyWithStripe() {
// await using releases the number automatically on exit (TypeScript 5.2+)
await using session = await provision({
agentId: "stripe-onboarding",
country: "US",
ttlSeconds: 300,
});
console.log(`Phone number: ${session.number}`);
// e.g. +14085551234 — carrier lookup returns "mobile"
try {
const otp = await session.waitForOtp({ timeout: 60 });
console.log(`OTP: ${otp.otpCode}`);
return otp.otpCode;
} catch (err) {
if (err instanceof OtpTimeoutError) {
console.log("No OTP in 60s — carrier retry may be needed");
} else if (err instanceof PoolExhaustedError) {
console.log("No US numbers available");
} else {
throw err;
}
}
}
MCP Integration
If you're using Claude Code, Cursor, or any MCP-compatible assistant:
{
"mcpServers": {
"agentsim": {
"type": "streamable-http",
"url": "https://mcp.agentsim.dev/mcp",
"headers": {
"x-api-key": "asm_live_..."
}
}
}
}
Once configured, your assistant can call provision_number, wait_for_otp, and release_number autonomously — no human intervention required.
Implementation Guide: Verifying Numbers Before Use
Python: Check Number Type Before Sending OTP
from twilio.rest import Client
def get_line_type(phone_number: str, account_sid: str, auth_token: str) -> str:
client = Client(account_sid, auth_token)
number = client.lookups.v2.phone_numbers(phone_number).fetch(
fields="line_type_intelligence"
)
lti = number.line_type_intelligence
return lti.get("type", "unknown") if lti else "unknown"
def is_mobile(phone_number: str, account_sid: str, auth_token: str) -> bool:
return get_line_type(phone_number, account_sid, auth_token) == "mobile"
TypeScript: Check Number Type
import Telnyx from "telnyx";
async function getLineType(phoneNumber: string) {
const telnyx = new Telnyx(process.env.TELNYX_API_KEY!);
const result = await telnyx.numberLookup.retrieve(phoneNumber, { type: "carrier" });
const carrier = result.data?.carrier;
return {
type: carrier?.type ?? "unknown",
carrier: carrier?.name,
portedStatus: carrier?.ported_status,
};
}
Frequently Asked Questions
Q: Does this affect Twilio numbers specifically, or all VoIP?
All VoIP numbers are affected, not just Twilio. Twilio programmable numbers are classified nonFixedVoip because Twilio's OCN is classified as a VoIP/CLEC provider in LERG. The same applies to Telnyx, Bandwidth, Vonage, Plivo, Sinch, and every other CPaaS provider's programmable numbers.
Q: My Twilio number worked on Google last year. Why is it failing now?
VoIP blocking has been tightening progressively. A number or OCN range that was tolerated in 2023 may now be explicitly blocked. Google in particular has been documented increasing eSIM and VoIP restrictions in early 2026.
Q: What about prepaid mobile numbers? Do they pass?
Prepaid mobile numbers from major carriers (AT&T Prepaid, T-Mobile Prepaid, Verizon Prepaid) pass carrier lookup as mobile. However, fraud-sensitive services apply additional velocity and reputation scoring.
Q: Can I port my existing Twilio number to a mobile carrier?
Yes, in principle. After porting, NPAC updates the SPID and the number is reclassified as mobile. This is a one-time operation — not suitable for dynamic number provisioning.
Q: Will this change as AI agent use cases grow?
The direction is toward stricter verification, not looser. Silent Network Authentication (SNA) is emerging as a more secure alternative — it requires a real SIM and mobile data, making it impossible to fake with VoIP.
Q: What about international numbers?
VoIP blocking is primarily a US/Canada phenomenon due to the specific LERG/NPAC infrastructure. AgentSIM currently supports US numbers.
Summary
The VoIP blocking problem is structural, not accidental. Services block VoIP numbers because the LERG/NPAC/OCN infrastructure exposes carrier type reliably, VoIP numbers have statistically higher fraud rates, and blocking is technically trivial once carrier lookups are already running.
For AI agents that need SMS verification to pass Stripe, Google, WhatsApp, Amazon, Microsoft, or financial institutions, the only path forward is a number that carrier lookup APIs classify as mobile.
- Documentation: docs.agentsim.dev
-
MCP server:
mcp.agentsim.dev/mcp - Get an API key: console.agentsim.dev
Top comments (0)