A mobile game web shop strategy works when the store sits on player identity, CRM and offer design, not when it resells the same packs a little cheaper than the app store. Three questions help you assess whether a game webstore will pay for itself, and they all come before choosing a provider.

Who owns the offers on it. What your business case actually assumes you save. Where a web purchase lands in your reporting.

The project tends to get scoped the way it sounds. We're giving away 30% to Apple, we'll stand up a web shop, put the same packs on it a bit cheaper, keep the difference. Scopely is the company everyone cites as proof that works. In March its co-CEO Javier Ferreira told The Game Business the fee saving isn't a big driver of how they think about the business, and that he's never felt either Apple or Google restricted their ability to build direct relationships with players. The lower the fees the better, he said. Just not the point.

So what is? Scopely didn't build a cheaper checkout. It built a player relationship, and the store is one surface on it. Copy the checkout on its own and you leave behind the identity, the CRM, the offer design and the lifecycle system that make it work.

What they got right

Start with the store itself, because the design gives it away.

The MONOPOLY GO! web channel is the Tycoon Club and you can't just turn up. It's invite only: board level 10 and roughly a month of play, with no purchase anywhere in the entry requirement, so the gate is tenure rather than spend. Inside it, web purchases earn Loyalty Points that redeem for sticker packs, safes and rolls and advance a Tycoon Pass.

Sourcing on that, because it matters: Scopely's own account confirms the Loyalty Points. The gating and the redemption detail are GamesRadar's reporting. And the sharpest version of the claim, that the store pays in bonus currency rather than discount at roughly 4,300 rolls against 3,700 in game for the same money, comes from Stash, which sells webstores, so take that one at vendor weight.

That is a strange way to build a cheaper checkout. It is a very ordinary way to build the place a loyalty programme settles up, which is what I think it is.

Underneath sits Playgami, Scopely's own platform. A Scopely job posting describes it as covering payments, identity, CRM and web infrastructure together, coordinating outside providers rather than buying a webstore product off the shelf. That's one listing, so hold it as one data point. That reads like an org chart decision rather than a payments integration.

The order of events matters too, and most write-ups skip it. MONOPOLY GO! was already enormous before the store was widely available. Ferreira has said about 80% of Scopely's revenue, across its games rather than this one title, comes from people who have been playing more than a year, and back in March 2024, at the $2bn mark, he put MONOPOLY GO!'s lifetime marketing spend at under a quarter of revenue. Sensor Tower estimates reported for H1 2026 have D1 retention at 22.6% against 49,300 ad creatives in the same period, and Gradient's read of the live ops calendar has 57% of events running one to two days. Retention, cadence and creative volume are what make it work, and the store is downstream of that. The store didn't make the game work, which is the thing to remember if you're copying it. One caveat on the sequencing: the only dating I can find for wide availability is a fan wiki and a vendor blog putting it around October 2024, nothing first-party, so it's the thinnest evidence in the argument.

Two panels. What gets you into the Tycoon Club: board level 10, and roughly a month of play. What does not: having spent anything, or spending more. No purchase appears anywhere in the entry requirement, so the gate is tenure rather than spend.
The Tycoon Club gate is tenure, not spend

Where it breaks, when it breaks

I can't tell you most publishers have done this badly, and adoption is thinner than the noise suggests. Naavik took October 2025's US top-50 grossing iOS games and assessed them in mid-November: 24 of them, about 48%, had a mobile webshop available; 11, about 22%, had direct webshop links in-game; and just 3, about 6%, had direct checkout links in-game. So what follows is how this goes wrong when it goes wrong, not a verdict on the field.

If there's a D2C line on your roadmap this year, there's a fair chance some version of the 30% fee-saving argument is in the business case behind it. From there it tends to land with payments or platform engineering rather than with the people who run the events calendar. Worth asking who owns the offers on it, the loyalty mechanic and the merchandising cadence. If no name comes back for those three, that's the gap, whoever the store reports to.

It ships as a price list rather than a progression system, so it converts on discount. Michal Korek, who took a webstore from 32% to 70% of revenue, puts the ceiling on a discount-only proposition at a fifth to two-fifths of payers. And a discount trains payers to wait for cheaper, which is a tax on every offer in the game from then on. Korek's fix was to swap a 10% discount for a 10% value bonus. Those aren't the same trade, and the difference is the point: on a £100 pack, the discount takes £90 and hands over the usual goods, while the bonus keeps the £100 and hands over more of them. The headline price survives, the cash survives, and you pay in virtual goods instead. Whether that is better for you depends on what the extra currency does to your economy, which is a question for whoever owns it.

Two panels comparing the same pack. A 10% discount takes £90 for the usual goods, so you hand over £10 of revenue and teach payers to wait for cheaper. A 10% value bonus keeps the £100 and hands over more of the goods, so the headline price and the cash both survive and you pay in virtual goods instead.
A discount and a bonus are not the same trade

Then the business case, which is the bit I'd expect to sink most of these rather than the build. If somebody has handed you a model with 30% in it, the number isn't wrong so much as it's being applied to the wrong base. You don't save the platform fee on all of your revenue. You save part of it on the share you actually move, and that share decides how much reaches the P&L. Naavik works it through: if 10% of sales improves margins by 26 points, going from a 30% platform fee to 4%, that translates to a 2.6 point bump to company-wide margins, assuming unchanged sales and other costs. Change the inputs and you change the answer, but the shape holds: a transaction-level fee saving is a fraction of thirty by the time it reaches the P&L.

A full-width revenue bar with only the first 10% shaded, marking the share that actually moves. On that slice the fee goes from 30% to 4%, a 26 point margin gain, which lands as about 2.6 points of company-wide margin. Naavik's worked example, assuming unchanged sales and other costs.
Why thirty per cent does not arrive as thirty per cent

What the companies furthest along disclose is a separate exercise. Playtika's DTC share went from 7% in 2018 to 27% in 2024, and its gross margin moved from 71% to 73%. Stillfront's moved 78% to 83% as D2C reached 49%, with share figures sitting between 44% and 49% depending on the source and the base, so not a clean rising line.

Those aggregates don't tell you how much of the movement DTC caused. Six years of company gross margin carries a lot besides a payment rail, and Naavik reads Playtika's revenue growth over the period as mostly tracking its acquisitions rather than DTC.

Stillfront is the interesting one. On Naavik's reading of its reporting, the company says plainly that the migration is negative for bookings and net revenue and accretive only to gross profit, and guides to accepting that at the cost of some bookings growth. I haven't read Stillfront's own filing, so that's Naavik's characterisation rather than a quotation.

Sell this internally on thirty and you've set it up to be judged a failure at whatever it actually returns.

The cost side is worse than the headline too. The only published all-in example I can find for game webstores is a vendor's own and it lands near 14%. Unity's model separately assumes you hand the player back 10% to 15% as incentive, and says out loud that it excludes tax compliance, chargebacks, support and CRM. Two illustrations from two vendors, so don't stack them and call it a model. I haven't found a published model that includes headcount, so I'd build that cost into your own.

Above, a single box labelled the rate, which is what the business case usually counts. Below, that same box followed by card fees, FX, chargebacks, refunds, tax, support, CRM, and a dashed box for headcount. One vendor's all-in illustration lands near 14%, and a different vendor separately assumes a further 10 to 15% handed back to the player as incentive.
The headline rate is one line in a longer stack

And the bottleneck may sit further up than the checkout. Korek found 71% of webstore visitors never saw the main page, which in his case made discovery and offer rotation the constraint rather than payments. That's one operator, so take it as a reason to check your own funnel. Nor does the line only go one way: Lancaric's D2C guide, from filings, has Ten Square Games flat for a year at 19% to 20% and Nexters going backwards, 41% to 36%, while the category grew.

The timing problem underneath all of it

Scopely's first web store, for Star Trek Fleet Command, is reported to have launched in September 2021. MARVEL Strike Force followed in February 2022. Both dates come from a vendor blog rather than from Scopely, so treat them as reported rather than confirmed, though Scopely's own help centre does document the Star Trek store as buying in-game content directly from Scopely in a browser.

Take September 2021 at face value and it sits three and a half years before the April 2025 contempt ruling. Read alongside Ferreira saying the platforms never restricted their ability to build direct relationships, it's hard to argue the rules were the gate for them. They started when starting was harder.

Meanwhile the thing the late movers are timing off isn't settled. What was ruled is that Apple can't restrict how you link out in the US. What's still open is whether it can charge for it, and at what rate: the Ninth Circuit vacated the blanket zero-commission provision in December 2025, and on 11 August 2026 the court denied Apple's motion to stay remand and began proceeding to set a rate. Apple is charging 0% on US link-outs in the meantime, and its proposed 15% is a proposal no court has approved. Outside the US it's already priced, with Apple's EU terms from 1 October 2026 running link-out at 15%. The full sequence, with dates, is in the sources.

So the US 0% is a litigation position rather than a settled rule. If your business case gets its margin from 0% in one territory while a rate is being set, it's worth knowing whether anyone has priced that date.

A timeline. Star Trek Fleet Command web store September 2021 and MARVEL Strike Force February 2022, both reported by a vendor blog. Apple held in contempt 30 April 2025, and the Ninth Circuit vacating the blanket zero-commission provision 11 December 2025, both ruled. From 11 August 2026 the court is proceeding to set a rate, still open, with Apple charging 0% meanwhile. Alongside: Apple's proposed US schedule of 15% standard which no court has approved, and EU terms in force 1 October 2026 running link-out at 15%.
Scopely started before the rules changed, and the rules are not settled

What I'd do

Three things, in this order, and the order is most of the value.

Decide who owns the offers before you decide what's on the store. This goes first because it sets everything else. Engineering can build you the store. What it won't do on its own is rotate the offers, run the loyalty mechanic and merchandise the thing every week, because that isn't the job. Put those three with whoever runs your events calendar and they happen on a cadence that already exists. If you haven't got a live ops team, same decision, different answer: give it to whoever writes the offers, even if that's one person. It doesn't need a new team, and a new team is the fastest route to a store nobody merchandises.

Rebuild the business case on fully loaded cost and set the target on gross profit, not channel share. Take the processing rate, add card fees, FX, chargebacks, refunds, tax handling, support load and whatever CRM time this needs, then add whatever you give the player back to move them. Then work out what share of revenue you realistically expect to shift, because that share decides how much of the saving reaches the P&L. Agree the gross profit number with finance before you build rather than after. You can move half your revenue to web and watch bookings and net revenue fall while gross profit rises, which is what Stillfront reports happening to it, as Naavik reads its filings.

Build the path back for the data before you move the money. A web purchase doesn't come back through the app store transaction the way an IAP does, so somebody has to deliberately build the route back into your measurement stack. I'm reasoning from how the plumbing works rather than from a study, because I couldn't find one I'd stand behind.

What I have instead is the same problem from the other side. At Owners Club we hadn't integrated AppsFlyer early, which is an ordinary small-studio decision and an expensive one: App Store IAP attribution was genuinely hard, and the fix wasn't a dashboard. It was deliberately building in-app events and trigger events so there was something to optimise spend against in the first place. And when Firebase and the store numbers disagreed on first-time user experience, which they did, we chose Firebase as the working source and used it consistently.

Different business entirely, same shape: at P&D Group I ended up building the sales tracker myself, replacing a CRM they were paying for that wasn't putting ad spend and acquisition in the same view as what actually converted.

Neither of those is a webstore. The decision is the same decision: when revenue or behaviour stops arriving through the channel your reporting assumes, you either build the path back on purpose or you spend a quarter arguing about whose number is right. The narrower version is enough on its own: moving transactions off-platform creates measurement and reconciliation work that didn't exist before. Settle who owns web revenue in your reporting now rather than two quarters in, which is when somebody asks what UA is actually returning. If you run a full measurement stack with an MMP and a ROAS model, this is a question of attribution ownership. If you don't, it's simpler and more urgent: decide which single report web revenue appears in before the first pound moves.

Two absences before a number goes in a board pack, and they cut opposite ways. I couldn't find a published holdout test, geo split or matched cohort study for a game webstore anywhere. Equally I couldn't find a public case of one being shut down, or of Apple penalising featuring or ranking over one. Not finding them isn't evidence they don't happen. In FastSpring's own commissioned survey with Omdia last year, 42% of studios that hadn't shipped D2C feared damaging platform relationships, which is a fact about what people believe rather than about what Apple does.

On scale, since it always comes up: Sensor Tower estimates, US, June 2026 put the web shop at $52.6m of $143m. Single-sourced, so hold it loosely. It's the number everyone quotes and the least useful one here.

Before you build it

The three from the top, sharpened. If you can't answer them today, the project isn't ready to start.

Who owns the offers on the store, by name, and do they also own the events calendar?

What does your business case assume you save, and is that a fee rate or a gross profit number?

When a web purchase happens, where does that event land in your measurement stack?

Where I come in

Those three questions are the work, and they are where I can help. Pressure-testing the business case before it goes to the board. Putting a name against offer ownership and the merchandising cadence. Designing the offer structure so the store pays in value rather than discount. Settling where web revenue lands in your reporting before the first pound moves through it. All four are cheaper to get right before you build than after.

If those questions landed uncomfortably, how I work through this with gaming teams is the next thing to read. If you'd rather see where you stand first, the Growth Readiness Scorecard is free, ungated, and gives you the full read-out. And if you'd rather have this done on your own numbers than read about Scopely's, that's what the Growth Diagnostic is: a structured read of your acquisition, offer design and lifecycle system, and a written set of moves in the order I'd make them.