The OTP Delivery Chain: What Happens Between Your API Call and Your User's Phone

From your application's point of view, sending a one-time password is one line of code. You call an endpoint, you get a 200, you move on. It feels atomic.

It isn't. Between that API call and the phone in someone's hand sits a supply chain — usually several companies long — that you have no visibility into, didn't choose, and are paying for on every single message. Most verification problems that look mysterious from inside your app are perfectly ordinary once you can see that chain.

Here's what's actually in it.

The hops nobody shows you

A "send SMS" request typically travels something like this:

Your provider's API accepts the request and queues it.
An aggregator — a company that buys messaging capacity in bulk and resells it — picks it up. Your provider may not own any carrier connections at all; it may simply be reselling somebody else's.
Possibly another aggregator. Capacity gets traded. A route that was cheap this morning may be resold twice by lunch.
The destination carrier finally accepts the message and attempts delivery to the handset.

Each of those hops is a business that needs a margin. None of them are visible in your dashboard. When we say roughly 20 cents of every verification dollar goes to middlemen, this chain is the middlemen — not a metaphor.

What each hop costs you

Latency. Every hop is a queue. This is why SMS OTP delivery is typically quoted at anywhere from 5 to 30 seconds depending on the corridor — that range isn't the radio network being slow, it's the number of intermediaries the message has to be handed through. A flash call over a direct carrier connection completes in a median of 2–3 seconds because it simply has fewer places to wait.

Money. Margin compounds at every hop. The same message to the same handset can cost wildly different amounts depending on how many companies touched it on the way.

Truth. This is the one that hurts. A delivery receipt (DLR) is generated somewhere in that chain and passed back up to you. If an intermediary reports "delivered" and it wasn't, you have no independent way to know. You are trusting a status report from a company you have no contract with, about an event you cannot observe, on a route you didn't pick.

Gray routes, briefly

A gray route is a path where the commercial relationship doesn't match the technical one — traffic that reaches a carrier through a channel it wasn't strictly meant to, usually because it's cheaper. Gray routes are common precisely because everyone in the chain is competing on price.

The practical consequence: the more hops between you and the carrier, the more opportunities exist for somebody in the middle to profit from your traffic in ways that don't serve you. This is the same structural weakness that makes AIT fraud so profitable — fraud is easiest where a message passes through multiple resellers before reaching a carrier, because more hops mean more places for someone to take a cut of inflated volume.

Gray routes aren't a separate problem from cost. They're the same problem, viewed from the fraud side.

Why "we have a great API" isn't the whole story

Every verification vendor has a clean REST API. That's table stakes, and it tells you nothing about what happens after the request leaves your server.

The questions that actually determine your bill and your conversion rate are further down:

Does your provider hold its own carrier connections, or is it reselling?
How many parties touch a message before it reaches the handset?
Can you see the actual route and the actual per-message cost — or just a monthly total?
When a DLR says "delivered," who generated that receipt?

A vendor that can't answer those is not necessarily doing anything wrong. But they can't prove they aren't, either, and neither can you.

What a direct connection changes

Connecting straight to carriers — SMPP for messaging, PSTN for voice — removes the resale layer rather than optimising it. The differences are structural, not incremental:

Fewer queues → lower, more predictable latency.
No resale margin → the price you pay is the route's price, not the route's price plus everyone's cut.
First-party records → the call detail record is generated by the leg that actually ran, not relayed to you by a counterparty with an interest in what it says.
No gray-route exposure → there is no chain of intermediaries for anyone to insert themselves into.

Flash call verification takes this further by not entering the messaging chain at all. The code is never sent as data — it is the caller ID of a real voice call over carrier infrastructure. There is no SMS aggregator anywhere in the path, which is why it's structurally immune to the fraud patterns that target SMS termination.

What to actually do about it

You don't need to switch providers to start seeing this. Three things worth doing this week, whoever you're with:

Ask your provider directly whether they own their carrier connections or resell. It's a fair question and the answer is informative either way — including how they answer it.
Pull your per-message cost, not your monthly total. If you can't get per-message cost broken down by destination, that's the finding.
Compare your send count to your completed-verification count. The gap between those two numbers is what you're paying for and not getting. Most teams have never looked.

The chain is invisible by default. That's the problem — not because everyone in it is acting badly, but because you can't manage what nobody will show you.

You can check our published per-attempt rates for every country we serve on the pricing page — no quote form, no sales call. What you see is what you pay, because there's nobody in between to take a cut of it.