Browser games don’t process payments themselves. The platform a game runs on (a web portal, messenger or app store) provides the payment method; the game calls that platform’s purchase API, the platform charges the player and pays the developer a revenue share. Consumable items (boosters, lives) and permanent items (skins, levels) are the two common purchase types.
At a glance
| Fact | Value | Source |
|---|---|---|
| Purchase types supported by most platforms | consumable and permanent | wiki.playgama.com |
| Who actually processes the payment | the hosting platform | wiki.playgama.com |
| Server-side check needed before granting an item | verify the payment token | wiki.playgama.com |
A browser game does not run its own payment processor. It runs inside some platform – a web portal, a messenger, a social network or an app store webview – and that platform owns the checkout: it shows the price, collects the player’s card or wallet, converts currency, and later pays the developer a share of what it collected. Your game code only calls that platform’s purchase API and reacts to the result (granted, cancelled, pending).
The most common integration path is an SDK wrapper that adapts your game to whichever platform it runs on, so you write one purchase call instead of one per platform. Playgama Bridge works this way: it is an SDK wrapper over the platforms’ own payment APIs, not a payment system of its own, and money goes through the platform.
How do consumable and permanent items differ?
- Consumable: single-use, spent and gone – boosters, lives, in-game currency.
- Permanent: stays with the player – skins, unlocked characters, unlocked levels.
Never trust the client alone. A purchase result reaching your game code can be faked or replayed, so verify it server-side: check the signed token (e.g. security token) is valid and unmodified, then call the platform’s verification API to confirm the order was actually paid, and only then grant the item. Do this after your ad monetization and core game loop are already stable, since IAP is optional but often the highest-revenue feature for games that fit the model.
Sources
- Playgama wiki: In-game purchases
- Playgama wiki: Payments
- Playgama wiki: In-game purchases JWT verification
- Playgama Bridge (GitHub)
- Playgama Ad
Related questions
Can I add my own payment processor instead of the platform’s?
Not through a platform-integration SDK like Bridge – it wraps each platform’s own payment API, so the money always moves through the platform, not a separate processor you control.
Should I verify purchases on the client or server?
Server-side. Check the signed token is valid, then confirm with the platform’s verification API that the order was actually paid, before granting the item.
Do ads and in-game purchases conflict?
No, they’re complementary. Most teams stabilize ad monetization and the core game loop first, then add purchases for games where players are willing to pay.
Last updated: 24 September 2026