Aug 1, 2026 · 4 min read · GameMantra Team

Cross-platform play and your single-currency economy

Studios are building one game across phone, PC and console. One shared currency across stores with different fees and different players is harder than it looks.

Studios are increasingly building unified ecosystems intended to run across mobile, PC, console, handheld and cloud simultaneously, rather than shipping a phone-only product. (Gameindustry.com)

The design and technical work that gets planned for is account linking, input handling, and performance parity. The economy question tends to be settled by assumption — one currency, shared across platforms, the same everywhere — and that assumption has consequences that surface after launch.

The same currency costs different amounts to sell

The first problem is that the platform takes a different cut in different places, and your currency does not know that.

A unit of premium currency sold on one storefront nets you a different amount than the same unit sold on another, or on your own web store. If the price is identical everywhere, your margin varies by platform, and your revenue mix now depends on where players happen to buy rather than on anything you decided.

The naive fix is to price differently per platform so that net revenue matches. That works arithmetically and creates a visible inconsistency: the same currency costs more on one device than another, for the same player, in the same game. Players notice this quickly in a cross-platform title, because they are by definition using more than one device.

The alternative is to accept variable margin and price consistently. That is usually the better player experience and it means your economics depend on platform mix, which you should then actually track rather than discover later.

There is no clean answer here. What matters is that it is a decision rather than something that happens to you, because the version that happens to you is the one where nobody notices the margin difference for a year.

Earn rates that were tuned for one context

The second issue is subtler and does more damage. A currency earned through play was balanced against a specific session pattern, and session patterns differ sharply by platform.

Mobile sessions are short and frequent. Desktop sessions are longer and less frequent. If earning is per-session, mobile players earn more. If earning is per-unit-time, desktop players earn more. Either way, one platform's players accumulate faster than the other's, and they are spending in the same shared economy.

This is fine until it is not. In a game with any competitive or comparative element, the faster-earning platform becomes the advantaged one, and the community works this out well before the studio does. In a purely single-player game the effect is milder but still means your pricing is correct for one platform and wrong for the other.

Balancing earn rates per platform is possible and immediately raises a fairness conversation. Balancing them per session structure — designing earning around what a player accomplishes rather than how long they play — sidesteps most of it, and is worth deciding before rather than after.

Shared wallets and where purchases happen

A shared currency across platforms means a player can buy on one and spend on another, which is what players want and what creates the third complication.

If one platform's storefront takes a smaller cut, players will learn to buy there and play elsewhere. That is rational and generally fine — many studios actively encourage it. It does mean your purchase volume and your engagement volume live on different platforms, and any per-platform analysis that assumes they align will be wrong.

It also means platform-specific rules about what you may advertise and where apply to a currency that is spent everywhere. Directing players to a cheaper storefront is subject to different constraints depending on where the player is at the time, and those constraints have been moving.

The practical requirement is that the economy is modelled at the account level rather than the platform level, with platform recorded as an attribute of each transaction rather than as a partition. That sounds obvious and is frequently not how it gets built, because the mobile version usually existed first and the data model inherited its assumptions.

See how we model economies across platforms →

Deciding before it is expensive

The choices that are cheap now and costly later are all about identity and record-keeping rather than about design.

Whether the wallet belongs to the account or the platform install is the first, and it is close to irreversible once players have balances. Account-level is almost always right for a cross-platform title and is painful to retrofit.

Whether every currency transaction records the platform it happened on is the second. Adding the field later means every historical row lacks it, and the questions you will want to answer are all comparative across platforms.

Whether prices are one global set or per-platform is the third, and it is the one worth deciding deliberately because both answers are defensible and the drift version — where prices diverged because someone fixed a rounding problem on one store — is the one nobody can defend.

None of these are hard problems. They are cheap decisions with expensive reversals, which is exactly the category that gets skipped when the cross-platform work is framed as a technical port rather than as an economy change.

Talk to us about cross-platform economy design →

Share this post

See what this looks like for your game.

SDK for Unity and Unreal. A 20-minute call to walk you through it.

Book a demo