> ## Documentation Index > Fetch the complete documentation index at: https://docs.zbdpay.com/llms.txt > Use this file to discover all available pages before exploring further. # ZBD Earn SDK > Add real-money rewards to your Unity mobile game. No backend required to get started.

The ZBD Earn SDK lets you reward players with real money at meaningful moments in your mobile game (level completions, daily missions, milestone unlocks). Done well, it lifts retention and LTV by making progress feel tangible. Unlike third-party rewards networks, rewards live natively inside your game — branded to your experience, triggered by your gameplay moments, and controlled entirely by you. Players never leave your app to collect rewards from an aggregator. The habit loop stays yours. You control when rewards fire and how much players can earn. ZBD handles account creation, identity verification, and payouts through an in-app modal that requires no UI work on your end. Drop a prefab into your scene. No backend required. Reward players in your own virtual currency units or in satoshis. Most studios use the in-game currency model. Players cash out through the ZBD modal. You open it with one method call; ZBD handles the rest. Average revenue per daily active user increase seen by ZBD partners. Long-term retention lift seen by partners with well-integrated reward economies. Typical reward budget. Reinvesting a slice of revenue generates significantly more in return. ## What makes it work Before anything else, know what a successful integration depends on. **Three things drive conversion — if one is missing, your rewards may underperform:** 1. Your **UI/UX shows and explains** how rewards work and how to claim them — native game elements first, plus creatives and notifications. 2. You're **rewarding enough** to be worth coming back for. Nobody changes their behavior for a few cents — size rewards off actual revenue by [connecting your MMP](/earn/sdk/mmp-postbacks). 3. You **know your audience**. Acquiring players who want to earn — or who'd be interested in earning — improves conversion rates. What to do for each one, and the pages that implement them. Read this before you design your rewards UX. ## How it works Players accumulate a **rewards balance** at triggers you define. The balance is denominated in your chosen reward currency: virtual units in in-game currency mode, or satoshis in Bitcoin mode. When players are ready to cash out, they tap the rewards entry point in your game, pick how they want to be paid, and withdraw. ZBD handles the rest. Two values govern every player's rewards state: | Value | What it is | | -------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Rewards balance** | The total amount the player has earned and not yet withdrawn. You add to this by calling `SendReward`. | | **Withdrawal limit** | How much of that balance the player can withdraw right now. It grows automatically as they play, on the reward schedule configured for your app, and you can also raise it from your server at any time. | The withdrawal limit exists mainly to protect against fraud, but it's also a retention mechanic: how much the limit can grow in a day is capped, and that daily allowance resets every 24 hours — so players come back tomorrow to unlock more of what they've earned. A player can earn faster than their limit grows. The excess stays in their balance and becomes withdrawable as the limit rises, either through continued play or a server-side increase. You set the reward amounts and configure the withdrawal limits. ZBD enforces those limits on the player side. This separation means you can be generous with rewards without taking on uncapped financial exposure. ## The player experience Here's what a player sees from first launch through first cashout — the journey you're building toward. At a gameplay moment you define (level complete, daily mission chest, milestone hit), a reward notification fires: "You earned 500 coins (\$0.05)!" They didn't have to do anything differently — it just happened. Fire this early in the first session, so the player never sees the rewards counter sitting at zero: discovering a balance that already exists is what makes the feature feel real. The player notices a balance counter in your game UI alongside your other currencies — and there's already something in it. It's branded to your game; they have no idea what's powering it. Right after the first reward lands, a one-screen [creative](/earn/sdk/creatives) shows the balance they already have, paired with the reason it's real: *"game studios share their ad revenue with players."* The modal's built-in first-time screen doesn't carry that line, so this is where players learn why the rewards aren't a scam. See the [Player Communication Guide](/earn/sdk/player-comms). They tap the counter (or your rewards button). The modal opens instantly — no extra screens — showing their balance and the cashout options you've configured with your Customer Success Manager: gift cards, Cash App, ZBD, and others depending on their region. They pick a payout option and withdraw. The modal handles the full flow, and they're deep-linked back to your game when it's done. Most options need nothing more than that. Cashing out **to ZBD** is the one that requires the player to have a linked ZBD account — worth knowing because ZBD runs partner incentive programmes for studios whose players cash out to ZBD, so you may want to promote it as an option. It's never a requirement for withdrawing. Their withdrawal limit doesn't reset — what resets is how much more of it they can unlock. Each day brings a fresh allowance, so any balance they couldn't withdraw yet becomes withdrawable as they keep playing. The habit loop is set: play, earn, come back. For guidance on what to say to players at each of these moments, see the [Player Communication Guide](/earn/sdk/player-comms). ## Key decisions Before writing any code, you'll need to choose your reward currency (in-game units or Bitcoin), your delivery method (client-side or server-side), and confirm your target regions are covered. These decisions shape your integration. Reward currency, delivery method, and payout options — with a comparison table for each. Read this before starting the setup. ## How the economics work The reward budget comes from you — typically a small percentage of the revenue your players are already generating. You're not buying ad impressions or paying for external traffic. You're redirecting a portion of existing player LTV back to the players who generate it, at a fraction of what acquisition channels cost. ZBD's platform fees are low, and the total cost of running a rewards program is designed to be well within the value it returns in retention and engagement. Your Customer Success Manager will walk you through the specifics when you get set up. ## Compliance and KYC Payments involve compliance requirements. Here's what falls on ZBD and what falls on you. **ZBD handles:** * Player identity verification — players go through a light KYC step the first time they cash out, inside the ZBD modal. You don't build or manage this. * Regulatory compliance — ZBD is a licensed payment service provider in the US and EU. * Fraud tooling — withdrawal limits, device attestation, geolocation, and VPN detection are built into the SDK. **You are responsible for:** * Your reward exposure — you set the budget and limits. ZBD's built-in protections reduce fraud risk, but you ultimately own your reward economics. Moving to [server-side reward delivery](/earn/sdk/send-rewards-server) is the most effective step you can take. See [Security](/earn/sdk/security) for the full picture. * App store compliance — ZBD rewards must be implemented correctly to comply with Apple App Store and Google Play policies. See [iOS App Store Guidelines](/earn/sdk/ios-app-store) and [Android App Store Guidelines](/earn/sdk/android-app-store). * How you communicate rewards to players — see the [Player Communication Guide](/earn/sdk/player-comms) for what to say and what to avoid. You do not take on KYC obligations for your players. ZBD holds that relationship. ## Before you start A few decisions should be locked in before you write any code. The reward budget, daily withdrawal limit, and reward currency are all tunable after launch, but getting them roughly right at the start saves significant iteration. Recommended starting values for reward budget, withdrawal limits, and trigger ceilings. Start here. What you need to know to pass App Store and Google Play review with ZBD integrated. ## Get started ZBD Earn is available to approved partners. [Talk to our team](https://zbdpay.com/contact) to discuss your use case and get access to the Unity SDK. Most studios are set up within a few days. Lock in your reward budget, withdrawal limit, and reward currency before integrating. [Reward Economics →](/earn/sdk/reward-economics) Your ZBD Customer Success Manager will provide the Unity package and help configure your project. [Download →](/earn/sdk/download) Import the package, drop the prefab, and call `Init` on app launch. [Integration guide →](/earn/sdk/integration) Call `SendReward` at a gameplay moment. [Client-side →](/earn/sdk/send-rewards-client) or [Server-side →](/earn/sdk/send-rewards-server) Run through the go-live checklist before pushing to production. [Go-live checklist →](/earn/sdk/go-live-checklist)