Developer Docs
Case Study Brief API Reference Architecture Case Studies Research / Planning

Platform Overview

The full-stack payment platform purpose-built for gaming

DBZ is a bi-directional payment platform for game studios. It handles everything from paying players real money for in-game achievements to processing purchases and managing virtual currency — all while keeping studios completely out of PII and PCI scope. Built on regulatory licenses (US Money Transmitter Licenses + EU MiCAR/EMI) and micropayment economics that make sub-cent transactions viable, DBZ enables product categories that are structurally impossible on traditional payment rails.

Three Workstreams

Workstream 1

Payout to Bank

Money flows from studio to player. When a player earns a reward (wins a match, completes a challenge), the game server validates the event and calls DBZ's API to send money to the player's bank account.

Think of it like direct deposit: the studio (employer) triggers the payout on the player's behalf. The player never touches the API — they just see "+$0.25 earned" in-game.

Studio controls when and why players get paid. DBZ handles banking rails, KYC, and compliance.

Workstream 2

Wallet Loading + Checkout

Money flows from player to studio. Players buy in-game items (skins, battle passes, virtual currency) through a DBZ-powered web store instead of the Xbox/PlayStation/Steam store.

Players save ~20% (lower prices). Studios keep ~27% more revenue (3% processing fee vs 30% platform fee). Both sides win.

Players can also load funds into a DBZ wallet from their bank account for faster future purchases.

Workstream 3

Virtual Currency + Tournaments

Virtual Currency: An in-game currency (e.g., "Halo Credits") managed by DBZ's ledger. Players earn or buy credits, spend them on items, and — unlike V-Bucks or Robux — can convert them back to real money.

Tournaments: Competitive events where players pay a real-money buy-in ($10), play for a prize pool ($500), and winners are paid out automatically. DBZ holds funds in escrow during play and handles geo-fencing to legal states.

Bundled because tournaments can use virtual currency for buy-ins and prizes, sharing the same ledger infrastructure.

Competitive Landscape

CompetitorPay-InPay-OutGaming-NativeMicropaymentsLicensing
Xsolla700+ methodsNoYesNoMoR model
TipaltiNo196 countriesNoNoVia partners
StripeYesYesNoNo ($0.50 min)Yes
CoinflowYes (crypto+fiat)YesPartialYes (crypto)Growing ($25M Series A)
NuveiYesYesiGaming onlyNoYes (gambling)
SkillzTournaments onlyTournaments onlyYesNoSkill gaming
DBZYes (checkout)Yes (payouts)YesYes ($0.0005)MTL + MiCAR + EMI

The Compound Moat

"Three things that compound together: (1) Regulatory licenses that took years and millions — competitors need 2+ years just to get started. (2) The only bi-directional payment platform purpose-built for gaming — Xsolla does pay-in, Tipalti does pay-out, DBZ does both. (3) Micropayment economics that enable use cases structurally impossible on traditional rails — you can't reward a player $0.02 through Stripe. No single piece is unassailable, but together they create a 3+ year head start."

For shared infrastructure details (authentication, webhooks, rate limiting, sandbox setup, multi-currency support), see Research & Deep Dives.

Users & Identity

Registration, KYC verification, and user management

Zero PII — Developers never handle identity documents

Endpoints

MethodEndpointDescription
POST/v1/usersRegister a player. Accepts externalId, email, country. Returns a DBZ userId.
GET/v1/users/{userId}Get user profile (KYC status, tier, linked accounts).
GET/v1/usersList users. Filter by kycStatus, country, createdAfter.
POST/v1/users/{userId}/verifyInitiate KYC verification. Returns a verificationUrl (hosted by DBZ).
GET/v1/users/{userId}/verify/statusCheck current KYC verification status.

KYC Tiers

Tiered verification minimizes friction and maximizes conversion. Players earn first, verify only at cash-out.

TierRequiresPayout LimitUse CaseLegal Basis
Tier 0Email onlyUnlimited earning, no withdrawalFrictionless onboarding, in-game economyNo cash-out = no money transmission
Tier 1Email + phone (SMS)$300/month withdrawalCasual player cash-outsAligned with Venmo/Cash App unverified limits
Tier 2Full name + DOB + address$2,999 cumulative withdrawalRegular earnersBelow FinCEN Travel Rule ($3K, 31 CFR 1010.410)
Tier 3SSN/TIN (W-9) + government ID$20,000/yearHigh-volume playersEnables 1099-MISC filing; satisfies Travel Rule
Tier 4Government photo ID + address proofUnlimitedCreators, streamers, prosFull KYC; all federal and state requirements

User Object

{
  "id": "usr_a1b2c3d4",
  "externalId": "player_12345",
  "email": "player@example.com",
  "country": "US",
  "kycStatus": "approved",
  "kycTier": 2,
  "createdAt": "2026-03-20T10:00:00Z",
  "metadata": {}
}

For detailed webhook events, see Research.

Payout to Bank

Trigger bank account payouts on behalf of players

Zero PII — Developers never see bank account numbers

Bank Account Linking

Before a payout can be created, the player must link a bank account through DBZ's hosted Plaid flow.

MethodEndpointDescription
POST/v1/users/{userId}/bank-accountsCreate a bank account linking session. Returns linkUrl (DBZ-hosted, powered by Plaid).
GET/v1/users/{userId}/bank-accountsList linked bank accounts. Returns tokenized references only.
GET/v1/users/{userId}/bank-accounts/{bankAccountId}Get bank account details (masked: ****6789, institution, status).
DELETE/v1/users/{userId}/bank-accounts/{bankAccountId}Unlink a bank account.

Bank Account Object (tokenized)

{
  "id": "ba_x9y8z7",
  "userId": "usr_a1b2c3d4",
  "institutionName": "Chase",
  "accountType": "checking",
  "last4": "6789",
  "status": "verified",
  "createdAt": "2026-03-20T12:00:00Z"
}

Developer never sees: full account number, routing number, holder name, or any PII.

Payout Endpoints

MethodEndpointDescription
POST/v1/payoutsCreate a payout. Specify userId, bankAccountId, amount (cents), currency.
GET/v1/payouts/{payoutId}Retrieve payout details and current status.
GET/v1/payoutsList payouts. Filter by userId, status, date range. Cursor-paginated.
POST/v1/payouts/{payoutId}/cancelCancel a payout (only if status is pending).
POST/v1/payouts/batchCreate up to 500 payouts in one request. Returns a batchId.
GET/v1/payouts/batch/{batchId}Get batch status and individual payout statuses.

Create Payout Request

POST /v1/payouts
{
  "userId": "usr_a1b2c3d4",
  "bankAccountId": "ba_x9y8z7",
  "amount": 5000,
  "currency": "usd",
  "description": "Tournament winnings - March 2026",
  "internalId": "game_match_789",
  "metadata": {
    "gameId": "battle-royale-2",
    "matchId": "match_789",
    "reason": "tournament_prize"
  }
}

Payout Object

{
  "id": "po_m4n5o6p7",
  "userId": "usr_a1b2c3d4",
  "bankAccountId": "ba_x9y8z7",
  "amount": 5000,
  "currency": "usd",
  "status": "processing",
  "description": "Tournament winnings - March 2026",
  "internalId": "game_match_789",
  "method": "ach",
  "estimatedArrival": "2026-03-22T00:00:00Z",
  "failureCode": null,
  "failureMessage": null,
  "createdAt": "2026-03-20T14:00:00Z",
  "completedAt": null,
  "metadata": {
    "gameId": "battle-royale-2",
    "matchId": "match_789",
    "reason": "tournament_prize"
  }
}

Payout Status Lifecycle

stateDiagram-v2 [*] --> pending pending --> processing pending --> canceled : Developer cancels processing --> in_transit processing --> failed in_transit --> completed completed --> returned : Bank rejects after deposit

For detailed failure codes, webhook events, and Node.js code samples, see Research.

Wallet Loading

Allow players to purchase virtual currency from a linked bank account. USD is converted to VC at the configured rate.

Zero PII — Sensitive bank data stays inside DBZ's perimeter

The wallet holds virtual currency, not USD. This is a deliberate regulatory design: by converting to VC on the buy side, the wallet avoids stored-value classification under state money transmitter laws, simplifying compliance for both DBZ and the studio.

Endpoints

MethodEndpointDescription
GET/v1/users/{userId}/walletGet virtual currency balance and wallet status.
POST/v1/users/{userId}/wallet/loadPurchase virtual currency from a linked bank account. USD is converted to VC at the configured rate.
GET/v1/users/{userId}/wallet/loads/{loadId}Get load status.
GET/v1/users/{userId}/wallet/loadsList wallet loads. Filter by status, date range.
GET/v1/users/{userId}/wallet/transactionsVirtual currency transaction history (purchases, credits, debits, transfers, conversions).

Wallet Object

{
  "userId": "usr_a1b2c3d4",
  "vcBalance": 15000,
  "currencyId": "pokecoin",
  "currencyName": "PokeCoin",
  "fiatEquivalentCents": 15000,
  "conversionRate": 100,
  "status": "active",
  "dailyLoadLimitCents": 50000,
  "dailyLoadRemainingCents": 35000,
  "updatedAt": "2026-03-20T15:00:00Z"
}

Create Wallet Load Request

POST /v1/users/{userId}/wallet/load
{
  "bankAccountId": "ba_x9y8z7",
  "amountCents": 2500,
  "targetCurrency": "pokecoin",
  "internalId": "load_session_456"
}

Wallet Load Object

{
  "id": "wl_q1r2s3t4",
  "userId": "usr_a1b2c3d4",
  "bankAccountId": "ba_x9y8z7",
  "amountChargedCents": 2500,
  "vcCredited": 2500,
  "targetCurrency": "pokecoin",
  "conversionRate": 100,
  "status": "pending",
  "internalId": "load_session_456",
  "createdAt": "2026-03-20T15:30:00Z",
  "completedAt": null
}

Load Status Lifecycle

stateDiagram-v2 [*] --> pending pending --> processing processing --> completed processing --> failed

SDK vs. Developer Responsibility

SDK Handles (inside DBZ)Developer Receives
Bank auth via Plaid LinkTokenized bankAccountId
ACH debit initiationLoad status + webhooks
Reg E compliance (error resolution)load.failed with reason code
Fraud screening on loadApproved/rejected decision
Balance updatesUpdated wallet balance via API

For detailed error codes and webhook events, see Research.

Checkout (Web Store)

Hosted checkout widget for direct-to-consumer purchases, bypassing app store fees

Payment Methods

Players can pay with:

  • Existing virtual currency balance
  • Linked bank account (USD, converted to VC at checkout)
  • Card payment (via DBZ hosted widget)

Platform fee savings: DBZ charges 3% processing vs. 30% app store fees. Studios keep significantly more revenue on every transaction.

Endpoints

MethodEndpointDescription
POST/v1/checkout/sessionsCreate a checkout session. Returns a checkoutUrl.
GET/v1/checkout/sessions/{sessionId}Get session status and payment details.
GET/v1/checkout/sessionsList checkout sessions. Filter by userId, status, date range.
POST/v1/checkout/sessions/{sessionId}/refundRefund a completed purchase.

Create Checkout Session

POST /v1/checkout/sessions
{
  "userId": "usr_a1b2c3d4",
  "lineItems": [
    {
      "name": "1000 Gold Coins",
      "description": "In-game currency pack",
      "amount": 999,
      "currency": "usd",
      "quantity": 1,
      "metadata": { "sku": "gc_1000", "type": "virtual_currency" }
    }
  ],
  "successUrl": "https://yourgame.com/purchase/success?session={SESSION_ID}",
  "cancelUrl": "https://yourgame.com/purchase/cancel",
  "internalId": "purchase_abc123",
  "metadata": { "gameId": "battle-royale-2" }
}

Checkout Session Object

{
  "id": "cs_v1w2x3",
  "userId": "usr_a1b2c3d4",
  "status": "completed",
  "paymentMethod": "card",
  "amountTotal": 999,
  "currency": "usd",
  "lineItems": [ ... ],
  "internalId": "purchase_abc123",
  "createdAt": "2026-03-20T17:00:00Z",
  "completedAt": "2026-03-20T17:01:30Z"
}

Checkout Flow

  1. 1. Create session — Developer creates checkout session via API, receives a checkoutUrl.
  2. 2. Redirect player — Player is redirected to DBZ's hosted checkout page (card entry, Apple Pay, Google Pay).
  3. 3. Process payment — DBZ processes payment (PCI-compliant, fraud screening, 3D Secure).
  4. 4. Fulfill order — Webhook checkout.completed fires. Developer credits items/currency to the player. Funds settle to the studio's DBZ project balance.

Platform ToS Strategy

Web store checkout happens outside the app. Player opens a link in their browser.

  • Post-Epic v. Apple (April 2025 ruling): developers can link to external purchase pages.
  • The December 2025 Ninth Circuit appeal allows Apple to charge a "reasonable commission" (exact rate TBD by district court). Even so, studios save meaningfully vs. 30%.
  • In the EU, the DMA separately prohibits Apple from charging commissions on external links, making the web checkout value prop strongest there.
  • In-app, the studio can still use Apple/Google IAP for platform-required purchases. DBZ web checkout is the direct-to-consumer alternative.

For detailed webhook events, see Research.

Virtual Currency

Convertible virtual currency ledger for in-game economies, backed by DBZ as system of record

Currency Configuration

MethodEndpointDescription
POST/v1/currenciesDefine a virtual currency (name, symbol, conversion rate, limits).
GET/v1/currencies/{currencyId}Get currency config.
PATCH/v1/currencies/{currencyId}Update currency settings (rate, limits).
GET/v1/currencies/{currencyId}/rateGet current conversion rate to USD.

Currency Object

{
  "id": "cur_g1h2i3",
  "name": "Gold Coins",
  "symbol": "GC",
  "conversionRate": 100,
  "conversionUnit": "usd_cents",
  "conversionDirection": "to_fiat",
  "minConversion": 1000,
  "maxConversionPerDay": 50000,
  "status": "active",
  "createdAt": "2026-03-01T00:00:00Z"
}

conversionRate: 100 means 100 Gold Coins = $1.00 USD. Developer defines earn rate in-game; DBZ defines the cash-out rate.

Ledger Endpoints

MethodEndpointDescription
POST/v1/ledger/creditCredit virtual currency to a user (player earned coins).
POST/v1/ledger/debitDebit virtual currency (player spent coins in-game).
POST/v1/ledger/transferPlayer-to-player transfer.
GET/v1/ledger/balance/{userId}Get player's virtual currency balance.
GET/v1/ledger/transactionsTransaction history. Filter by userId, type, date range.
POST/v1/conversionsConvert virtual currency to USD. Requires KYC. Internally triggers the Payout to Bank flow — the same KYC tiers, compliance checks, and bank payout lifecycle apply.
GET/v1/conversions/{conversionId}Get conversion status.
GET/v1/conversionsList conversions.

Credit Request (player earns coins)

POST /v1/ledger/credit
{
  "userId": "usr_a1b2c3d4",
  "currencyId": "cur_g1h2i3",
  "amount": 500,
  "reason": "match_victory",
  "internalId": "match_789_reward",
  "metadata": {
    "matchId": "match_789",
    "placement": 1
  }
}

Ledger Transaction Object

{
  "id": "txn_k5l6m7",
  "type": "credit",
  "userId": "usr_a1b2c3d4",
  "currencyId": "cur_g1h2i3",
  "amount": 500,
  "balanceAfter": 3200,
  "reason": "match_victory",
  "internalId": "match_789_reward",
  "createdAt": "2026-03-20T16:00:00Z",
  "metadata": {
    "matchId": "match_789",
    "placement": 1
  }
}

Conversion Request (player cashes out)

POST /v1/conversions
{
  "userId": "usr_a1b2c3d4",
  "currencyId": "pokecoin",
  "amount": 1000,
  "payoutMethod": "bank_account",
  "bankAccountId": "ba_x9y8z7"
}

Conversion Response

{
  "id": "conv_m1n2o3p4",
  "userId": "usr_a1b2c3d4",
  "currencyId": "pokecoin",
  "amountDebited": 1000,
  "conversionFeePct": 15,
  "feeAmount": 150,
  "netAmount": 850,
  "usdEquivalentCents": 850,
  "payoutId": "po_r5s6t7u8",
  "status": "pending",
  "createdAt": "2026-03-20T16:00:00Z"
}

The payoutId links the conversion to a Workstream 1 payout. The same KYC tiers, compliance checks, and bank payout lifecycle from the Payout to Bank section apply to this payout.

Key Design Decisions

1. Developer doesn't own the ledger

DBZ is system of record. Developer calls credit/debit APIs, but can't directly manipulate balances. This prevents fraud and ensures auditability.

2. Conversion is one-way (virtual to fiat)

The virtual currency is "convertible" under FinCEN guidance (FIN-2013-G001), which means DBZ operates as a licensed money transmitter for the conversion. One-way conversion simplifies the regulatory model because DBZ is not operating a two-sided exchange/marketplace — but it still requires DBZ's MSB registration and state MTLs. This is why DBZ's licensing is the moat: competitors need 2+ years of licensing before they can legally offer this.

3. Conversion requires KYC

Because this is the point where virtual currency becomes real money. FinCEN requires identity verification for convertible virtual currency transactions.

4. Conversion flows through the wallet

Not directly to bank. This creates a clean two-step: convert then withdraw. Each step has its own compliance checks.

5. Anti-fraud built into the ledger

Velocity checks (max credits per hour), minimum conversion thresholds, suspicious pattern detection — all handled by DBZ.

6. Double-entry accounting

Every credit to a player is a debit from the project's reward pool. Developer tops up the pool; DBZ tracks both sides.

For detailed error codes and webhook events, see Research.

Tournaments

Skill-based tournaments with buy-in escrow, automated prize distribution, and geo-fencing

Endpoints

MethodEndpointDescription
POST/v1/tournamentsCreate a tournament with entry fee, prize structure, and eligibility rules.
GET/v1/tournaments/{tournamentId}Get tournament details and status.
GET/v1/tournamentsList tournaments. Filter by status, currencyType, date range.
POST/v1/tournaments/{tournamentId}/enterEnter a player. Debits entry fee from wallet (cash) or ledger (virtual).
POST/v1/tournaments/{tournamentId}/resultsSubmit final results/rankings. Triggers prize distribution.
POST/v1/tournaments/{tournamentId}/cancelCancel tournament. Refunds all entry fees.
GET/v1/tournaments/{tournamentId}/entriesList all entries/participants.
GET/v1/tournaments/{tournamentId}/payoutsList prize payouts for a completed tournament.

Create Tournament

POST /v1/tournaments
{
  "name": "Friday Night Showdown",
  "gameId": "battle-royale-2",
  "entryFee": 500,
  "currency": "usd",
  "maxPlayers": 100,
  "minPlayers": 10,
  "prizeStructure": [
    { "rank": 1, "percentage": 50, "label": "1st Place" },
    { "rank": 2, "percentage": 30, "label": "2nd Place" },
    { "rank": 3, "percentage": 20, "label": "3rd Place" }
  ],
  "platformFeePercent": 10,
  "prizeSource": "entry_fees",
  "startsAt": "2026-03-21T20:00:00Z",
  "endsAt": "2026-03-21T22:00:00Z",
  "eligibleRegions": ["US_SKILL_GAMING"],
  "metadata": { "season": "3", "week": "12" }
}

Tournament Object

{
  "id": "trn_d4e5f6",
  "name": "Friday Night Showdown",
  "status": "active",
  "entryFee": 500,
  "currency": "usd",
  "currentPlayers": 47,
  "maxPlayers": 100,
  "minPlayers": 10,
  "prizePool": 21150,
  "prizeStructure": [ ... ],
  "prizeSource": "entry_fees",
  "startsAt": "2026-03-21T20:00:00Z",
  "endsAt": "2026-03-21T22:00:00Z",
  "eligibleRegions": ["US_SKILL_GAMING"],
  "createdAt": "2026-03-20T10:00:00Z",
  "metadata": { "season": "3", "week": "12" }
}

Tournament Status Lifecycle

stateDiagram-v2 [*] --> draft draft --> open : Accepting entries open --> active : In progress open --> canceled : Refunds issued active --> completed completed --> settled : Prizes paid

Enter Tournament Flow

POST /v1/tournaments/{tournamentId}/enter
{
  "userId": "usr_a1b2c3d4",
  "internalId": "entry_player123_trn_d4e5f6"
}

DBZ automatically:

  1. Checks player eligibility (KYC tier, age 18+, geo-location in eligible region)
  2. Debits entry fee from player's wallet
  3. Holds entry fee in escrow until tournament completes
  4. Returns entry confirmation with entryId

Submit Results Flow

POST /v1/tournaments/{tournamentId}/results
{
  "rankings": [
    { "userId": "usr_a1b2c3d4", "rank": 1, "score": 9850 },
    { "userId": "usr_e5f6g7h8", "rank": 2, "score": 9200 },
    { "userId": "usr_i9j0k1l2", "rank": 3, "score": 8700 }
  ]
}

DBZ automatically:

  1. Validates rankings (all entrants accounted for)
  2. Distributes prizes per prizeStructure — credits to winners' wallets
  3. Takes platform fee from prize pool (e.g., 10%)
  4. Fires tournament.settled webhook with full payout details

Prize Source Options

SourceHow it WorksBest For
entry_feesPrize pool = sum of entry fees minus platform fee. Skillz model.Competitive esports, PvP games
developer_fundedStudio pre-funds the prize pool from project balance. Entry fee can be $0.Promotional events, player acquisition
hybridBase prize from developer + bonus from entry fees.Seasonal tournaments, live events

Escrow Model

  • Entry fees are held in a DBZ-managed escrow account (not the developer's project balance).
  • Developer cannot access escrowed funds.
  • On tournament completion: prizes distributed from escrow, remainder (fees) split between developer + DBZ.
  • On cancellation: full refund to all entrants from escrow.
  • This protects players and satisfies regulatory requirements for skill gaming.

Virtual Currency Tournaments

Same API, but with currency: "virtual" and a currencyId.

  • No geo-restrictions (virtual currency tournaments legal everywhere)
  • No KYC required for virtual currency buy-in
  • Prizes paid in virtual currency — player can convert to USD later (conversion requires KYC)
  • This lets studios offer tournaments globally, with cash-out only in eligible regions

Geo-Fencing & Legal Framework

  • Skill-based tournaments are legal in approximately 40 US states (Skillz operates under this model).
  • Key legal test: skill must be the "dominant factor" in determining outcomes (not chance).
  • States like AR, CT, DE, LA, SD have specific restrictions on cash skill gaming. Other states (AZ, MT, SC, TN) may have additional restrictions depending on game mechanics.
  • DBZ handles geo-fencing (GPS + IP) to restrict cash tournaments to eligible jurisdictions.
  • Players must be 18+ for cash tournaments (age verified via KYC).

For detailed error codes and webhook events, see Research.

How Tournaments Use All Three Workstreams

flowchart LR A["Wallet Loading\n\nPlayer loads wallet\nfrom bank account"] --> B["Tournament Escrow\n\nEntry fee debited\nfrom wallet, held\nin escrow"] B --> C["Payout to Bank\n\nWinner cashes out\nwinnings from wallet\nto bank"] A --> D["Virtual Currency\n\nAlternative:\ntournament in virtual\ncurrency, convert\nto cash later"] D --> C