How to Compare VTU API Providers: A Scorecard for Resellers
Your VTU website does not make data. Every order you sell is bought from a provider, and your site passes it on. So the provider you pick decides how often your customers get what they paid for.
Most resellers choose a provider by one thing: the lowest price. It is an easy number to compare, and it is the wrong one to start with. A provider that is ₦3 cheaper per GB but fails one order in twenty will cost you more than it saves, because every failed order brings a refund, a message, and a customer who is less likely to return.
This article gives you a scorecard. It has nine questions. You score each provider from 0 to 3 on each question, add up the total, and let the numbers show you what your gut feeling hides.
Before you start: three rules
- Compare at least two providers. One provider is a risk, not a plan. You will want a backup anyway.
- Test with real money, in small amounts. A test of ₦200 tells you more than any sales page.
- Write down what you find. Memory is kind to providers you like.
The scorecard
Copy this table into a note or a spreadsheet. Fill it in as you test.
| # | Question | Provider A | Provider B |
|---|---|---|---|
| 1 | Do orders succeed? | ||
| 2 | Is the answer clear when they do not? | ||
| 3 | Can I check an order again later? | ||
| 4 | Are refunds automatic and fast? | ||
| 5 | Are plan and network IDs stable and documented? | ||
| 6 | Is the price good across the whole range? | ||
| 7 | Can I test safely before real money? | ||
| 8 | Is support real and reachable? | ||
| 9 | Is the wallet side easy to live with? | ||
| Total (max 27) |
Now the questions, one by one.
1. Do orders succeed?
Make twenty small orders across the networks you care about, at different times of day. Include one late at night and one at a busy hour such as Friday evening. Count how many arrive.
- 3 points: nearly all arrive, with no pattern in the failures.
- 2 points: most arrive, and failures are rare and random.
- 1 point: failures are common on one network or at certain times.
- 0 points: you would not tell a friend to use it.
2. Is the answer clear when an order does not succeed?
This one is easy to miss. Some providers return a clear "failed" or "success". Others return a message that could mean either, or a "pending" that never changes.
An unclear answer is expensive. You do not know whether to refund the customer, and if you guess wrong you lose money or you leave a customer unpaid.
- 3 points: every response is a clear success, failure or pending, with a reason.
- 0 points: you often have to guess.
3. Can I check an order again later?
A good provider lets you ask, "what happened to order number 12345?" and gives a final answer. This is called a re-query or status check. It is how a good system settles a pending order without guessing.
Also look for a request ID you can send with each order. If your site sends the same request twice by accident, a request ID lets the provider say "I already did this one" instead of delivering twice.
- 3 points: a status check exists, it is documented, and request IDs are supported.
- 0 points: neither exists.
4. Are refunds automatic and fast?
When a provider cannot deliver, does the money go back to your wallet by itself, and how soon? Or do you have to write to support?
Place a failing order on purpose (for example, a number that is not valid on that network) and watch your wallet.
- 3 points: an automatic refund within minutes.
- 1 point: a refund after a ticket and a wait.
- 0 points: no clear rule.
5. Are plan and network IDs stable and documented?
Your site talks to the provider in codes: a network code, a plan ID. Here is something that surprises people: two providers rarely use the same codes. One provider might call a TV service "1" where another calls the same service "2". A plan that is ID 5 at one provider may be a different plan, or not exist, at another.
So ask:
- Is there a clear, current list of IDs?
- Do IDs change without notice?
- Is a plan removed and replaced under a new ID when prices change?
If you plan to use more than one provider, your site needs to keep a separate code for each. Do not copy IDs from one provider to another. Check every one.
- 3 points: a complete list that rarely changes, and a change notice when it does.
- 0 points: you only find out when orders fail.
6. Is the price good across the whole range?
Do not compare only your best-selling plan. Compare the same twenty items across providers: the cheap plans, the big ones, airtime, and the bills you plan to sell.
A provider can be cheapest on MTN data and the most expensive on cable. Build a small table of your real top sellers and compare the cost for each.
Also check how the price is set. Is it a fixed discount, or does it depend on how much you fund each month? Does a higher tier need a big deposit?
- 3 points: competitive on your actual top sellers, with clear rules for discounts.
- 0 points: cheap on one item, poor on the rest.
7. Can I test safely before real money?
A sandbox or test mode lets you build and check your integration without spending. Not every provider has one. Without it, every test costs money, and you test less.
- 3 points: a sandbox with realistic responses.
- 1 point: no sandbox, but very small minimums.
- 0 points: no way to test without a real spend.
8. Is support real and reachable?
Contact support before you need them. Ask a real question, such as "how do I check a pending order?", and see how long the answer takes and whether it is useful.
- 3 points: a fast, specific answer from a person who knows the system.
- 0 points: silence, or an answer that does not address the question.
9. Is the wallet side easy to live with?
Check the practical parts:
- How do you fund the wallet, and how fast does money show?
- Is there a minimum deposit?
- Do you need to give them your server's IP address for API access (called whitelisting), and how easy is it to change?
-
Can you see a clear statement of every order and every refund?
-
3 points: easy to fund, easy to read, nothing surprising.
- 0 points: delays, hidden rules, or statements you cannot match to your own records.
How to read your totals
- 21 to 27: a strong provider. Use it as your main one.
- 15 to 20: usable, but find out which questions scored low and decide if you can live with them. This is often a good backup.
- Below 15: not for your main traffic, whatever the price.
A provider with a low total on questions 1 to 4 should worry you more than a low total on questions 6 to 9. The first four are about whether your customers get what they paid for. The rest are about convenience and cost.
How to run the twenty-order test properly
Do not just place twenty orders and look. Use a small plan so you can write the result down.
| Test | What to order | What to record |
|---|---|---|
| 1 to 5 | The cheapest data plan on each network you will sell | Time sent, time delivered, status |
| 6 to 8 | Airtime on three networks | Same |
| 9 to 10 | One bill you plan to sell (cable or electricity) | Same, and the receipt or token |
| 11 | An order for a number that is not valid | The error message you get |
| 12 | The same order sent twice, quickly, with the same request ID | Whether it delivers once or twice |
| 13 to 14 | An order at night and one on a busy evening | Delivery time and status |
| 15 | An order for a plan that is out of stock | The message and what happens to the wallet |
| 16 to 20 | Repeat your best-selling plan | Whether results stay the same |
Spend about ₦3,000 to ₦5,000 in total. It is the cheapest insurance you will buy for your business.
Five red flags
If you see any of these, slow down.
- A price that is much lower than every other provider. Someone is losing money, and it may soon be you.
- No written API document. If they only explain things in chat messages, you will have problems every time something changes.
- No status check. You cannot settle a pending order without guessing.
- Support that only answers after you have paid. It tells you how you will be treated later.
- A wallet balance you cannot get back. Ask before funding.
When you change provider
Switching is normal. The careful way:
- Keep the old provider running while you test the new one.
- Map the network codes and plan IDs again from the new provider's own list. Do not assume they match.
- Move one service first, such as airtime, then watch it for three days.
- Move the rest, one at a time.
- Keep a small balance with the old provider for a few weeks, in case you need to roll back.
An example, with made-up numbers
Here is a small made-up example to show how the scorecard changes a decision. These are not real providers.
| Question | Provider A (cheapest) | Provider B |
|---|---|---|
| 1 Orders succeed | 1 | 3 |
| 2 Clear answers | 1 | 3 |
| 3 Re-check | 0 | 3 |
| 4 Refunds | 1 | 2 |
| 5 IDs | 2 | 3 |
| 6 Price | 3 | 2 |
| 7 Testing | 0 | 2 |
| 8 Support | 1 | 2 |
| 9 Wallet | 2 | 2 |
| Total | 11 | 22 |
Provider A wins on price, and loses nearly everywhere else. If you only compared prices, you would have chosen A. The scorecard says B is the one you can build a business on, and A is not even a good backup.
Using two providers well
Once you have a main and a backup, a few rules keep things simple.
- Keep each provider's codes separate. Do not reuse one provider's plan IDs for another.
- Decide which provider serves which service. For example, B for data and A for airtime, if each is better at that.
- Watch the failure rate by provider every week. Move traffic when one gets worse.
- Keep both wallets funded. A backup with an empty wallet is not a backup.
What to ask in your first message to any provider
Copy and paste these:
- Do you have a status-check endpoint, and can I send a request ID with each order?
- What happens to the wallet when an order fails? How long does it take?
- Where do I get the current list of network and plan IDs, and how will you tell me when they change?
- Do you have a sandbox?
- What is the minimum deposit, and how do tiers or discounts work?
- Do I need to whitelist my server's IP address, and how do I change it?
If the answers come back quickly and clearly, that is already a good sign. If you get vague replies, you have learned what support will be like later.
How this helps on XpiriaTech
On XpiriaTech you connect your own provider accounts, and you can connect more than one. The site keeps a separate code for each provider on each network and plan, and you choose which provider serves each one, so the "same plan, different ID" problem is handled in your settings and not in your head.
You can see how this works on the VTU solution page. The scorecard works whichever platform you use.
Common questions
Is the cheapest provider ever the right choice? Yes, when it also scores well on questions 1 to 4. Then the lower price is a real saving. The mistake is choosing on price before you know the rest.
How often should I re-score? Every three months, or any time you notice more failed orders than usual. Providers change.
Is it risky to put a lot of money in one provider's wallet? Keep the balance only as high as a few days of sales need. Fund little and often. If a provider has trouble, the money at risk is small.
Can I get my money out of a provider wallet? Ask before you fund. Some providers refund the wallet balance, and some do not. It is a fair question and a good provider will answer it plainly.
The short version
Do not pick a provider by price alone. Place twenty small orders, check how failures and refunds are handled, confirm the IDs and support, and score each provider on the nine questions. The cheapest one rarely wins, and the one that wins is the one your customers never have to complain about.
Software engineer with over 9 years of experience in software development and digital technology. B.Sc. in Industrial Chemistry from Adekunle Ajasin University. Has worked across web development, mobile applications, e-commerce platforms, VTU and fintech solutions, API integrations and custom software.




Comments
No comments yet. Be the first to share your thoughts.