DEV Community: Serhat Doğan

The Refund State Machine That Saved Our SMS Reseller from Bleeding Money

Serhat Doğan — Mon, 06 Apr 2026 10:45:45 +0000

Every SMS verification reseller eventually hits the same wall: codes don't always arrive. In our production data over the last six months, the failure rate has been remarkably stable around 28-32% depending on country and service. Telegram in Indonesia is closer to 40%. WhatsApp in the US is closer to 18%.

The naive refund flow looks like this:

User buys number → Wait 20 minutes → No code arrived → Refund user

This is what we shipped in v1. It cost us roughly $400 per week in losses before we caught it. Here's what was happening, what we built to fix it, and the Postgres patterns that made the new flow safe.

The bug

The failure mode wasn't subtle once we instrumented it: we were refunding users even when the upstream provider had charged us and not refunded us back. Both providers we use (HeroSMS and 5SIM) have their own internal refund logic — sometimes they refund automatically when no code arrives within their SLA, sometimes they don't, sometimes they do but ~30 minutes later.

Our v1 logic just checked our own clock: 20 minutes after purchase, if status was still "WAITING" in our DB, we'd refund the user. That meant:

Provider eventually refunds us: we got our money back later, fine, no net loss
Provider does NOT refund us: we ate the cost of the number, lost it from our margin
Provider refunds us LATE, after we already refunded the user: double-refund detected on reconciliation, manual cleanup
Code arrives at minute 21: user already refunded, code is now wasted

The first failure mode was the killer. We were refunding 30% of activations, but only ~70% of those resulted in a corresponding provider refund. So we were losing the cost of ~9% of all activations on top of the markup we'd already given back.

With ~50,000 activations a month, that's a meaningful number.

The state machine

The fix was to make every activation live in exactly one of these states, with explicit transitions:

            ┌─────────────────┐
            │   PURCHASED     │  ◄── initial, provider returned an activation ID
            └────────┬────────┘
                     │
            ┌────────▼────────┐
            │    WAITING      │  ◄── polling or webhook for code
            └────┬───────┬────┘
                 │       │
         received│       │timeout (20m) OR cancelled
                 │       │
            ┌────▼──┐ ┌──▼──────────────┐
            │RECEIVED│ │     EXPIRED     │
            └────┬──┘ └────────┬────────┘
                 │             │
         ┌───────▼──┐ ┌────────▼────────────────┐
         │COMPLETED │ │PROVIDER_REFUND_PENDING  │  ◄── waiting on provider refund
         └──────────┘ └───────┬─────────────────┘
                              │
                      ┌───────▼───────┐
                      │   REFUNDED    │  ◄── user gets credit back, only after provider confirms
                      └───────────────┘

Key rules:

Never refund the user before PROVIDER_REFUND_PENDING → REFUNDED transition.
Every state transition is an atomic Postgres UPDATE with a WHERE status = expected_previous. No race conditions.
The provider refund check is a balance delta, not a status field. We track provider balance every minute, and when the balance goes up after an EXPIRED activation, we tag that delta to the activation and only then refund the user.

The Postgres part

The table:

CREATE TABLE activations (
  id              bigint PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
  user_id         uuid NOT NULL REFERENCES users(id),
  provider        text NOT NULL CHECK (provider IN ('herosms', '5sim')),
  provider_activation_id  text NOT NULL,
  service         text NOT NULL,
  country         text NOT NULL,
  cost_charged    numeric(10,4) NOT NULL,
  status          text NOT NULL CHECK (status IN (
    'PURCHASED', 'WAITING', 'RECEIVED', 'COMPLETED',
    'EXPIRED', 'PROVIDER_REFUND_PENDING', 'REFUNDED', 'CANCELLED'
  )),
  status_updated_at  timestamptz NOT NULL DEFAULT now(),
  created_at         timestamptz NOT NULL DEFAULT now(),
  expires_at         timestamptz NOT NULL,
  refund_provider_balance_delta_id  bigint REFERENCES provider_balance_deltas(id),
  UNIQUE (provider, provider_activation_id)
);

CREATE INDEX idx_activations_status_expires ON activations (status, expires_at)
  WHERE status IN ('WAITING', 'PROVIDER_REFUND_PENDING');

The partial index is the workhorse. We have hundreds of thousands of activations in this table, but only the ones in WAITING or PROVIDER_REFUND_PENDING need to be scanned by the cron. The partial index makes that scan O(active rows), not O(total rows).

The atomic transition function:

CREATE OR REPLACE FUNCTION transition_activation_status(
  p_activation_id  bigint,
  p_from_status    text,
  p_to_status      text
) RETURNS boolean AS $$
DECLARE
  v_updated int;
BEGIN
  UPDATE activations
  SET status = p_to_status,
      status_updated_at = now()
  WHERE id = p_activation_id
    AND status = p_from_status;

  GET DIAGNOSTICS v_updated = ROW_COUNT;
  RETURN v_updated = 1;
END;
$$ LANGUAGE plpgsql;

The WHERE status = p_from_status is the atomic guard. If two crons race to transition the same activation, only one wins, the other returns false. No locks needed, no advisory locks, no redis. Just Postgres row-level MVCC.

The cron that scans for expired activations:

-- Run every 60 seconds
WITH expired AS (
  SELECT id, provider, provider_activation_id, cost_charged
  FROM activations
  WHERE status = 'WAITING'
    AND expires_at < now()
  FOR UPDATE SKIP LOCKED
  LIMIT 100
)
UPDATE activations
SET status = 'EXPIRED',
    status_updated_at = now()
FROM expired
WHERE activations.id = expired.id
RETURNING activations.id, activations.provider, activations.provider_activation_id;

FOR UPDATE SKIP LOCKED is critical. It means multiple cron workers can run in parallel and won't block each other — they'll just claim different rows. We run two workers in different regions for redundancy.

The provider balance reconciliation

This is the part that makes the whole thing work. Every 60 seconds we ping each provider's getBalance endpoint and store the delta:

CREATE TABLE provider_balance_deltas (
  id              bigint PRIMARY KEY GENERATED ALWAYS AS IDENTITY,
  provider        text NOT NULL,
  balance_before  numeric(12,4) NOT NULL,
  balance_after   numeric(12,4) NOT NULL,
  delta           numeric(12,4) NOT NULL,
  observed_at     timestamptz NOT NULL DEFAULT now()
);

When delta > 0 (provider gave us money back), we look at activations in EXPIRED state for that provider where the cost matches the delta within a tolerance, and tag them:

UPDATE activations
SET status = 'PROVIDER_REFUND_PENDING',
    refund_provider_balance_delta_id = $1
WHERE id = (
  SELECT id FROM activations
  WHERE provider = $2
    AND status = 'EXPIRED'
    AND ABS(cost_charged - $3) < 0.001
  ORDER BY status_updated_at ASC
  LIMIT 1
);

Then a final cron transitions PROVIDER_REFUND_PENDING → REFUNDED and credits the user wallet in the same transaction.

The key insight: the provider's refund and the user's refund are now linked by a real cash flow, not by hope. If the provider doesn't refund, the user doesn't get refunded. We eat the loss explicitly and visibly, instead of bleeding it silently.

What this changed

Refund-related losses dropped ~80% on the first deploy.
User complaints about double-refunds went to zero because we no longer race the provider.
Reconciliation became boring, which is the highest praise reconciliation can get.
Support load dropped because the rare "my code arrived after I was refunded" complaints went away — we now hold the refund until after the timeout AND the provider has confirmed.

What I'd do differently

I'd build the state machine on day one. We retrofitted it on top of v1 and it was painful.
I'd use a real provider webhook listener for the WAITING → RECEIVED transition, not just polling. We have webhooks now but they came late.
I'd tolerance-match on provider balance deltas more carefully. Our first version was too strict and missed legitimate refunds. Now we use a 0.1% tolerance and a time window.
I'd add a RECONCILIATION_FAILED state for the cases where the provider balance came back but didn't match any expired activation. Those go to an admin queue.

Why share this

If you're building anything that resells a paid upstream service — SMS, voice, virtual cards, pay-per-call — this pattern probably applies. The naive refund flow looks fine in dev and bleeds cash in prod. The state machine is not glamorous but it pays for itself in the first month.

For what it's worth, VerifySMS runs on this exact pattern in production today across HeroSMS and 5SIM, on Supabase Edge Functions and Postgres. If you want to see the user-facing side — instant virtual numbers, automatic refunds, no KYC — we're on the App Store and the web.

Questions about the state machine, the balance reconciliation, or the partial index strategy — ask in the comments.

Building a Privacy-First Phone Verification Architecture: Lessons from 6 Months in Production

Serhat Doğan — Mon, 06 Apr 2026 10:02:03 +0000

When we started building VerifySMS in late 2025, the SMS verification reseller market was a graveyard. SMS-Activate had just shut down. Half the surviving providers were running on PHP 5.6 with hardcoded IPs. The 'modern' alternatives were Telegram bots that took your USDT and disappeared.

We wanted something different: an iOS-first, edge-deployed verification service that respected privacy by design — no KYC, no stored numbers, automatic refunds when codes never arrived. Six months and ~50,000 activations later, here's what we learned about building it.

The architecture in one diagram

  iOS app  ──┐
             ├──► Cloudflare Edge ──► Supabase Edge Functions ──┬──► HeroSMS API
  Web app  ──┘                                                  └──► 5SIM API
                                                                       │
                                                                       ▼
                                                              Webhook listener
                                                                       │
                                                                       ▼
                                                                  Postgres + RLS

Four pieces matter: the edge router, the dual-provider abstraction, the refund state machine, and the secret boundary. Everything else is plumbing.

1. The dual-provider abstraction

Never trust one SMS provider. Ever. Their uptime claims are fiction, their API stability is worse, and the moment a high-value campaign needs Telegram numbers in Macedonia, every provider mysteriously runs out.

We wrap two providers (HeroSMS, 5SIM) behind a single interface. Each request specifies a service+country+price target and the router picks based on three signals:

Recent success rate for that exact (service, country) pair, not the global rate
Cost including the markup we apply
Inventory — both providers expose count endpoints we poll every 60s

The interface is intentionally minimal:

interface SmsProvider {
  getCountries(service: string): Promise<Country[]>
  getPrice(service: string, country: string): Promise<Price | null>
  purchaseNumber(service: string, country: string): Promise<Activation>
  getStatus(activationId: string): Promise<ActivationStatus>
  cancelActivation(activationId: string): Promise<void>
}

The hard part isn't the interface — it's the response normalization. HeroSMS returns activation IDs as strings, 5SIM as integers. HeroSMS lets you cancel within 2 minutes, 5SIM cancels instantly. HeroSMS supports operator selection only in UA/KZ, 5SIM in 50+ countries. Every quirk goes into the adapter, never bleeds into the router.

Lesson learned: Don't try to map provider-specific status codes to a unified enum on day one. Just store both the raw provider status and your interpretation. The week we did this saved us a month later when 5SIM silently changed status STATUS_OK from meaning 'code received' to 'number purchased.'

2. The refund state machine

This is the part everyone gets wrong. SMS providers charge you when you reserve a number, not when the user actually receives a code. If the code never arrives — and it doesn't, ~30% of the time — you've already paid the provider.

The naive answer: refund the user, eat the loss, hope it averages out. It doesn't. You bleed money.

The better answer: a state machine.

  PURCHASED ──► WAITING ──► RECEIVED ──► COMPLETED
      │            │
      │            ▼
      │        EXPIRED ──► PROVIDER_REFUND_PENDING ──► REFUNDED
      │
      ▼
   CANCELLED

Every activation lives in exactly one state at a time. Transitions are atomic Postgres updates with WHERE status = expected_previous_status. The cron that scans for expired activations only refunds users when the provider has confirmed the refund on their side — we check the provider balance delta, we don't trust their status field alone.

This cut our refund-related losses by ~80%. The remaining 20% are real provider failures that we eat, and that's fine — the unit economics still work because of #3.

3. The secret boundary

The iOS app never sees an API key for HeroSMS, 5SIM, or even Supabase service-role. The web app doesn't either. Both clients only ever talk to Supabase Edge Functions, and Edge Functions are the only thing holding live secrets.

Why this matters: the moment a client app holds a provider key, your unit economics are at the mercy of whoever IPA-decrypts your binary. We ran this experiment with a competitor's iOS app (with their permission) and pulled their HeroSMS key from the strings table in 90 seconds.

The boundary looks like:

Client → Edge Function: anon JWT, RLS-enforced row access
Edge Function → Provider API: service-role secret, never logged
Edge Function → DB: service-role JWT, RLS bypassed only for the specific table the function owns

One caveat: Supabase deploys Edge Functions with verify_jwt=true by default, which silently enables JWT verification on functions you may have intended to be public (like a get-services listing endpoint). Every deploy script must PATCH the function metadata to set verify_jwt=false for the explicitly public ones. We learned this when our pricing page returned 401s for two days and nobody noticed because the iOS app cached the previous response.

4. The edge cache

Users hit the pricing page hundreds of times per second. The provider APIs absolutely cannot handle this — HeroSMS returns 503 if you exceed ~5 req/s.

Cloudflare Workers + KV solves this beautifully. Every 60 seconds, a single cron-driven Worker fetches the full price matrix from both providers, normalizes it, and writes it to KV. Every client request reads from KV — single-digit-millisecond latency, zero load on the provider APIs.

The trick: store the full price matrix as one KV entry, not per-(service, country). Per-pair entries seemed cleaner but blew through KV read budget in two weeks. One JSON blob, ~80KB gzipped, refreshed atomically. KV fan-out handles the read load globally.

What we got wrong

Started with one provider. Spent two months migrating to a dual-provider architecture after the first provider had a 6-hour outage during a paid ad push.
Used global success rates for routing. The (service, country) pair matters more than you think — Telegram in Indonesia might be 95% on Provider A and 12% on Provider B, and the global average tells you nothing.
Tried to localize prices client-side. Don't. Localize at the edge with the user's IP-derived currency, cache the converted price, and ship it. Client-side conversion fights the cache and breaks every time a currency rate moves.
Trusted webhook delivery. Both providers offer webhooks. Both providers drop ~2% of webhooks under load. Always poll status as a fallback, even if you also have a webhook listener.
Built a custom rate limiter. Rewrote it three times before giving in and using Cloudflare's Turnstile + native rate limiting rules.

What we got right

iOS-first. The web app exists for SEO and Stripe payments, but 80%+ of revenue comes from iOS. Users want a real app, not a website wrapped in a WebView.
Dual provider from the start of v2. Worth every hour of refactor pain.
Refund state machine. Single biggest unit-economics improvement we shipped.
No KYC. Some markets we can't serve because of compliance, and that's fine. The rest love us for not asking for a passport scan.

Why share this

We got asked in a private Slack last week how we built it, and the answer was too long for a DM. If you're building anything in this space — even an internal tool for your own product's signup flow — these patterns will save you months.

And if you just need a virtual number to verify a Discord account without handing your real number to Discord's data brokers, VerifySMS is on the App Store and the web. We don't store your real number, we don't ask for ID, and if the code doesn't arrive your money comes back automatically.

Questions about any of this — the state machine, the edge cache strategy, the provider-specific quirks — ask in the comments and I'll dig into specifics.

I Analyzed 10,000 SMS Verifications Across 50 Countries — Here's What the Data Shows

Serhat Doğan — Sat, 04 Apr 2026 20:44:08 +0000

Every month, millions of people need to verify accounts with a phone number they don't want to share. I analyzed our verification data across 50 countries to find patterns most people miss.

The Dataset

Over 90 days, we tracked:

10,247 verification attempts across 50 countries
43 different services (WhatsApp, Telegram, Instagram, Discord, etc.)
Success rates, delivery times, and cost per verification
Provider reliability by country and time of day

Finding #1: Country Choice Matters More Than Provider

Most guides tell you to pick the cheapest provider. Our data says pick the right country first.

Country	Avg Success Rate	Avg Cost	Avg Delivery Time
🇺🇸 USA	72%	$0.80	28s
🇬🇧 UK	78%	$0.60	22s
🇮🇩 Indonesia	85%	$0.15	18s
🇮🇳 India	68%	$0.12	35s
🇷🇺 Russia	82%	$0.20	15s
🇧🇷 Brazil	71%	$0.25	31s
🇩🇪 Germany	76%	$0.90	24s
🇵🇭 Philippines	88%	$0.10	12s

For more country-specific data, see our full cheapest virtual phone numbers by country breakdown.

Key insight: Philippines and Indonesia have the highest success rates AND lowest prices. Western countries cost 4-8x more with lower success rates.

Finding #2: Time of Day Changes Everything

We found a 23% variance in success rates based on when you verify:

Success Rate by Hour (UTC)

90% |          ████
85% |      ████    ████
80% |  ████            ████
75% |██                    ████
70% |                          ██
    └──────────────────────────────
     0  4  8  12  16  20  24

Best window: 08:00-14:00 UTC (morning in Asia, business hours in Europe)
Worst window: 22:00-04:00 UTC (overnight maintenance, carrier throttling)

Finding #3: Service Difficulty Tier List

Not all services verify equally. If you're struggling with a specific platform, check our dedicated guides:

Easy Tier (80%+ success)

Telegram — consistently highest success
Discord — low VoIP detection
TikTok — accepts most number types
LINE

Medium Tier (60-80% success)

WhatsApp — moderate VoIP detection
Instagram — inconsistent
Facebook — varies by region
Steam

Hard Tier (<60% success)

Google — aggressive VoIP detection
PayPal — carrier whitelist
Banking apps — regulatory requirements

Finding #4: The Auto-Refund Factor

This is the metric nobody talks about. If a service doesn't auto-refund failed verifications, your real cost is:

Real Cost = Listed Price ÷ Success Rate

A $0.15 number with 60% success actually costs $0.25. A $0.30 number with 90% success and auto-refund costs exactly $0.30.

We did a deep comparison of free vs paid virtual phone numbers — spoiler: free ones have ~3% success rate.

Finding #5: Multi-Provider Routing

Services using multiple upstream providers show 12% higher success rates than single-provider services. The routing logic matters:

Check provider inventory for the requested country + service
Sort by historical success rate (not just price)
Fallback to secondary provider if primary fails
Auto-refund on timeout

If you want to understand the technical architecture behind SMS verification, check out how SMS verification actually works.

Practical Takeaways

Choose Indonesia or Philippines for budget verifications
Verify during business hours (08:00-14:00 UTC)
Check for auto-refund — it changes the economics completely
Expect Google/PayPal to be hard — budget more attempts
Multi-provider services are worth the premium

Want to Try It?

VerifySMS uses the multi-provider routing described above across 150+ countries. The complete guide to getting a virtual phone number walks you through the process.

For the best deals, check which countries offer the cheapest virtual numbers.

This analysis is based on aggregated, anonymized data from VerifySMS — virtual phone numbers for SMS verification in 150+ countries. Download on the App Store.

I Tested 8 SMS Verification Services After SMS-Activate Shut Down — Honest Results

Serhat Doğan — Thu, 02 Apr 2026 00:28:59 +0000

When sms-activate.org shut down on December 22, 2025, I had 3 production systems relying on their API. Here's what happened when I tested every alternative I could find.

The Test Methodology

I wasn't going to trust marketing pages. I spent $50 on each service and ran identical tests:

10 WhatsApp verifications (hardest — aggressive VoIP detection)
10 Telegram verifications (moderate difficulty)
10 Instagram verifications (inconsistent)
5 Google account verifications (very strict)
5 random service verifications (Discord, TikTok, etc.)

All tests used US, UK, and Indonesian numbers. I timed everything and noted the exact failure modes.

The Results

Success Rates (% of codes received)

Service	WhatsApp	Telegram	Instagram	Google	Overall	Avg. Delivery Time
VerifySMS	78%	90%	55%	40%	66%	34s
5sim.net	72%	88%	48%	35%	61%	41s
sms-man	65%	82%	42%	30%	55%	52s
SMSPool	80%	85%	60%	45%	68%	28s
TextVerified	92%	95%	88%	80%	89%	15s
Receive-SMS (free)	5%	15%	2%	0%	6%	N/A

Takeaway: TextVerified crushed everyone — but it's US-only and costs $2-5 per number. For international coverage at a reasonable price, it's a different game.

The Price-Performance Sweet Spot

                    High
                     │
  Success     SMSPool●  TextVerified●
  Rate               VerifySMS●
                     │    5sim●
                     │  sms-man●
                     │
                    Low────────────────────
                     Low    Price    High
                    $0.20          $5.00

Cost Per SUCCESSFUL Verification (the metric that matters)

This is what most reviews ignore. If a service costs $0.30 but only works 50% of the time, your effective cost is $0.60.

Service	Sticker Price	Success Rate	Real Cost	Auto-Refund?
VerifySMS	$0.20-0.80	66%	$0.30-1.21	✅ Yes
5sim	$0.15-0.60	61%	$0.25-0.98	❌ Manual
sms-man	$0.10-0.50	55%	$0.18-0.91	❌ Manual
SMSPool	$0.30-1.00	68%	$0.44-1.47	❌ Partial
TextVerified	$2.00-5.00	89%	$2.25-5.62	✅ Yes

Critical note on refunds: Without automatic refunds, your "real cost" is the sticker price divided by success rate. With auto-refunds (VerifySMS, TextVerified), failed attempts cost you nothing — so the "real cost" is just the sticker price for successful ones.

Service-by-Service Breakdown

5sim.net — The Obvious First Choice

Everyone from sms-activate migrated here first. The interface is similar, the API is compatible.

What works: Huge country selection (180+), decent API, crypto payments.
What doesn't: The web interface feels like 2015. No mobile app. Refunds require opening a support ticket. Some numbers are recycled too aggressively — I got a number that was already linked to someone else's WhatsApp.

Verdict: Good for developers who need API compatibility. Not great for end users.

sms-man.com — Budget Option

Cheapest per-number pricing I found.

What works: Low prices, especially for social media services.
What doesn't: Slow. Average delivery was 52 seconds (vs. 15-34s for others). Interface is confusing — I accidentally bought 3 numbers for the wrong country because the UX is that bad. No mobile app.

Verdict: Use if budget is the only concern and you don't mind waiting.

SMSPool — The Privacy Option

Claims to use non-VoIP numbers, which means better success rates for services that block virtual numbers.

What works: Genuinely good success rates. Their non-VoIP numbers do work better for WhatsApp and Instagram.
What doesn't: Smaller inventory. Popular country/service combos are often out of stock. Pricing is opaque — different prices for different "quality tiers" that aren't well explained.

Verdict: Best raw success rates in the budget category. Stock issues are frustrating.

TextVerified — The Premium Option

Real US carrier numbers. By far the best success rates.

What works: Everything works. 89% overall success rate is unmatched. Fast delivery.
What doesn't: US numbers only. Expensive ($2-5 per number). Limited availability — popular services sell out fast.

Verdict: If you only need US numbers and budget isn't a concern, nothing beats this.

VerifySMS — Disclosure: I Built This

Full transparency: I'm the developer behind VerifySMS. That's why I ran these tests — I needed to know where we actually stand.

What works: Automatic refunds (this is genuinely the feature I'm most proud of), native iOS app, 150+ countries, 40 languages.
What doesn't: Success rates for Instagram and Google are mediocre. We're still building our provider network. No Android app yet. No developer API yet.

Verdict: I won't claim we're the best. We're competitive on price, strong on UX, and the automatic refund policy makes the effective cost lower than the numbers suggest. But if you need US-only with maximum success rates, TextVerified is better.

Free Services (receive-sms-online.info, etc.)

I tested 3 free services. 6% overall success rate. Numbers are shared publicly, meaning they're already burned on every major platform. Don't bother.

API Migration Guide

If you're migrating from sms-activate's API, here's a compatibility matrix:

sms-activate Endpoint	5sim Equivalent	sms-man Equivalent
`getNumber`	`GET /v1/user/buy/activation/{country}/{operator}/{product}`	`POST /get-number`
`getStatus`	`GET /v1/user/check/{id}`	`POST /get-sms`
`setStatus` (cancel)	`GET /v1/user/cancel/{id}`	`POST /set-status`
`getBalance`	`GET /v1/user/profile`	`POST /get-balance`

My recommendation: Don't build provider-specific integrations. Build an abstraction layer:

interface SMSProvider {
  getNumber(country: string, service: string): Promise<{id: string, number: string}>;
  waitForCode(id: string, timeoutSeconds: number): Promise<string>;
  cancel(id: string): Promise<void>;
  getBalance(): Promise<number>;
}

Then implement this for each provider. When a provider goes down — and they will — you swap in the next one without touching application code.

Final Rankings

For developers needing API + international: 5sim > VerifySMS > sms-man

For end users wanting ease of use: VerifySMS > SMSPool > 5sim

For US-only, maximum reliability: TextVerified (no contest)

For budget: sms-man > 5sim > VerifySMS

Avoid: Free services, any service without a clear refund policy

These results are from January-March 2026. Success rates shift constantly as platforms update their detection. I'll update this post quarterly. Follow to stay updated.

Disclosure: I'm the developer behind VerifySMS. I've tried to be as honest as possible, including where competitors beat us. If you think my testing methodology is flawed, call me out in the comments.

Your Phone Number Is More Dangerous Than Your SSN — Here's the Data to Prove It

Serhat Doğan — Thu, 02 Apr 2026 00:28:36 +0000

In 2025, the average phone number appeared in 7.2 data breaches. Your social security number? 2.1. Yet we hand out our phone numbers like candy.

I dug into the data to understand why phone numbers became the most dangerous piece of personal information you own.

The Numbers Don't Lie

I analyzed data from HaveIBeenPwned, FTC reports, and carrier security disclosures. Here's what I found:

Data Breach Exposure Rates (2024-2025)

Data Type	Avg. Breaches Per Person	Recovery Difficulty
Email address	12.4	Easy — change password
Phone number	7.2	Impossible — same number for years
SSN	2.1	Hard — credit freeze
Home address	3.8	Moderate — but you live there
Credit card	1.9	Easy — bank issues new card

The critical difference: you can change everything except your phone number. New credit card? Call the bank. New email? 5 minutes. New phone number? You'd need to update every account, tell every contact, lose 2FA access to dozens of services. Nobody does this.

The Phone Number Attack Chain

Here's how a single leaked phone number cascades into a full identity compromise:

Phone number leaked in App X data breach
  ↓
Attacker finds your email via data broker lookup ($0.02)
  ↓
Attacker requests password reset on your email provider
  ↓
Email provider sends SMS verification to your number
  ↓
Attacker calls your carrier with social engineering
  ↓
SIM swap: your number now points to attacker's SIM
  ↓
Attacker receives your email reset code
  ↓
Attacker owns your email
  ↓
Attacker resets your bank, crypto, social media passwords
  ↓
Game over.

This isn't theoretical. The FBI's IC3 reported $68.4 million in SIM swap losses in 2023 alone. By 2025, estimated losses exceeded $100 million.

Why Phone Numbers Are Uniquely Dangerous

1. Universal Identifier

Unlike email (you can have many), most people use ONE phone number. It connects:

Banking apps
Social media accounts
Government services
Medical records
Dating profiles
Food delivery
Ride sharing

One number, connected to everything. One breach exposes the connections between all of them.

2. Reverse Lookup Is Trivial

For $5 on any data broker site, anyone can get:

Your full name
Home address
Email addresses
Relatives' names
Employment history

All from just your phone number. Try it yourself (with your own number) on sites like Whitepages or BeenVerified. It's terrifying.

3. Carrier Security Is Weak

The entity protecting your phone number is your carrier. The same carrier whose retail employees have been bribed to perform SIM swaps for $100. The same carrier whose "security question" is often your ZIP code.

T-Mobile has been breached 9 times since 2018, exposing customer phone numbers and account data repeatedly.

The Solution Spectrum

There's no single fix, but there's a spectrum of protection:

Level 1: Minimise Exposure (Free)

Stop entering your real number on random apps
Use email-based 2FA wherever available
Set a SIM PIN with your carrier (not the same as your phone PIN)

Level 2: Number Compartmentalization

Use your real number ONLY for banking and family
Use virtual numbers for everything else
Services like VerifySMS provide temporary numbers in 150+ countries at $0.20-1.00 per use

Level 3: Full Number Isolation

Dedicated "public" SIM for non-sensitive accounts
Google Voice or carrier secondary number
Virtual numbers for all one-time verifications
Hardware security key for critical 2FA

The Data Broker Economy

Your phone number is a commodity. Here's the actual pricing in data broker markets:

Data Package	Price	Includes
Phone → Name lookup	$0.02-0.10	Name, carrier, line type
Phone → Full profile	$0.50-5.00	Name, address, email, relatives
Bulk phone list (1000)	$50-200	Marketing-grade data
Real-time phone location	$300-500	Via carrier location services

Yes, there are services that sell real-time phone location data derived from carrier agreements. Your phone number is literally a tracking beacon.

What the Industry Should Do

Carriers should implement mandatory SIM swap verification (some now require in-store ID — but it should be universal)
Platforms should move away from SMS-based verification entirely. Passkeys, authenticator apps, and email verification are all more secure.
Regulators should classify phone numbers as PII with the same protections as SSNs. The current framework treats phone numbers as "directory information" — a classification from the landline era.
Users should treat phone numbers like home addresses — something you don't give to strangers. Use virtual numbers for verification when possible, and push for platforms to offer non-SMS alternatives.

The Uncomfortable Truth

We're using a 1990s technology (SMS) to secure 2020s infrastructure (banking, healthcare, identity). It doesn't work. But until the industry catches up, the best defence is reducing your phone number's exposure.

Every time you enter your number on a signup form, ask: "Do I trust this company to never be breached?" The answer is always no.

I'm building VerifySMS to make phone number privacy accessible. But honestly, the real solution is an industry shift away from SMS verification entirely. What's your take?

How SMS Verification Actually Works: Architecture, Failures, and Why 30% of Codes Never Arrive

Serhat Doğan — Wed, 01 Apr 2026 23:25:13 +0000

I spent the last year building an SMS verification service. Here's what I learned about the surprisingly fragile infrastructure behind those 6-digit codes.

The Journey of a Verification Code

When you tap "Send Code" on WhatsApp or any other app, you trigger a chain of events that crosses at least 4 different networks:

Your app → Platform's server → SMS aggregator → Carrier gateway → 
SMSC → Cell tower → Your phone

Each hop is a potential failure point. The industry average delivery rate? Around 70-85% depending on the country. That means up to 30% of verification codes never arrive.

Why Codes Fail to Arrive

After processing tens of thousands of verification requests, I've categorized the failure modes:

1. Carrier Filtering (40% of failures)

Carriers run content inspection on SMS traffic. Messages containing patterns like "Your code is" or "verification" get flagged and sometimes silently dropped.

This is why some services send codes as:

G-482916 (Google's format — harder to filter)
Your Telegram code: 48291 (mixed with branding)
A message with no clear code pattern at all

Carrier filtering varies wildly by country. Indonesia has aggressive filtering. Germany is relatively permissive. The US is somewhere in between — and it varies by carrier (T-Mobile vs. AT&T have completely different filtering rules).

2. Grey Routes (25% of failures)

SMS routing has a dirty secret: grey routes. To save money, some aggregators route international SMS through unauthorized paths.

Legitimate route:
  US Platform → US Aggregator → UK Carrier → UK Phone ✅

Grey route:
  US Platform → Indian Aggregator → Random gateway → UK Phone
  (cheaper, but unreliable and often blocked)

Grey routes are cheaper but have terrible delivery rates. They're also technically illegal in many jurisdictions. If a verification service is suspiciously cheap, they're probably using grey routes.

3. Number Type Mismatches (20% of failures)

This is the biggest challenge for virtual number services. Platforms actively try to block virtual and VoIP numbers:

Number Type	WhatsApp	Telegram	Instagram
Real carrier SIM	✅ 95%+	✅ 95%+	✅ 95%+
Mobile VoIP	⚠️ 60-70%	✅ 85%+	⚠️ 50-60%
Fixed VoIP	❌ <20%	⚠️ 40-50%	❌ <10%
Virtual (dedicated)	⚠️ 70-80%	✅ 90%+	⚠️ 40-60%

These rates shift constantly. WhatsApp updates their VoIP detection roughly every 2-3 weeks. What works today might not work tomorrow.

4. Timing and Load (15% of failures)

SMS infrastructure has capacity limits. During peak hours (9-11 AM local time in most countries), carrier gateways queue messages. Verification codes have a shelf life — if the code takes 3 minutes to arrive but the app's timeout is 60 seconds, it's a failure even though the SMS eventually arrives.

The Multi-Provider Problem

No single SMS provider covers all 180+ countries reliably. Here's what the provider landscape looks like:

Provider A: Good in US/EU, terrible in Southeast Asia
Provider B: Great in Asia, doesn't cover Africa
Provider C: Covers Africa, but expensive and slow

Any serious verification service needs at least 2-3 providers with intelligent routing. The algorithm isn't just about fallback — it's about knowing which provider works best for which country-service combination in real-time.

// Naive approach (bad)
const provider = providers[0] || providers[1]; 

// Better: route based on historical success data
function selectProvider(country, service) {
  const stats = getSuccessRates(country, service); // from last 24h

  // Weight by success rate and latency
  return stats
    .filter(s => s.successRate > 0.5) // minimum threshold
    .sort((a, b) => {
      const score = (s) => s.successRate * 0.7 + (1 - s.avgLatency/120) * 0.3;
      return score(b) - score(a);
    })[0]?.provider;
}

The Refund Problem

Here's an industry dirty secret: most SMS verification services profit from failed deliveries.

You pay $0.50 for a number. The SMS never arrives. The service keeps your money and says "sorry, try again." They spent $0.10 on the number attempt, pocketed $0.40, and gave you nothing.

This is why automatic refund policies matter. If a service doesn't offer automatic refunds for failed verifications, they have a financial incentive for codes to not arrive. Think about that.

What I've Learned Building This

After a year of building VerifySMS, these are my biggest takeaways:

SMS is unreliable by design. It was built for human-to-human communication in the 1990s, not for security-critical verification in 2026.
The industry needs transparency. Success rates, delivery times, and refund policies should be published openly. Most services hide behind vague "high success rate" claims.
Authenticator apps are better. If a service offers TOTP-based 2FA (Google Authenticator, Authy), use it instead of SMS. SMS verification should be a last resort, not a first choice.
Country matters more than service. A US number for WhatsApp verification might work 90% of the time. A Bangladeshi number for the same service might work 40% of the time. Always check country-specific success rates before purchasing.

The Future of Verification

SMS verification is a $2+ billion market, but it's built on infrastructure from the 1990s. The industry is slowly moving toward:

WhatsApp Business API verification (platform-native, no SMS needed)
Email-based verification (cheaper, more reliable)
Passkeys (passwordless, no verification code needed)
Device attestation (Apple/Google verify the device, not the number)

Until these alternatives achieve full adoption, SMS verification remains a necessary evil. Understanding how it works — and fails — helps you make better choices about when and how to use it.

I build VerifySMS, a virtual number service with automatic refunds. If you have questions about SMS verification infrastructure, I'm happy to answer in the comments.