How to Sell Steam Wallet Top-Ups on FunPay

Steam top-ups look like the simplest possible product — an amount for an amount, no editions and no DLC. In practice this is the category with the hardest regional binding of them all. A key is at least sometimes global. A wallet almost never is.

This article treats top-ups as a product category: two fundamentally different supply formats, what actually breaks in real orders, what delivery proof has to look like, and where the margin comes from.

It extends the guide to selling on FunPay into one category.

Two product formats that get confused

Two fundamentally different things are sold under the word top-up, and mixing them in one listing leads straight to disputes.

Regional wallet code

A ready product unit: a string with a denomination in a specific currency, tied to a region. You hand over the code and the buyer redeems it themselves.

• Upside — fully automatable, scales without headcount, delivery is instant.
• Downside — hard binding to region and currency, no flexibility on the amount.

Direct top-up

A service: you credit an amount to the buyer's specific account through your own chain.

• Upside — the region question disappears or shrinks, the amount is flexible.
• Downside — a manual operation, you own the whole payment path, proof is harder.

The practical conclusion: these are two different businesses, and they belong in separate listings with separate descriptions rather than one universal offer.

Currency and region matching

This is the central mechanic of the category. A wallet code is denominated in its region's currency and can only be redeemed on an account tied to that same region. No conversion happens.

Hence the mandatory step: the buyer's wallet region and currency are established before the sale, not after a failed redemption. The practical method is a clarifying question in chat as a condition of confirming the order. Phrase it specifically: many buyers name their country of residence rather than their account region, and those are not the same thing.

The buyer's answer stays in the platform correspondence and becomes your evidence if a dispute opens anyway. The full composition of what must reach the buyer is covered in the article on FunPay seller obligations.

What breaks in real orders

Three scenarios account for nearly every problem order in this category.

• Region mismatch. Code from one region, account from another — redemption is rejected. Cause number one, and entirely removable by asking before the deal.
• Wallet limits. The top-up would push the balance past its allowed ceiling and the system refuses. Particularly relevant for large denominations.
• Recent region change on the account. The buyer changed their region and hits restrictions they are not aware of themselves.

None of these is a defective product — the code remains valid throughout. But the buyer arrives with a complaint, and speed matters more than being right: a swap to the correct region or a refund within minutes almost always closes the matter without arbitration. The dispute logic is in the FunPay arbitration playbook.

Delivery proof

This category demands stricter evidence than keys, because the outcome is measured in a balance rather than in receipt of a string.

For a wallet code the minimum is the sent string with an exact timestamp, supplier confirmation of denomination and region at the moment of transfer, and the buyer's recorded answer about their region.

For a direct top-up the bar is higher — you need a transaction identifier on your side and confirmation of the credit, sent to the buyer immediately after execution. A bare done message weighs almost nothing in arbitration.

Automatic delivery generates a large part of this log by itself — how to configure it is covered in the FunPay auto-delivery guide.

Which grid of regions and denominations to stock

Assortment in this category is not a list of products but a two-dimensional grid: regions across, denominations down. Mistakes in how you build it cost more than your purchase price does.

The principles that work for most operators:

• Start with two or three regions, not ten. Every region is a separate listing description, a separate stock position and a separate support scenario. A wide grid with weak control produces more rejections than sales.
• Small denominations drive turnover, large ones drive margin. The first build flow and rating, the second pay for operator time. Carry both, but model their economics separately.
• Do not publish a listing you cannot fulfil from stock. Selling first and sourcing afterwards is the fastest route to a dispute in a category where the buyer expects an instant result.
• Run a separate listing per region. A universal any region description reliably generates mismatches and refunds.

A separate question is what to do when a popular denomination runs out. Pulling the listing is almost always cheaper than selling in the hope of restocking: rating recovers more slowly than turnover does. The mechanics of handling shortages are covered in the article on supplier stockout recovery.

Where the margin comes from

Margin on top-ups is thinner than on keys, because the product is uniform and buyers compare prices easily. Three levers matter:

• Denomination purchase price. The primary factor, driven directly by volume and by the quality of your wholesale channel.
• Failed-activation rate. Every region-mismatch order is either a refund or operator time. The pre-sale region question pays for itself faster than anything else here.
• Operator time per order. In direct top-ups this is the main cost line and the main growth ceiling.

Platform fees and withdrawal fees are counted separately and always verified on FunPay's current tariff page before you price — rates change, and pricing from memory eats margin invisibly. The full method is in the unit economics of a digital goods reseller.

Where to source denominations

The category imposes two supply requirements: a broad grid of regions and denominations (without it you turn away half your buyers) and correct region data delivered alongside the code, without which you can neither describe the listing nor verify a match.

FoxReload covers both: a catalog of 900+ SKUs including multi-region items, a single REST API, and automatic delivery where denomination and region arrive together with the code — letting you run several regional listings without manually reconciling stock. For the broader category view see the article on wholesale Steam gift cards, and for the adjacent in-game crediting mechanic the guide to selling game currency on FunPay.