{{ blogdata.headline }}

Search "best VTU API in Nigeria" and read the results carefully. Nearly every one is written by a provider who happens to rank itself first. Several advertise 99.9% uptime. Not one of them publishes a monthly success rate.

That is worth sitting with, because uptime is not the metric that matters to you.

Uptime measures whether a server answered. Success rate measures whether your customer got their data. A provider can be up every second of the month and still fail one order in six, and their badge will not change.

So here is ours, month by month, along with what our system actually does with every transaction that does not go through. If you are integrating a data, airtime or bills API — ours or anyone's — this is the part worth interrogating before you commit.

Our numbers

Between 26 February and 26 July 2026 we logged 48,719 API transactions, storing the request body for every single one and the raw upstream response for most. First-attempt success by month:

July is the interesting one, and we are not going to hide it. We traced the decline and it was largely ours to fix: we grew faster than one upstream route could absorb and kept routing into it past its capacity. That is a routing problem, not a mystery, and this month we shipped changes to stop it happening. We would rather show you a real month with an explanation than a rounded number with none.

What that figure does not mean is that 16% of customers lost money. It means 16% of orders did not complete on the first attempt. Those are entirely different statements, and the difference is the rest of this article.

A transaction has three outcomes, not two

This is the single most important thing about vending, and the thing most integrations get wrong.

1. Delivered

The telco confirmed it. Money moved, data landed.

2. Declined

The upstream rejected it outright — invalid plan, ineligible number, insufficient upstream balance. Unambiguous. Refund and move on.

3. Accepted, but not confirmed

This is the hard one. The upstream took the order, returned a reference, and told you something like:

{"status": true, "data": {"current_status": "processing",
 "reference": "5081f481bc27e72e27cd", "msg": "TIMEDOUT"}}

Read it carefully. status: true means accepted. processing means not finished. The data may land in ten seconds, or never.

About 1 in 10 of our failures sits in this third state — and on our busiest data route it is closer to 3 in 10. Treat these as failures and refund immediately, and you can pay twice: the customer keeps the data and gets their money back. Treat them as successes, and you have charged someone for data that never arrived. Both are wrong, and adopting either as a blanket policy is how resellers quietly lose margin without ever seeing it in a report.

This state is also not evenly distributed. Some upstreams never produce it — they answer yes or no and mean it. Others generate it constantly. That difference tells you far more about a provider than an uptime badge does, and it is worth measuring per route rather than as one platform average.

What happens to the ones that fail

Of every failed vend in the last 30 days:

• 81.9% were automatically refunded — no ticket, no chasing, no waiting for someone to notice
• 12.2% were cancelled before any value moved
• 3.0% completed on a later attempt
• 2.4% were still unresolved at the time of writing

That last figure is 47 transactions out of 1,930. We are not going to pretend it is zero.

And one more admission, since we are counting things properly: we store the request body for 100% of transactions, but on roughly 30% of failures the upstream returns an empty response body — nothing for us to keep. Two specific upstreams account for almost all of it. That is a real gap in our own diagnostics, we know exactly which routes cause it, and we are pushing those providers to return something loggable. We would rather tell you that than claim perfect records.

Four things we built because the numbers made us

Refund on decline, not on ambiguity

A hard decline auto-refunds immediately. An accepted-but-unconfirmed order does not — it stays open for reconciliation. Refunding an order the upstream has already queued is how you pay for the same data twice.

Refuse before debit, not refund after

When an upstream route starts timing out, we stop selling on that route rather than taking money for orders we suspect will strand. The customer sees "temporarily unavailable, try shortly" and keeps their money. A refund three hours later is a worse experience than an honest rejection now.

A cooldown after a timeout

When a timeout auto-refunds, the natural thing for a customer to do is buy again immediately. We watched a single phone number get stranded nine times from one intent. Now, after a timeout, that number cannot repurchase that plan for a short window — protecting the customer from repeated debits and us from a queue of duplicate reconciliations.

Balance snapshots on every transaction

Every wallet movement records the balance before and after. When a customer disputes something, nobody reconstructs it from timestamps.

Six questions worth asking any provider

Whether or not you ever use us, these separate a real integration from a demo:

1. What is your actual first-attempt success rate, by month, for the last six months? Not uptime.
2. What happens to an order that is accepted but not confirmed? If the question does not immediately land, they do not handle that state — and you will be the one absorbing it.
3. Can I requery an order by reference? Without a status endpoint, every timeout becomes a guess.
4. Do you accept an idempotency key on purchase? Without one, a retry after a network blip can double-vend.
5. Are failed vends refunded automatically, and how fast? "Contact support" is not a refund policy.
6. Do you store the raw upstream response? Ask what percentage they actually capture — "we log everything" and "everything our upstreams give us" are different answers.

If a provider answers all six clearly, they have thought about this properly. That is worth more than a discount.

Why we published this

We could have written the article everyone else writes: a comparison table where we come first, a 99.9% badge with no month behind it. It ranks for a while and convinces nobody who has run real volume.

Reselling is a margin business. A provider who hides their failure rate is not protecting you from it — they are just ensuring you discover it in front of your own customers. Anyone can vend data on a good day. The handling is the product.

Our API covers data, airtime, electricity and vouchers, with a sandbox that validates without charging your wallet, and drop-in compatibility if you are already built against a MaskawaSub or Adex-shaped integration — so switching does not mean rewriting. Full documentation, endpoints and error codes: absvendor.com/developers.

And if you run a competing platform: publish your monthly numbers. We would genuinely like to read them.