In-game purchases and virtual currency: how the money actually settles

When a player taps to buy a bundle of coins or an unlock, it feels like an instant sale. In cash terms it is anything but. The payment flows to the mobile app store or console storefront, the storefront takes its cut, and what is left reaches you weeks later on the storefront's own payout cycle. The number you watch climb in your live dashboard is a booking; the number that funds your studio is the cash that settles afterwards, and the two are never the same on any given day.

For a studio living on in-app purchases, microtransactions and virtual-currency sales, understanding that gap is the difference between a healthy cash position and a nasty surprise. The storefront cut, the payout lag, the way virtual currency defers revenue until it is spent, and foreign-currency settlement all sit between what players pay and what you can actually use. This guide walks through how that money really settles, so you plan around the cash rather than the bookings.

Bookings are not cash: the storefront cut and payout lag

Every in-app purchase settles through the storefront, not through you. The player pays the mobile app store or console storefront; the storefront deducts its commission, commonly cited around 30% for larger developers and reduced (often around 15%) under small-business programmes or for some subscriptions; and it pays you the remainder. So the gross a player spent is already larger than the proceeds you will ever see.

On top of the cut sits a timing lag. Storefronts typically report sales in monthly financial statements and pay out on a delayed cycle, so cash for this month's purchases lands weeks after the month closes. That means three different numbers exist at once: the bookings ticking up in real time, the recognised revenue net of the cut, and the cash that actually arrives later. Plan spending against the cash that has landed, not the bookings on the dashboard, because the dashboard is always running ahead of your bank balance.

Holdbacks, reserves and net-of-refund payouts

The lag is not the only thing standing between bookings and cash. Storefront payouts are reported net of taxes and of any refunds or chargebacks, so a refund granted this week reduces a future payout rather than producing a separate bill. A wave of refunds after a content drop can quietly shrink the next deposit below what the period's gross suggested.

Some storefronts also apply a holdback or reserve, withholding a portion of proceeds against expected reversals and releasing it later. The effect is that early cash is conservative by design and trails your bookings even more than the headline cut and lag imply. The practical takeaway is to reconcile each payout against the period it covers and against the refunds and adjustments applied to it, so you can see exactly how bookings became cash. Without that, a lighter-than-expected deposit looks like a problem when it is just the normal mechanics catching up.

Virtual currency: money in now, value delivered later

Virtual currency adds a second layer. When a player buys coins, gems or premium currency, they have paid for something they will spend over days, weeks or months. The cash (net of the storefront cut) may arrive on the usual cycle, but for accounting purposes the proceeds are often treated as deferred revenue and recognised as the currency is consumed, in line with revenue-recognition standards, with estimated service periods reviewed title by title.

That creates a gap between cash and earned revenue running the opposite way to the payout lag: you may hold cash for currency players have not yet spent. It also complicates refunds, since a player may request one against currency partly used, and prorated refunds reduce both the deferred balance and your eventual proceeds. You do not need to be an accountant to run a studio, but you should know that virtual-currency cash is partly a liability you still owe in gameplay, not all spendable margin. Treat large deferred balances with that in mind when judging how much is genuinely free to spend.

Foreign-currency settlement and the FX layer

Players buy across the world, but storefronts settle to you in a defined currency, converting from the sale currency at their own rates when they pay out. If your players are global and your storefront pays you in USD or EUR while your costs are in another currency, every payout carries an FX conversion you did not choose the timing of, and the rate applied is the storefront's, on the storefront's date.

For a studio that bills players in dozens of currencies, this matters twice: once for the rate itself, and once for control. Being forced to convert on the storefront's schedule means you take whatever rate applies on payout day, even if it is poor and even if you would rather hold that currency to pay a contributor or supplier in it. The alternative is to receive payouts in their native currency and convert on your own timeline, matching conversions to when you actually need the money and to rates that suit you, rather than converting everything reflexively the moment it arrives.

How Altery fits

The core problem with in-app purchases and virtual currency is that bookings, recognised revenue and cash move on different clocks and often in different currencies. An Altery account is built around holding and reconciling that. You can receive storefront in-app-purchase payouts in their native currency into multi-currency accounts holding USD, EUR and GBP, then convert on your own timeline rather than taking the storefront's rate on its payout day, so FX happens when it suits your cash needs.

Real-time balances show what has actually settled versus the bookings you are watching elsewhere, and categorised spend with balance alerts helps you reconcile each payout against the period and the refunds behind it, so a lighter deposit is explained rather than alarming. If you carry large virtual-currency balances that are partly still owed to players, ring-fencing money in a dedicated pot lets you separate genuinely free cash from what is effectively a liability, and multi-entity management keeps several titles' settlements apart. Altery is not a bank and provides general information, not advice.

Frequently asked questions