Cross-provider bonuses: running one campaign across every studio

Ask a CRM manager what limits their campaigns and the answer is rarely budget. It is the fact that every promotional mechanic behaves differently depending on which studio built the game. Free rounds on one studio need a pre-registration call; on another they are issued at launch; a third does not support them at all. Tournaments run on the studio's own leaderboard, which only sees its own games. This article explains where those limits come from and how a bonus layer removes most of them.

Why bonuses stop at studio boundaries

Studios build promotional features into their own game servers. A free-round is a game-server concept: the server has to know that the next twenty spins are prepaid at a specific stake and must report their outcome separately. That means the operator, or the aggregator, has to call the studio's promo API in the studio's format, with the studio's identifiers, before the player opens the game.

Tournaments are similar. Studio-run tournaments rank players on bets or wins in that studio's games, because that is the only data the studio has. Cashback and missions are different: they run on wallet data the operator already holds, which is why they work across studios more easily.

The result is a matrix of mechanics by studio that the CRM team has to memorise, and campaigns that quietly exclude half the lobby.

What a bonus layer does

A bonus layer sits above the wallet and the studio integrations. It exposes one set of campaign primitives (free rounds, bonus money with wagering, tournaments, missions, cashback) and translates each into what the underlying studio supports.

For free rounds, the layer holds a registry of each studio's promo API and issues the rounds in the right format at the right moment. For tournaments, the layer computes leaderboards from wallet transactions rather than from studio data, so a tournament can span any set of games from any set of studios. For cashback and missions, the layer works from the same transaction stream.

Where a studio does not support a mechanic, the layer says so at campaign setup rather than at go-live, so the CRM team can choose an equivalent (bonus money restricted to those games, for example).

Designing campaigns that work across the lobby

A few design rules make cross-provider campaigns reliable.

• Define eligibility by game category and market, not by studio. "All slots certified for Brazil" is a stable rule; a hand-picked list is not.
• Use wallet-based mechanics for the broad reach and studio-based mechanics for the headline. A lobby-wide tournament computed from wallet data reaches everyone; free rounds on one new release create the hook.
• Attribute cost per game and per studio. A campaign that looks profitable overall may be losing money on a high-RTP game that eats the free-round budget.
• Test the studio calls in sandbox before the campaign launches, because the failure mode (free rounds that never appear) is invisible until support tickets arrive.

Reporting and reconciliation

Cross-provider campaigns generate cost in several places: prepaid free-round stakes, bonus money converted to cash, tournament prize pools. Finance needs those attributed to campaign, game, studio and market, and reconciled against studio invoices where the studio charges for free rounds. A bonus layer that shares its ledger with the reporting system makes that a query rather than a project.

How SlotCore does it

SlotCore's bonus and gamification module is the layer described here. Campaigns are configured once against categories and markets; the module issues free rounds through each studio's promo API where supported, computes tournaments and missions from the seamless wallet stream, and reports cost per campaign, game and studio in the same back office as GGR. The provider page for each studio notes which mechanics it supports, so the CRM team knows before designing a campaign.