Cowrie Research

zbd

4 min read

ZBD

  • Name: ZBD
  • URL: https://zbdpay.com/
  • Category: gaming-payments operator / rewards-and-payout company / login-and-wallet workflow control plane
  • Tags: bitcoin-ecosystem
  • Summary: ZBD belongs in companies/ because the durable dependency is not only a rewards SDK or Bitcoin payout API. It is a named operator that decides which games and apps get onboarded, which regions and withdrawal methods are available, how payout limits and anti-fraud controls are enforced, how OAuth identity and wallet state are exposed, and which regulated payment shell partners inherit across gaming rewards, cash-out, branded-card, and embedded-account products. The useful question is not just can a game pay players with Bitcoin? but which company controls the rewards, compliance, withdrawal, and account workflow around that path?
  • What it does:
    • Operates a gaming-focused payment stack spanning ZBD Earn, payout APIs, OAuth login, the consumer ZBD app, and broader payment products for studios and app developers
    • Lets developers issue player rewards, manage payout and withdrawal flows, and authenticate users through ZBD accounts rather than through a neutral unaffiliated rail
    • Packages branded debit cards, embedded accounts, and payout corridors to bank accounts and third-party destinations under one company-run operator shell
    • Runs fraud and abuse controls around gameplay-linked withdrawals, including geolocation, VPN and proxy checks, device attestation, backend allowlisting, time-alive withdrawal gating, and optional extra verification
    • Markets itself as a licensed payment service provider for gaming and interactive entertainment across the US and Europe, making the company boundary analytically stronger than any one wallet or SDK label
  • Key claims:
    • The docs home describes ZBD as the global Bitcoin payments API for app and game developers and a Global Payment Service Provider for Gaming and Interactive Entertainment, which is an unusually explicit operator-shell framing rather than a narrow app pitch
    • The products page says ZBD handles virtual-currency conversion, compliance, and card management, supports real-money payouts to bank accounts plus endpoints such as Cash App, Kraken, Coinbase, and gift cards, and sells embedded accounts for player-to-player and creator-economy flows
    • The about page says ZBD is a fully licensed payment service provider operating in top gaming markets, with MTL / EMI / MiCAR-style licensing claims, which matters because customers inherit a named regulated entity boundary rather than only an SDK
    • The privacy page footer identifies the operator as ZEBEDEE, LLC with NMLS ID 2188007, while the docs footer links to a ZEBEDEE EUROPE B.V. pricing-policy document, which is useful evidence that the real control surface sits with a multi-entity company shell rather than a protocol brand
    • The Earn SDK security docs say ZBD geolocates users by IP, blocks VPN/proxy sessions from initializing normally, tracks Time Alive with server pings roughly every 20 seconds, uses Apple/Google attestation, recommends backend-only reward sending with IP allowlisting, and can add CAPTCHA or facial-recognition checks for higher-risk withdrawals
    • The OAuth docs frame ZBD Login as money-enabled OAuth2, where users share gamertags, Lightning Addresses, verification status, and other profile data with apps, which reinforces that identity, wallet exposure, and payment capability sit under one company-run auth surface
  • Whitepaper: No classic standalone company whitepaper is the important artifact here. The clearest primary materials are the official about, products, privacy, docs-home, OAuth, and Earn-security pages; the focused source capture for this split is ../whitepapers/zbd-company-primary-sources-2026-08-09.md.
  • Sources:

Internal linkages

Protocol / company boundary

  • There is not a very useful standalone ZBD protocol boundary doing most of the analytical work here.
  • The practical dependency is a company-managed gaming-finance workflow: account onboarding, login, rewards issuance, withdrawal rules, payout routing, cards, embedded accounts, and compliance handling all sit under the ZBD operator shell.
  • That is why this note belongs in companies/: the important questions are who approves the integration, who defines withdrawal and fraud-control policy, who operates the identity and wallet surface, and who packages the regulated money-movement shell behind the game-facing products.

Control surface

  • Practical leverage sits in partner onboarding, geography and payout-method exposure, reward issuance workflow, withdrawal thresholds, anti-fraud policy, backend allowlisting, user identity and permission grants, wallet and payout state publication, and which banking / exchange / gift-card cash-out routes are live in which regions.

  • The sticky dependency is operational memory: once a game or app hardens around ZBD-managed accounts, OAuth scopes, reward events, withdrawal limits, fraud controls, and payout rails, the real lock-in is to the company-run gaming-payments shell rather than only to Lightning or Bitcoin payout semantics.

  • Read ZBD as a company-operated rewards, identity, and payout boundary first, and as a game-finance API bundle second.

  • Last reviewed: 2026-08-09 UTC

Graph View

Backlinks