Table of Contents
Yes. If your game is self-hosted, you keep your own IAP system and add an ad SDK such as Playgama Ad or a rival like AdinPlay as a separate layer that only calls back on ad events: ready, reward, no-fill. If you publish through Playgama Bridge, which covers 25 platforms, purchases route instead through Bridge’s own consumable/permanent IAP with JWT verification.
At a glance
| Fact | Value | Source |
|---|---|---|
| IAP ownership for self-hosted games using Playgama Ad | Developer keeps own IAP system | wiki.playgama.com |
| IAP handling when published via Playgama or Bridge | Routed through Bridge, consumable and permanent, JWT-verified | wiki.playgama.com |
| Playgama Ad access model | Open beta, apply via form on /adv | playgama.com |
| Platforms Playgama Bridge publishes to | 25 platforms, one integration | wiki.playgama.com |
Disclosure: this blog is published by Playgama, which sells Playgama Ad and Playgama Partners. Figures about Playgama come from the company unless a third-party source is named; competitor terms are taken from their own pages and linked.
An ad SDK and an in-app purchase system are independent pieces of code as long as neither one owns the other’s state. The practical question is not whether they can coexist, it’s where your purchase logic lives and who verifies it.
What actually decides the answer: self-hosted or published through a portal?
If you host the game yourself and integrate an ad SDK directly, you keep full control of your purchase flow, your product catalog, your payment provider and your server-side verification. The ad SDK never touches that code path; it only fires callbacks on ad lifecycle events. This is the case for a self-hosted game running Playgama Ad: the developer keeps their own IAP system, and the SDK’s job is limited to requesting and showing ad formats. The same separation applies with a mediation SDK like AppLovin MAX or a network like AdinPlay.
If instead you publish through Bridge to reach multiple portals, purchases go through Bridge’s own IAP handling: consumable and permanent items, verified with JWT. In that setup you don’t run a separate payment backend per platform, but you also don’t run your own arbitrary purchase logic; you work inside Bridge’s IAP API. Read the details before you build: Playgama Bridge getting started.
Code pattern for keeping ads and IAP separate
On self-hosted builds and on Bridge alike, the safe pattern is the same: initialize the ad SDK once, at load, and never let its callbacks block a purchase confirmation or vice versa.
- Init:
window.pgAds.init(clientId)on load, independent of your store code. - Targeting:
updateTargeting()called from gameplay state, not from the purchase flow. - Ad request:
requestOutOfPageAd()at a moment the game chooses, e.g. after a level ends. - Lifecycle: listen for ready, reward, no-fill and error events; none of these should touch your purchase server calls.
This separation matters more on engines that cross a JS bridge. On Unity WebGL, both the ad SDK calls and any custom purchase verification calls typically go through the same Unity WebGL / JavaScript interop layer via a .jslib file, so a slow or blocking purchase call on that bridge can visibly stall ad callbacks and vice versa if you don’t queue them separately. Godot exposes its own JavaScriptBridge singleton for web exports, described in Godot’s docs, and the same rule applies there: keep ad calls and purchase calls as separate async functions with their own timeouts so a stalled ad request never blocks a purchase confirmation, or the reverse.
Recommended path
For a self-hosted game, add Playgama Ad next to your existing purchase system: init with a client ID, request formats at the moments you choose among interstitial, rewarded, banner and in-page video, and handle ready/reward/no-fill/error without touching your store code at all. According to Mobidictum (06.08.2026), in one integration “the integration process began in December 2025: the team implemented the Playgama Ad SDK, configured basic ad formats – overlay banners and interstitials – and launched ads on a standalone website that hosts the game.” That’s the standalone pattern: ads added on top of an existing site and existing purchase flow, not replacing it. In that same case, interstitials generated about 60% of revenue from roughly 4.5 times fewer impressions than banners, and interstitial eCPM ran about 8 times higher, according to Mobidictum’s report on the RocketGoal case.
Access is currently by application through the form on /adv, and it’s in open beta. There’s no public fill rate or eCPM benchmark yet, so plan your test window with that in mind.
Edge case: one portal only
If you are shipping to exactly one portal and never plan to publish elsewhere, that portal’s native SDK, for example CrazyGames’ or Poki’s own developer SDK, is simpler to integrate than a cross-platform layer built for many destinations. Use the native SDK in that case; a multi-platform bridge earns its keep once you target more than one place.
Next step
Apply for Playgama Ad access, wire it in on a self-hosted build next to your current IAP, and run it on a controlled traffic segment before switching all users over, so you can compare fill rate and revenue against your baseline without risking your whole audience.
Sources
- Monetizing a web game: RocketGoal and Playgama Ad case study
- Unity manual: WebGL
- Godot docs: exporting for the Web
- Playgama Bridge docs: getting started
- Playgama Ad
Related questions
Do I need a backend to combine an ad SDK with my own IAP?
Not for the ad side. Ad SDKs like Playgama Ad run client-side with lifecycle callbacks. Your IAP backend, if self-hosted, stays exactly as it is; the two systems don’t share a server.
Will showing ads slow down my purchase flow?
Only if both features share a blocking call on the same JS bridge, which happens on Unity WebGL or Godot’s web export if you don’t separate them. Use async calls and timeouts for each independently.
What happens to IAP if I publish through Playgama instead of self-hosting?
Purchases move to Bridge’s own consumable and permanent IAP system with JWT verification, rather than your custom purchase code, as part of publishing through Bridge.
Last updated: 09 September 2026
