In-Game Purchase Refund Policy: Spent Currency, Consumables, Bundles
Write an in-game purchase refund policy that handles spent currency, consumables and bundles, and holds up with app stores and card disputes.

Photo: Pixabay
On this page 7 sections
- Why "All Sales Final" Fails for Game Purchases
- Unspent Currency vs. Spent Currency Refunds
- Consumables, Cosmetics, and Bundle Refund Rules
- Clawing Back Currency on Refunded Purchases
- Matching Your Policy to App Store and Web Shop Rules
- Displaying the Policy so It Counts in Disputes
- A Game Refund Policy Template You Can Adapt
Key takeaways
- Track paid currency separately from bonus and earned currency, and fix a spend order, because the spend order decides how much of a purchase is still refundable.
- Refund only what is untouched, whether that's unspent paid currency or unused bundle components, and give each bundle component a stated value at the time of sale.
- When a refund or chargeback lands after the currency is spent, revoke what that purchase funded and leave the rest of the account alone.
- A limited refund policy helps in a card dispute only if the player saw it before paying, so put it on the purchase screen and log the acceptance.
A workable in-game purchase refund policy refunds what the player hasn't used and declines what they have. Unspent paid currency is refundable. Currency already turned into items or consumed is not, and bundles are refunded only for the components nobody has touched. Write those rules to match how your currency ledger actually works, then show them before the buy button. Card networks and issuers give weight to a refund policy only when the player saw it before paying.
Most studios get those broad strokes right. Policies break down in the ledger details: which bucket a player spends from first, and what happens when a refund lands after the gems are gone.
Why "All Sales Final" Fails for Game Purchases
A blanket no-refund line in your terms feels safe. In practice it fails in three places.
The first is unauthorized purchases. A common source of game disputes is a child spending on a parent's saved card. The parent calls the bank, which treats it as an unauthorized transaction. Your "all sales final" clause says nothing about a purchase the cardholder claims they never made, so the dispute proceeds anyway.
The second is the app stores. When a player buys through Apple or Google, the store is the seller of record and decides refunds under its own policy. Your terms can't override that. If your game assumes those sales are final, a store refund leaves the player holding currency they no longer paid for.
The third is cost. Refusing a refund doesn't keep the money if the player goes to their bank instead. Refunding costs you the sale. A chargeback costs you the sale and a processor dispute fee. Someone on your team also has to spend time answering it, and it counts against your dispute ratio. Card networks run monitoring programs for merchants whose dispute counts climb, and processors respond to rising ratios with higher reserves or account reviews. For a studio already classed as high risk, that matters. We cover how those reserves and fees work in video game processing fees and microtransaction math.
Consumer protection law can also limit how far a no-refund policy reaches, and it varies by state and by country. Some jurisdictions, including the EU, have specific consent rules for digital content that affect whether a no-refund position holds. Treat this as general information and confirm your obligations with a qualified attorney.
Unspent Currency vs. Spent Currency Refunds
Players usually ask to refund virtual currency in one of two situations. Either they bought a pack and changed their mind, or they bought a pack, spent some of it, and now regret the purchase. Your policy should treat these differently, and your ledger has to be able to tell them apart.
Start by splitting the wallet. Paid currency is what the player bought with money, and it is the only bucket with refund value. Bonus currency, the extra units granted alongside a purchase, disappears when that purchase is refunded. Earned currency from gameplay or login rewards is never refunded.
The rule studios overlook is spend order. When a player spends from a mixed wallet, which bucket gets drained first? Your answer changes the size of every partial refund.
Here is an illustrative example, with the assumptions stated. A player buys a gem pack for $9.99 that grants 1,000 paid gems and 100 bonus gems, so each paid gem is worth just under one cent ($9.99 ÷ 1,000). The player spends 800 gems, then asks for a refund.
| Spend order | Gems spent from each bucket | Paid gems left | Refund value |
|---|---|---|---|
| Bonus first | 100 bonus, 700 paid | 300 | 300 × $0.00999 = $3.00 |
| Paid first | 800 paid | 200 | 200 × $0.00999 = $2.00 |
The player and the purchase are identical in both rows, yet the refund differs by a dollar because of a rule most players never see. Neither order is wrong. It has to be written into the policy and reflected in the code, and support has to apply it the same way every time. "Bonus currency is spent before purchased currency" is a defensible, player-friendly choice. Whatever you pick, a support agent should be able to pull the ledger and calculate the refund without escalating.
One way to keep this manageable is to accept requests only for the most recent currency purchase and only inside a fixed refund window. That ties each refund to one transaction, which is how your processor will see it anyway.
Consumables, Cosmetics, and Bundle Refund Rules
Consumable Item Refunds
A consumable item refund is the easiest call: once it's used, it's gone. Boosts and energy refills deliver their value at the moment of use, and so does an opened loot box. The policy should say plainly that used consumables are not refundable. Unused consumables bought directly with money, such as a stack of revives still sitting untouched in inventory, can reasonably be refunded within the window and removed from the account. If your store sells randomized items, odds disclosure adds another layer. See loot boxes, odds rules and processor account risk.
Cosmetics and Permanent Unlocks
Skins and permanent unlocks don't get used up, so "used" needs a definition. You might define it as equipped at least once, or as held past the refund window. Pick a definition your telemetry can prove.
If the item was bought with currency rather than cash, the in-game item refund is really a currency refund. You return the currency to the wallet and remove the item. No money moves.
Bundles and Season Passes
Bundles produce the hardest refund arguments because players experience them as one purchase while the game delivers several. The fix happens at the point of sale: show the value of each component in the store listing. If a starter bundle includes a gem pack and a character, list a value for each, with the values adding up to the bundle price. When a refund request arrives, refund the stated value of the untouched components and point to the listing.
Season and battle passes unlock rewards over time. The simplest rule allows a full refund before any tier reward is claimed and none after. Pro-rating by tier is hard to explain and invites argument.
Clawing Back Currency on Refunded Purchases
Sometimes the money comes back before you can stop it. A chargeback succeeds, or an app store refunds a player who already spent the currency. Your policy needs a stated consequence, and your ledger needs to support it.
The clean approach is lot tracking. Each currency purchase is a lot, and each spend records which lot funded it. When a purchase is reversed, you know exactly which items it paid for.
From there, work in order. First remove whatever currency is left in that lot. Then revoke the items the lot paid for, where they still exist in the account. If the currency went on consumables that can't be taken back, set the wallet to a negative balance that future purchases or earnings repay.
Leave everything the reversed purchase didn't fund exactly where it is. A punitive response, such as wiping the account or banning the player, creates new complaints. It can also draw regulatory attention when the player was a parent disputing a child's charge. Before you write suspension into your terms, read whether you can ban a player for filing a chargeback.
Matching Your Policy to App Store and Web Shop Rules
Your policy has to work across every place you sell, and the rules differ by channel.
App store purchases. Apple and Google handle refund requests for purchases made through their billing systems. Your policy should say so and send players to the store's refund process instead of promising refunds you can't issue. Both stores offer ways to notify developers when a purchase is refunded or reversed. Wire those into your clawback logic, or store refunds will leave free currency in player wallets. Check each store's current developer documentation for the exact mechanism, because these tools change.
Web shop purchases. On your own web store you are the merchant. Your policy governs, and disputes land on your merchant account. More studios are adding direct web shops as app store rules loosen in some markets, a shift we covered in South Korea's fines on Apple and Google and what app sellers did next. Underwriters will read your web shop refund policy before approving you, and getting a video game merchant account approved walks through what they check.
Cross-platform wallets. If a player buys gems on iOS and spends them on PC, an Apple refund still has to reach the shared wallet. Tag every lot with its purchase channel so a reversal from any store or from your own processor finds the right currency.
Displaying the Policy so It Counts in Disputes
Under card network dispute rules, issuers generally give weight to a limited refund policy only if the cardholder saw it before completing the purchase. A link buried in the footer of your terms of service is weak evidence. Stronger placement looks like this:
- On the purchase confirmation screen, next to the buy button, show a one-line summary: "Unspent gems refundable within the refund window. Spent gems and used items are not."
- Link that line to the full policy.
- For higher-value purchases, add a checkbox or acknowledgment and log it with a timestamp and account ID.
- Repeat the summary in the email receipt.
Then keep the records an issuer will want when a dispute arrives: delivery logs showing the currency was credited, spend logs showing what it bought, login and device history for the account, and earlier undisputed purchases from the same account and device. Evidence that the account kept playing and spending after the "unauthorized" purchase can be strong support in a fraud dispute. For web shops, 3D Secure authentication on higher-risk purchases can also shift fraud liability away from you.
A Game Refund Policy Template You Can Adapt
Use this as a starting outline, not finished legal text:
- Scope: which storefronts the policy covers, and that app store purchases follow the store's refund process.
- Refund window: how long after purchase a request can be made.
- Currency: unspent paid currency is refundable; bonus and earned currency are not. Name the spend order.
- Items: used consumables and claimed pass rewards are not refundable. Define "used" for cosmetics.
- Bundles: component values are shown at purchase, and refunds cover untouched components at those values.
- Reversals: what happens to currency and items when a payment is refunded or charged back, including negative balances.
- Unauthorized purchases: how a parent or account holder reports one and what you'll do about it.
- Contact: the support channel, with a commitment to respond before the player reaches for a chargeback.
Have an attorney review the final wording for the markets you sell into.
Before you change any customer-facing text, check whether your ledger can do what the policy promises. It needs separate paid and earned buckets, a fixed spend order, lot tracking and channel tags. If it can't, fix the ledger first. When you're ready to run a web shop on processing set up for high-risk digital goods, see how MannyPay works with gaming merchants and high-risk merchant accounts, or request a free quote. A MannyPay specialist responds within one business day.
This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.


