A player taps "buy on the web", lands on a page, and is asked to log in. Which account? The game account has no password; it was created with Game Center or a Google sign-in two years ago. Half of them close the tab. The store didn't fail on price or design; it failed on the first screen.
The fix isn't a better login screen. It's no login screen. The game the player just left already knows exactly who they are.
The design: the backend signs, the store trusts
- The game asks your backend for a player token. The request goes through the game's own authenticated session, so your backend knows the player.
- Your backend signs the token. It contains your player ID, expires within five minutes, and is signed with a private key you hold. You register the public key once in the Studio (player tokens).
- The game opens the store with the token.
openStore(playerToken)for the store, orpurchase(sku, playerToken)for one pack. - The store opens signed in. The player sees the pack, the price and the checkout, in the game's look. Nothing to type.
- The order arrives at your backend as a signed
order.paidwebhook with the same player ID, and your backend grants it.
There's no password because there's nothing to protect with one: the token can't be used to log in to anything, only to buy a pack for that player, for the next few minutes.
The token rules
| Rule | Why |
|---|---|
| Expires within 5 minutes; anything longer is rejected | A leaked token is useless almost immediately |
| Bound to one player ID | It can't buy for someone else |
| Signed by your private key, verified against the public key in the Studio | The store can't be fooled by a forged token |
| Minted only by your backend, behind your login | The game client never holds a signing key |
| Optional attributes (level, spender tier, country, new player) | Targeted offers, signed by you, so the store never trusts the client's word |
| Key rotation: add the new key, switch, wait five minutes, remove the old | No downtime, no forced re-login |
The outside-the-game case
Not every visit starts in the game. A push, a newsletter or a Discord post sends the player to a link, and there's no token yet.
Send the link through the game. A Universal Link (iOS) or App Link (Android) opens the app, which asks the backend for a token and opens the store. The player never sees a web login; they're signed in to the game, which is the only account they have. The deep links guide covers the return path, and the same association files handle the entry.
Where the app isn't installed on that device, you have a real choice: a one-time code by email is the least bad fallback, and it should be the exception that your analytics show is rare, not the default that every visitor meets.
What this does to conversion
The order of drop-off in a web store is almost always: login, then "is this really the game's store?", then "is it a better deal?", then checkout (conversion checklist). Removing the first step is the biggest single change you can make, and it's free: it's three lines in the game and one endpoint on your backend.
Appcharge's post on the subject (January 15, 2025) lists the login problem first among four, recommends auto-login when the player is already signed into the game, and reports a revenue increase of 10% or more for some games after adding a one-time-password login, from its own experience rather than a study. Auto-login is the right recommendation; the version above goes one step further and makes it the only login there is.
What to tell support
Three sentences cover every ticket:
- "You don't need a password. Open the store from inside the game and you're already signed in."
- "If the store asked you to sign in, you opened it outside the game. Open the game and tap the store button."
- "Your purchase is tied to your game account, the same one you play on. If it hasn't arrived, tell us the order ID on the receipt."
Create your store free. No card needed to start; 3.9% per successful payment.