Game Top-Up Suppliers — API, Pricing and Regions 2026
Resellers routinely enter the top-up market carrying key-market habits, and break their operations in the first month. A game-currency credit cannot be warehoused, has no code, and in the overwhelming majority of cases cannot be reversed. Below: how top-up supply actually works, where regional price gaps come from, and which clauses must be in your supplier contract.
Keys and top-ups are two different businesses
Compare the mechanics, not the marketing.
A key is goods. The activation string exists before the order. You can buy it early, hold it, and deliver it in a minute or in a month. If your supplier goes down, you sell from your own stock. Key problems are goods problems: revocation, region locking, provenance.
A top-up is an operation. At order time the supplier calls the publisher channel and credits currency to a specific game account. Nothing exists before the order and nothing remains after. You cannot build a buffer. If the channel is down, you have nothing to sell regardless of how large your deposit is.
Three practical consequences follow:
- Top-up "stock" is a channel status, not a number. Monitor availability, not quantity.
- A supplier failure is immediately visible to the buyer. With keys you have time to fall back to a reserve; with top-ups you do not.
- Refunds work differently. An unused key returns to stock; credited currency does not come back.
Player-ID delivery — where the money leaks
The defining operational trait of top-ups: the delivery address is a player identifier typed in by the buyer. If the buyer gets it wrong, currency lands on a stranger's account — and from the publisher's perspective that is a correctly executed transaction.
Validate the ID before charging
This is the first question for any supplier. The correct flow looks like this:
- Buyer enters the player ID (and server, if the game requires one).
- Your backend calls the supplier's lookup and receives the account nickname.
- You display the nickname and require explicit buyer confirmation.
- Only then do you create the order and charge.
If the supplier cannot return a nickname from an ID, every typo becomes your loss. The dispute almost never goes your way — the buyer paid you, not the publisher.
Server, region and platform
Many titles need more than an ID. You may need a server (common in titles with Asian infrastructure) or the platform the account is bound to. The supplier's catalogue must state which fields are mandatory per SKU — otherwise you will build an order form that generates unfulfillable requests.
Why the same currency costs different amounts
The regional spread is not an anomaly or a grey scheme. It follows directly from how publishers structure local pricing.
Local price lists. The publisher sets a bundle price per market against local purchasing power. In lower-income markets the hard-currency equivalent comes out lower.
Digital-services tax. VAT or its local equivalent varies by jurisdiction and is often baked into the shelf price. The mechanism is covered in tax and VAT for digital-goods distributors — always verify current rates for your own jurisdiction before pricing.
Payment-method cost. Local payment rails have different costs and that cost sits inside the price.
FX movement. Publishers do not revise local price lists daily, so currency swings temporarily widen or close the gap.
An important warning: the cross-region gap is unstable. A publisher can revise a local price list or technically restrict purchases at a local price at any time. A strategy built entirely on the spread between two regions lasts exactly until the next price revision. The logic is unpacked in regional price arbitrage on game codes.
What to demand from a top-up supplier
| Criterion | What to check | Why it matters |
|---|---|---|
| Coverage | Games and servers/regions for each | "We have PUBG" means nothing without regions |
| ID validation | Nickname returned before charging | The only defence against buyer typos |
| Crediting time | Typical and maximum, in writing | Buyers expect seconds, not hours |
| Failure behaviour | What is returned on a channel timeout | Determines who absorbs the loss |
| Refunds | Explicit terms and exclusions | Top-up refunds are usually impossible |
| Outage notice | Channel and lead time | Lets you close the storefront before complaints |
| Order status | How to obtain the final result | Without it automation is impossible |
A note on asynchrony
Top-ups rarely complete instantly. An order moves from accepted to confirmed credit, and your code must survive the intermediate state. Some suppliers expose results via status polling, others via callbacks. Never assume a supplier offers webhooks or idempotency keys — ask whether that specific supplier actually implements them and design against what is genuinely documented. A correct order lifecycle is laid out in the API order flow explained.
Common early mistakes
Selling without a channel health check. The storefront shows stock, the channel is down, and you collect orders you cannot fill.
One refund policy for keys and top-ups. The terms must differ, and the buyer must see it before paying.
Not logging the submitted ID. When a buyer claims they typed a different ID, only a timestamped log with the confirmed nickname proves otherwise.
Ignoring margin after fees. Supplier price is not your cost base. Compute with platform and payment fees included, as in unit economics for a digital-goods store.
Where to source top-up inventory
Assembling top-ups for dozens of titles directly from publishers is unrealistic for a small or mid-sized reseller — nearly every case requires a local contract, volume and legal presence. The practical route is a wholesale supplier with a broad catalogue: FoxReload offers 900+ SKUs spanning game top-ups, gift cards, keys and eSIM through a single REST API with auto-delivery and multi-region SKUs — one contract, one integration and one balance instead of a dozen fragmented channels. Before your first deposit, run the process in how to vet a supplier before funding your balance.
Pre-integration checklist
- Obtained the title list broken down by server and region.
- Verified player-ID validation returns a nickname.
- Crediting times and timeout behaviour agreed in writing.
- Top-up refund terms documented separately from keys.
- Channel health monitoring wired to automatic SKU hiding.
- Logging the submitted ID, confirmed nickname and final status.
- Ran a test order for every region you intend to sell.