Embedded payouts for games

Pay the people who make your game better. Inside your game.

Creator earnings, mod sales and programme payouts, with much lower practical minimums.

Your platform decides what creators have earned. ZBD brings required checks, supported payout choices and status into one branded flow.

Talk to us See it in a game

Programme fitConfirm countries, payees and methods

On demandEvent-driven payout initiation

Meridian Haul · Vasari Reach ● Docked

12,800 venncargo sale

+$9.40route bonus

Wallet

$24.5012,800 venn

Walletlinked wallet

BankUSD · EUR

Cardpush-to-card

Identity verified ✓Cash-out in your product

Cash out$24.50

Fee · covered by publisheryou receive $24.50

Bank transfer · arrival set by your bankEligible balance

✓

VerifiedIdentity & sanctions checks passed

− $24.50 · cash-outBank

Sending…arrival set by your bank

Sent · arrival set by your bank

ReceiptZBD-4F7K-0921

Amount$24.50

Feecovered by publisher

To@marrowfox · Bank

Net$24.50 · arrival set by your bank

Illustrative flow for an eligible, verified earner. Event-driven payout initiation. Arrival depends on method, market and cut-off times.

Your game

Fee paid by

Rail

Either way, the earner sees the fee before they confirm. Who pays is your setting.

Why choose ZBD

One integration. Three things you would otherwise buy separately.

Built around the people your game already owes.

Payouts

Paid inside the game, not in a supplier portal. The recipient never leaves your UX.

Identity

KYC and KYB built in. A cleaner community as a side effect: harder for bad actors to be paid.

Tax

Reporting handled, including the US forms most creator programmes dread.

Compared one line at a time, bundled providers look expensive. Compared as a stack, the picture changes.

Required checks stay in the flow. Confirm countries, methods, fees and responsibilities for your programme.

Watch the payout journey

Why ZBD

The moment the game hands them to someone else.

Today

9 steps · 2 companies

Steps counted on the fictional screens shown.

Two companies. Two logins. A supplier-invoice process for a player who built a level.

With ZBD

1 step · inside the game

One tap. Requested. Still in the game.

Illustrative. The portal shown is fictional; the earnings, methods, minimum and timing are examples, not any provider’s terms or ZBD’s. A payout request is not bank arrival.

The payout journey, before and after.

Illustrative sequence · counts unverified; not a timing benchmark

Portal-heavy example00 / 27

ZBD0 / 4

Plays once when the journey scrolls into view.

Portal-heavyIllustrative creator
setup journey

Out of the product. Into setup.

27illustrative actions

An authored portal-heavy journey. The winding route below is an illustration, not an audited screen map.

A journey with detours00 / 27

Creator hub → Email → Payout portal

Separate setup · six task groups

You came here to get paid.

First: activation, profile, account security, agreements, a transfer method and destination details. Follow the detour, one action at a time.

Illustrative trace, not a reconstruction of 27 actual screens.

Proposed payout
experience

Cash out. In your product.

4proposed stages

Four proposed payout stages. Required checks vary by programme.

Creator hubFictional example

Confirm who’s getting paid

Required checks, presented as part of the experience.

Alex · individual creatorMakes game content and experiences

Simulated identity check. No personal information is collected.

Demo only. $18 balance and $0.50 fee are examples, not ZBD terms. No payment is sent. Arrival depends on method.

Illustrative, drawn from a published creator-payout process. Not a matched vendor benchmark and not a measured reduction.

Why it matters

Built for the long tail.

Most contributors never reach a hundred-dollar floor, so they are never paid and drift away. Every hurdle between earning and being paid is a chance to lose them. Paying small amounts, often, inside the game keeps them contributing.

Who gets paid

Pay the person who earned it.

Creators, influencers and eligible winners. Pay the people who create value in your game.

Nia makes a game island.Creator = someone who makes content others play.

Creator programme

Your platformApproves & funds Nia’s earnings

Funds

The payout journeyChecks · method · request · status

Payout route

Nia, the creatorRequests her approved earnings

The creator gets paid. The players play.Playing alone does not create a right to cash out.

How it fits

Fund it. Request it. Track it.

Your brand stays in front. Your team sees what happens next.

Orbit Studio / PayoutsFictional example

Approved creator earnings$48.50

Funded by your platform. Ready to request.

Platform fundsEligible balance

Requested ≠ arrived. Bank arrival depends on the method and checks. No live payment is shown.

What stays yours & what needs confirming

You keep: earnings rules, funding, your brand, the recipient relationship and your own legal obligations.

Agree before launch: countries, payees, methods, fees, checks, tax, support, reporting and responsibilities. Availability depends on the programme.

Explore the integration →

Where it stands

Plan your first payout launch.

ScopeConfirm supported users, countries, methods and launch requirements with the ZBD team

ProveMeasure completion, recipient costs, support demand and reconciliation for your first cohort

Who it's for

Built for the people who actually pay creators and contributors.

Live-service games with tradable assets

Tradable items, player markets, in-game currencies. Let a permitted slice of your economy change hands and settle inside the game. Built on Embedded Accounts — proposed capability; availability and launch scope to be agreed.

Game economies →

Mod and UGC marketplaces

You already owe modders and level makers for what they sell. Pay them inside the game, with identity and tax handled by the same integration.

Creator payouts →

Creator and esports programmes

Streamers, island creators and esports players who drive engagement. One programme, one recipient cohort, one payout journey inside your game.

Programme payouts →

The threshold problem

How many earners does your minimum leave waiting?

An illustrative first-month view. Real balances carry forward, and some earners may stop engaging while they wait; measure that in your own programme.

Payout minimums exist because someone pays per payout. Put your numbers in.

Earners on your platform

Average monthly earning ($)

Current payout minimum ($)

Assumption: the median earner makes % of the average — creator and player earnings are long-tailed.

Illustrative. Your distribution will differ; the threshold effect is what to look for.

5 monthsbefore the median earner first reaches $100

Try a lower minimum to see how the waiting share changes. The viable minimum depends on payout costs, risk and who pays the fee.

How this is calculated

Monthly earnings per earner are modelled as lognormal with your mean and median: σ = √(2·ln(mean/median)), μ = ln(median). The share of earners below a threshold T is Φ((ln T − μ)/σ), where Φ is the standard normal CDF, computed with the Abramowitz–Stegun 7.1.26 erf approximation. The median wait is ⌈T / median⌉ months. A blank field shows “—” rather than assuming zero. Small payouts cost money on every method. Changing who pays moves that cost; it doesn't remove it.

Build vs buy

Why not build it yourself?

The build

A prebuilt flow removes the interface work. Production timing depends on your integration, your compliance review and any migration.

What stays yours

Building it yourself still needs licensing, verification, tax, reconciliation and support allocated to someone. Buying doesn't remove all of it either. Compare what your team retains under each model.

Where ZBD accelerates

Compare the payment workflow and regulated services ZBD would provide with the work your team would retain.

Review ZBD’s payout flow for your programme. Embedded Accounts is proposed capability; availability and launch scope to be agreed.

See the sourced comparison with five other providers →

Developers

Choose your integration route.

Start with the web cash-out flow or API. Confirm the supported route, responsibilities and launch requirements for your stack.

Web cash-out flowA branded cash-out journey inside your product; scope and integration support are agreed before launch.

Unity integrationFor Unity projects, agree the integration route and support requirements with the ZBD team.

Payouts & Accounts APIServer-side workflow examples. Accounts is proposed capability; availability and endpoint scope to be agreed.

Read the docs Explore the API

Illustrative pseudocode — not a released SDK or production API contract

// Unity concept — illustrative, not a released ZBD SDK
var zbd = ZbdSdk.Init("sk_test_your_key_here");

await zbd.Payouts.Send(new Payout {
  PlayerId = creator.Id,
  Amount   = Money.USD(12.00m),
  Reason   = "creator_earnings"
});

zbd.Cashout.Open(creator.Id); // illustrative UI, your brand

// Pay out cleared earnings the moment they're earned
await zbd.payouts.send({
  playerId: creator.id,
  amount:   { value: 12.00, currency: 'USD' },
  reason:   'creator_earnings',
  feePayer: 'player'       // or 'publisher' | 'split'
});

// Open the in-game cash-out screen
zbd.cashout.open({ playerId: creator.id });

# REST — one call per payout (sandbox)
curl https://api.zbd.example/v1/payouts \
  -H "Authorization: Bearer sk_test_your_key_here" \
  -d playerId=plr_8842 \
  -d amount=12.00 -d currency=USD \
  -d reason=creator_earnings

Trust & compliance

What procurement usually asks for, and where to get it.

Licensed in the US and across the EEA

ZBD provides the agreed regulated payment services, recipient checks and controls for your supported programme. Confirm the licensed entity, countries and responsibilities with the team; your platform retains its own programme obligations.

United StatesMoney Transmitter Licences · NMLS ID 2188007

European Economic AreaElectronic Money Institution · CASP under MiCAR · PSD2

SecuritySOC 2 Type II, per ZBD's security page. Ask for the current report, its period and scope.

ControlsKYC/AML, sanctions screening, real-time fraud detection

Built to be diligenced

Ask for our current security and compliance documentation for your evaluation.

Request the trust pack →

Embedded Accounts · proposed

Money in. Money around. Money out.

Proposed capability. Availability and launch scope to be agreed.

A player buys an item. Another player wants it. A permitted trade gives the seller a usable balance and can create a new commission stream for the publisher.

Money in through platform stores, the publisher’s own store and the in-game wallet; money around as players trade and the publisher earns a commission on each pass; money out when a contributor cashes out. The in-game wallet: In-game wallet · Unified ledger · KYC · Compliance and licences.

Illustrative. Retained shares, commission and trade counts are examples, not measured figures. Publisher commission, trade volume and ZBD revenue are three different numbers. The player economy is proposed.

Try the numbers: a fictional game economy

A fictional game economyProposed capability · no money moves

Money in$100

Three adults fund their game accounts. The publisher defines which items may be traded.

Money around

Mira$40

Jules$30

Ari$30

0 illustrative trades · $10 per trade

Money out$0

Mira can request her balance

Withdrawal request ≠ money received at a bank.

Three fictional adults fund $100 between them. No trades yet.

Trade volume · not revenue$0

Publisher commission · example$0

Participant balances remaining$100

Pending withdrawal request$0

Fictional economics: each $10 trade credits $9 to the seller and $1 to the publisher. The 10% commission is illustrative, not a quote. ZBD charges and delivery costs are not modelled. Ten trades is an example, not a requirement before withdrawal. Asset permissions, controls, account eligibility and launch scope must be agreed.

A publisher-controlled marketplace needs its own business rules, product readiness and approved financial model.

More Accounts illustrations: creator sharing and the platform layer

Earns $18
Shares $6
$12 available to withdraw
Withdrawal requested. Arrival depends on method.

Proposed capability

1 · EarnsA creator’s map is played; the earning lands as a real balance in their account inside the platform.

2 · SharesThey send a share to the collaborator who worked on it — an approved transfer type, recorded on the same ledger.

3 · WithdrawsThey request withdrawal to a supported destination. The request stays in your product; funds leave through the payout method.

Illustrative example: a creator earns $18, shares $6 with a collaborator, and requests withdrawal of the remaining $12. Proposed capability; arrival depends on method.

Proposed capability

ZBD Embedded Accounts

Proposed. Players trade with each other; proceeds return to their in-game wallet and are mostly respent. Cash-out is the player’s choice, not the point.

Illustrative flow: money enters an account, an approved transfer moves value between participants, and a withdrawal is requested through a supported payout method.

Transfer types and payout methods depend on the approved programme.

What Accounts is designed to add

Money in: deposits and top-ups
Money through: transfers between players and creator marketplaces, where approved
Money out: the same cash-out flow as Payouts

Discuss Embedded Accounts →

Get started

Review your payout flow.

Tell us who you pay, in which countries and by which methods. We’ll work through the fit, economics and first-launch scope with you.

Contact ZBD Read the docs