Can a virtual number receive SMS? Verification codes and business use

Yes, a virtual number can receive SMS. A business line from a texting platform, a cloud phone system or a CPaaS will accept replies from customers, keyword opt-ins and normal two-way conversation without any trouble. Verification codes are different. Many banks, payment apps, social networks and marketplaces deliberately refuse to send one-time passcodes (OTPs) to numbers they classify as VoIP or "non-fixed." Those numbers technically can receive the text. The sender has decided not to send it.

This post explains what a virtual number reliably receives and why verification services block them. It also covers the compliant setup if your real goal is to send verification codes to your own users rather than receive them.

What counts as a virtual number

"Virtual number" covers any phone number that isn't tied to a SIM card in a physical handset. Common types:

• 10DLC numbers: standard 10-digit local numbers registered for business texting (A2P 10DLC). This is what most business texting platforms, including Ready, hand out. Our 10DLC explainer covers the registration side.
• Toll-free numbers: 8XX numbers enabled for SMS, with their own verification process.
• Consumer VoIP apps: Google Voice, TextNow and similar. These are personal-use products, and their limits for business are well documented. See Google Voice for business texting.
• "Receive SMS online" sites: public pages showing texts sent to shared numbers. Anyone can read them. Never use one for anything you care about.

The carrier databases that verification services query usually tag all of these as something other than a mobile line, and that tag is what triggers the blocking.

What a virtual number receives fine

For normal business messaging, a properly registered virtual number works like any other phone line:

1. Customer replies. Someone answers your appointment reminder with "Can we do 3 PM instead?" and the reply lands in your inbox.
2. Inbound first contact. A customer texts the number on your website or truck.
3. Keyword opt-ins and opt-outs. "JOIN", "STOP", "HELP". On Ready, STOP and UNSUBSCRIBE are honored automatically, and the opt-out applies across every campaign so that contact can't be texted again.
4. Person-to-person texts from other businesses' 10DLC numbers. Ordinary A2P traffic generally reaches other 10DLC numbers.

On Ready, inbound replies land in the Inbox, and in GoHighLevel for connected accounts. A received reply is billed like a sent text: $0.0075 per segment plus a $0.0045 carrier fee. Budget for it if you expect a chatty audience.

Why verification codes often don't arrive

Here is what usually happens when you try to use a virtual number as the phone on, say, a bank or social account.

The sender checks line type first

Before sending an OTP, many services run a line-type lookup on the number you entered. If it comes back as VoIP, landline or "non-fixed VoIP," the form either rejects the number outright ("please use a mobile number") or accepts it and quietly never sends the code. They do this because virtual numbers are cheap to get in bulk, and fraud teams associate them with fake account creation. Blocking them is a crude filter, but it's common.

Short codes don't always route to virtual numbers

Many large senders deliver OTPs from short codes (5 or 6 digit numbers). Short-code delivery to VoIP and 10DLC numbers is inconsistent across the industry. Some carriers and providers pass it through. Others don't. Even when a service doesn't block you on purpose, the code can still fail to arrive.

Policy, not just plumbing

Even where it works technically, using a shared or bulk-acquired virtual number to get around a platform's phone verification usually violates that platform's terms. It can also violate your texting provider's acceptable use policy. We don't recommend it, and we don't support it as a use case.

The practical rule: for accounts that matter (banking, payroll, your domain registrar, the admin login for your own SaaS), use a real mobile number on a SIM you control, or an authenticator app. Don't make a business texting line the recovery phone for anything you'd be locked out of if a code stopped arriving.

Quick reference: what to expect

The compliant alternative: send codes, don't borrow numbers

Most buyers searching this topic fall into one of two groups. One group wants to receive codes, and for them the answer is above: use a real mobile. The other group runs a product and needs to send verification codes to their own users. That second problem has a clean, compliant answer.

Register the traffic

Carriers filter unregistered A2P traffic, and OTP traffic depends on every message arriving. Register a brand and a campaign with a two-factor or account-notification use case. On Ready this happens in-app. Brand registration is $10/mo, a campaign is $20/mo, and each number is $2/mo. There's no setup fee: the charge at submit is the first month, $25, and most approvals take 2 to 7 days. An account can send up to 500 texts a month before it registers, at the normal per-text rate. Use the first 20 free one-to-one texts to test your message before you pay for registration, because the free texts end when registration is paid.

Our posts on SMS OTP and verification APIs and OTP sender setup and deliverability go deeper on fallbacks and throughput.

Send through the API

A single OTP is one request (full reference at docs.tryready.com/api/messages):

POST https://api.tryready.com/v1/messages
X-API-Key: <your key>
Idempotency-Key: 7b1c2e4a-9f3d-4c1e-8a2b-5d6e7f8a9b0c

{"to": "+12125550199", "body": "Your Acme code is 482913. It expires in 10 minutes.", "consent_attested": true}

Send the Idempotency-Key on every OTP. If your server retries after a timeout, the user doesn't get two different codes and you don't pay twice. consent_attested is your statement that the recipient agreed to receive texts. A user who just typed their number into your login form and clicked "send code" has asked for that message. If your platform texts on behalf of its own customers, each customer can get its own sub-account with its own numbers and registration. The sub-accounts docs cover that setup.

Keep codes to one segment

The example message above is about 52 GSM-7 characters, so it fits in one segment. Add an emoji and the per-segment limit drops to 70 characters, which is an easy way to push a longer code message into two segments.

Worked example (assumptions: 10,000 OTPs a month, one segment each, Standard rate, no scrub or landline validation switched on):

• Messages: 10,000 × $0.0075 = $75
• Carrier fee: 10,000 × $0.0045
• Registration: $25/mo for registration and $2/mo per number

Users don't reply to OTPs, so there's little inbound cost. If they did reply, those replies would be billed at the same rate.

Where Ready is not the obvious pick

If all you need is high-volume OTP and nothing else, a raw CPaaS is reasonable. Twilio lists about $0.0083 per segment, which is below our Standard rate. Ready makes sense when the same platform also needs two-way conversations, sub-accounts for your customers, opt-out handling, quiet-hours enforcement and DNC scrubbing in one API. We cover that tradeoff in Ready vs Twilio.

The takeaway

A virtual number is a solid way to have conversations by text. It receives replies, inbound messages and opt-ins without fuss. It's a poor way to receive verification codes, because many senders block VoIP numbers on purpose and short-code routing to them is unreliable. Use a real mobile or an authenticator app for your own logins. If you need to send codes to your users, register the traffic, keep messages to one segment and send with an idempotency key.

If that second case fits what you're building, the pricing page shows the Standard rate, and you can create an account to try the API with your first 20 one-to-one texts.