The challenge

A new product on the same wallet, no separate UA.

The operator already had a casino brand with active players. A separate microsite would have duplicated account, payment and compliance integration. The hypothesis was that a shared wallet, approved identity record and player view could reduce journey friction, while product-specific eligibility and any additional KYC/AML checks remained in force.

What we did

Polybetting embedded; casino as the cross-sell target.

Polybetting deployed inside the existing casino product with a shared wallet and player account. Previously verified users could reuse approved identity data, subject to product-specific eligibility and any additional KYC/AML checks. The case used Polymarket as the first documented source; Kalshi and Manifold remain roadmap items rather than live integrations.

CROSS-SELL FLOW · SAME WALLET PREDICTION MARKETS Players who placed a prediction-market bet defined cohort SHARED WALLET · APPROVED KYC FLOW Single-tap to casino No duplicate onboarding · checks as required CASINO Placed a casino bet on the same balance measured per deployment
Same-wallet cross-sell from Polybetting into casino. Cross-sell economics are measured per deployment; per publication policy, exact rates are shared in proposals, not published.
Results

By the numbers.

  • A meaningful share of Polybetting players placed a casino bet in week one
  • Cross-sell cohort showed a lifetime-value uplift versus the casino-only baseline
  • Shared wallet and approved identity flow; product-specific checks still apply
  • Polymarket as first source — Kalshi and on-chain on the roadmap

Evidence status: first-party case claims pending a governed evidence pack with cohort dates, definitions, denominators, exclusions and source snapshots.

Polybetting paid for itself in casino within the first month. That was the test.
Anonymous (operator-confidential) CCO · Tier-2 operator
Share LinkedIn Telegram Email