You've finished your game. Or finished enough of it to start thinking about monetization. You want to charge for something — an item unlock, a DLC chapter, a supporter skin, access to a hard mode. Something small. Something that feels right at $0.50, maybe $1.
So you open the Stripe docs.
And you immediately run into the problem nobody warns you about.
The Minimum Transaction Problem
Stripe charges 2.9% + $0.30 per transaction. That's the standard rate for online card payments in the US, and it's roughly in line with every major payment processor.
On a $10 sale, that fee is $0.59. Fine. On a $1 sale, it's $0.33. You keep $0.67. Still workable, barely.
On a $0.50 sale? The fee is $0.315. You keep $0.185. You're giving away more than half the revenue to the processor before taxes, before your hosting costs, before anything else.
At $0.25, it's not worth processing at all. The fee exceeds the transaction value.
This is why micropayments in games are almost universally done through virtual currency — coins, gems, tokens — rather than direct payment. You charge $4.99 for a bundle of 500 game credits, then price items in credits, so every real-money transaction is large enough to make sense for the processor.
It's a completely reasonable engineering solution to the Stripe problem. It's also a complete layer of abstraction, friction, and overhead that didn't need to exist. The player wanted to spend fifty cents. You had to build an entire virtual economy to make that possible.
The App Store Problem
If you're shipping on iOS or Android, you already know the 30% problem. Apple and Google both take 30% of gross revenue — down to 15% for developers under $1M/year on Apple, but still a significant cut.
On a $0.99 in-app purchase, you keep $0.69. From that $0.69 you pay Stripe (or a comparable processor) to handle the actual transaction: another 2.9% + $0.30. You're keeping maybe $0.35 on a dollar the player spent.
This is why small in-app purchases are rare in indie games. Not because developers don't want to offer them, but because the math doesn't work below a certain price point. You're giving up more than half your revenue in fees before you've paid for a single server.
The platforms argue they provide distribution, discovery, and payment infrastructure worth 30%. For some developers — especially mobile-first developers building games for massive audiences — that's probably true. The App Store's install base is real.
But for an indie game developer with a niche audience, a small game, and a player who just wants to support you by buying a $0.50 cosmetic? You're paying 30% for distribution you might not need and infrastructure that's actively hostile to small transactions.
What Crypto Actually Solves Here
I'm not going to make the case that crypto payments are for everyone. They're not. Most players don't have wallets. Most games don't have audiences that overlap with the crypto-curious. If you're building a mainstream mobile game, this conversation is not for you.
But there's a category of indie game developer — smaller audiences, more technical players, direct relationships with their community — where crypto micropayments are genuinely interesting. And the reason is simple: the fee structure at small amounts is completely different.
A KOTO transaction costs fractions of a cent in network fees. There's no processor taking $0.30. There's no platform taking 30%. The player spends 50 KOTO (roughly $0.50 at current rates) and the developer receives 50 KOTO minus a trivially small network fee.
That's it. That's the whole transaction.
At $0.50, you keep essentially all of it. At $0.25, same. At $0.10, same. The fee structure doesn't change based on transaction size, because there's no intermediary whose business model depends on taking a percentage of every payment.
For micropayments specifically — the $0.10 to $1.00 range where traditional payments completely fall apart — crypto is structurally better. Not marginally better. Categorically better.
The Integration Problem (And What We're Doing About It)
The reason crypto payments haven't already taken over indie game monetization isn't fees. It's integration friction.
Building a native crypto payment flow into a game has historically required: choosing a coin, running or accessing a node, generating addresses, monitoring the blockchain for payment confirmations, handling edge cases like partial payments and transaction delays, and building all of that into your engine.
That's weeks of engineering work before your first transaction. For a solo indie dev, that's often not a trade worth making.
GameGlass is a hosted widget. You get an embed — an iframe with a JavaScript callback — that handles all of that for you. The player sees a QR code and a timer. When payment confirms, a postMessage fires to your game and you unlock the item. That's the integration.
It's designed to work with any engine that runs in a browser (Phaser, GDevelop, Construct, RPG Maker MZ/MV) and any engine that can open a webview (Defold, GDevelop native, GameMaker HTML5). The crypto complexity lives inside the widget. Your code just listens for a message.
Who This Is Actually For
I want to be clear about the use case, because there's a version of this pitch that overpromises.
GameGlass isn't going to replace your Stripe integration for a mainstream game. It's not going to let you accept KOTO from players who've never heard of CPU mining.
What it does is give you a second payment option that works well for:
- Games with technically-adjacent audiences — developers, miners, people in open-source communities, retro enthusiasts — who are more likely to already have a wallet
- Supporter tiers and extras — cosmetics, supporter badges, naming rights, bonus content — where the transaction is as much about backing the developer as buying an item
- Small-amount unlocks where Stripe's fixed fee makes direct payment unworkable
- Developers who want an option outside the app store ecosystem for at least part of their revenue
This isn't the payment layer for a mass-market mobile game. It's the payment layer for the kind of game where the developer and the player are both a little niche, a little technical, and a little tired of giving 30% to a platform for the privilege of a transaction.
The Honest Version
Building a CPU coin payment layer for indie games is a bet on a specific future: that the overlap between "people who mine CPU coins" and "people who buy indie games" is real and growing, and that lowering the transaction cost to near-zero is enough to unlock spending that wasn't happening before.
I think that bet is correct. I think there are miners sitting on wallets full of KOTO and Verus and Monero who would genuinely spend some of it on games they like, if the spending were easy. And I think there are indie developers who would rather receive 100% of a small transaction than 70% of nothing.
But I'm also a developer building something I want to exist. So take that for what it is.
If you're an indie dev and this sounds interesting, get on the waitlist. Tell us what engine you use and what you'd want to charge for. That data shapes what we build first.