PlayKovo Mobile Bridge Result Statuses: Rewarded, Cancelled, Cooldown

If your game is built for the PlayKovo mobile app, ads are requested through window.PlayKovoMobile. Every call returns a status, and the documentation lists them: rewarded, cancelled, unavailable, cooldown and error for rewarded requests, and shown in place of rewarded for interstitials. This post goes through what each means, what your game should do and the cases that lose rewards or trap players.

There are two entry points. Since SDK 2, window.PlayKovoSDK detects the PlayKovo app and routes ads, cloud saves, pause and sound by itself, and a new game needs only playkovo-sdk.js. The older mobile bridge, window.PlayKovoMobile, stays supported for games already built on it, and also receives pause, resume, mute and unmute through on(). This post covers the bridge. If you are starting new, read SDK 1 or SDK 2 first.

The documentation lists the five status values by name and does not define each in detail, so the "meaning" column below is the natural reading of the names. Confirm anything you depend on with your own test.

const result = await window.PlayKovoMobile.showRewarded({
  placement: "extra_life",
});
if (result.status === "rewarded") {
  grantExtraLife();
} else {
  showRewardUnavailable();
}

Status	Meaning	What your game does
rewarded	The player completed the ad	Grant the reward, once
cancelled	The player closed it before the end	No reward; let them continue without
unavailable	No ad could be shown, for example in a browser or in a game not enabled for mobile	No reward; explain that it is not available now
cooldown	Too soon after the last request	No reward; try again later or hide the button for a while
error	Something failed	No reward; keep the game working

Only the first row grants anything. The documentation puts it directly: grant the reward only after the status is rewarded, and unavailable is "expected behavior, not a reason to grant the reward". A browser, a local desktop run or a game not enabled for mobile returns unavailable.

const result = await window.PlayKovoMobile.showInterstitial({
  placement: "level_complete",
});
if (result.status === "shown") {
  startNextLevel();
} else {
  startNextLevel(); // Never block gameplay on an ad.
}

Both branches call the same function on purpose. An interstitial gives the player nothing, so no status should keep them from moving on. The comment in the documentation is the rule: never block gameplay on an ad.

The documentation says the native app, not the game, ultimately enforces eligibility and cooldowns. Your game may not know that a request would hit a cooldown until it asks. That is why cooldown is a status and not something you track yourself. Do not build a second timer to guess the answer; it will disagree with the app.

The bridge also supports events, for instance on("rewarded:rewarded", ...) to run code when the reward is earned. Use one style consistently. If you use both the awaited result and an event for the same reward, you can grant it twice. Pick one place where the reward is granted and make it idempotent: set a flag like rewardGranted for that request and ignore a second signal.

• Do not show a dead button. If rewarded ads are unavailable, hide or disable the button, or show a short message.
• Disable the button while a request is open. This stops double taps from sending two requests.
• Use the player's wording. "Watch a short video for an extra life" is clear. "Ad" alone is vague.
• Don't punish a cancel. The player chose not to watch. Let them continue as before.

1. Open the build in a normal browser. The bridge runs a PlayKovo demo video in place of a real ad, which lets you test timing, reward gating and skip behaviour.
2. Skip the demo video and check that nothing is granted.
3. Call twice in a row and check how your game handles cooldown or unavailable.
4. Disconnect the network and check that the game still plays.

The next step, mobile QA with a debug build, is covered in opting into the mobile app. For web rewarded ads, the equivalent rules are in grant the reward only inside onReward. The reference is the mobile bridge page.