Platform overview
Casino, sportsbook, wallet, aggregation, analytics and APIs are modules of a single system. They share one data model, one permission system and one API, so a rule set once holds everywhere.
01Shared foundation
Most platforms grow by adding products next to each other. Poocraft's modules sit on the same three foundations, which is what keeps them consistent.
01
One data model
Players, brands, markets, transactions and events are defined once. Casino and sportsbook read the same player and the same balance, so there is nothing to synchronise between products.
- One player record across products
- One event stream for reporting
- Tenant and brand on every record
02
One permission system
Every console action and every API call passes the same role check. A permission granted to a member of staff means the same thing in the catalog, in finance and in configuration.
- Roles defined per tenant
- Checked on the server, on every action
- Each decision written to the audit log
03
One API
The operator console is a client of the same versioned API your developers use. Anything your team can do in the interface can also be automated.
- Versioned under
/api/v1 - Scoped API keys
- Signed webhooks for every event
- Versioned under
02Modules
Each module has a clear contract with the others. You can run the full platform, or connect a single module to systems you already have.
- 01
Casino
Content
Catalog, categories, lobbies, tournaments and promotions for every connected game source, managed per brand and per market.
Casino solution- Lobby and category configuration
- Per-market availability
- Tournaments and promotions
- 02
Sportsbook
Betting
An integration layer for external sportsbook services: one model for events, markets and prices, with operator-side controls and monitoring.
Sportsbook solution- Feed adapter contract
- Market and margin configuration
- Event monitoring and settlement
- 03
Platform Management
Control
Tenants, brands, staff, roles and configuration. Every administrative change is attributed to a person and written to an audit trail.
Security architecture- Multi-brand, multi-tenant structure
- Role-based access control
- Audit log
- 04
Wallet & Payments
Finance
A double-entry ledger with immutable transactions and idempotent writes, connected to payment service providers through adapters.
How the ledger works- Double-entry ledger
- Idempotency on every write
- Reconciliation reports
- 05
Game Aggregation
Connectivity
One adapter contract for game sources. Launch, round and settlement flows are normalised before they reach the catalog or the wallet.
Integration model- Unified launch and settlement
- Adapter health and latency
- Sandbox adapter for testing
- 06
Analytics
Insight
Operational events from every module in one reporting layer, with dashboards, filters, exports and scheduled reports.
How reporting works- Event-based reporting
- Operational dashboards
- Exports for finance and compliance
- 07
API Integration
Developers
Versioned REST endpoints, signed webhooks and a sandbox, so your team can integrate and test before any real traffic.
Developer documentation- Scoped API keys
- Signed, retried webhooks
- Sandbox with generated data
03Wallet & payments
The wallet is an accounting system first and a balance second. Four rules make it trustworthy under retries, failures and audits.
- Double-entry
- Every movement of funds is recorded as balanced debit and credit entries between accounts. Value is never created or lost inside the ledger; it only moves.
- Immutable transactions
- Posted entries are never edited or deleted. A correction is a new transaction that references the one it reverses, so the full history stays readable.
- Idempotency
- Every write carries an idempotency key. If a request is retried after a timeout, the ledger returns the original result instead of posting twice.
- Reconciliation
- Ledger totals are compared with game source and payment reports. Differences surface as open items for your finance team, not as surprises at month end.
Journal · round_58210
1posted2| # | Account | Debit | Credit |
|---|---|---|---|
| 01 | player:9041:cash | 25.00 | |
| 02 | operator:stakes | 25.00 | |
| 03 | operator:stakes | 62.50 | |
| 04 | player:9041:cash | 62.50 | |
| Balanced | 87.50 | 87.50 |
Idempotency
3Reconciliation · today
4What happens when a stake is placed
- 1
Request
A debit arrives with an idempotency key and a reference to the game round or bet.
- 2
Check
Balance, limits and responsible gaming rules are evaluated before anything is written.
- 3
Post
A balanced set of entries is written in a single database transaction.
- 4
Confirm
The new balance is returned and a signed webhook reports the posting.
Where payments fit. Deposits and withdrawals reach the ledger through payment service provider adapters. Poocraft provides the ledger and the adapters; the funds and the payment relationships belong to the operator.
04Platform management
Operations, finance, support and compliance use the same console with different permissions. Select a workspace to see it.
Active players
12,480
▲ 4.2%
Turnover · 24h
1.84M
▲ 6.1%
Open bets
38,204
▼ 1.1%
Adapters healthy
6 / 6
Activity · all brands
LiveNeeds attention
- PSP latency above threshold
- Tournament starts in 2h
- 2 transactions flagged
- Scheduled report ready
Console previews run on generated data. Figures are not performance claims.
Brands and tenants
Run several brands on one tenant, each with its own markets, currencies, limits and look.
Staff and roles
Least-privilege roles for each team, with permissions enforced on the server for every action.
Configuration without deployment
Limits, jurisdictions, lobbies and feature flags are settings your team changes in the console.
Audit trail
Who changed what, when and from where, recorded for every administrative action.
Player management
Profiles, verification status, limits and session history, with responsible gaming controls on each account.
Financial operations
Approval queues, flagged transactions and reconciliation against game sources and payment providers.
Turnover · 30d
1.84M
▲ 6.1%
Bets
412K
▲ 3.4%
Avg. bet
4.47
▼ 0.8%
Turnover · all brands
30dBy product
Event report · today
export csv| Event type | Module | Count |
|---|---|---|
| game.round.settled | casino | 18,402 |
| wallet.transaction.posted | wallet | 41,930 |
| sportsbook.market.suspended | sportsbook | 212 |
| compliance.check.completed | players | 96 |
| report.export.ready | reporting | 4 |
05Analytics
Every module writes operational events to one reporting layer. Dashboards, exports and the Reporting API all read from the same source, so the numbers agree.
- Event-based
- Reports are queries over recorded events such as rounds, bets, transactions and logins, not separate counters that can drift.
- Operational dashboards
- Activity, adapter health and queues by brand, product and market, updated as events arrive.
- Exports and schedules
- On-demand and scheduled exports for finance and compliance, delivered as files or through the Reporting API.
- Scoped by role
- A report shows only the brands and data categories the viewer's role allows.
06API
Wallet, catalog, launch sessions, sportsbook events, compliance checks and reports are available to your developers under one set of conventions.
- Base path
- /api/v1
- Authentication
- Bearer API keys with scopes
- Events
- Signed webhooks
- Testing
- Sandbox with generated data
POST /api/v1/wallet/debit
Authorization: Bearer pk_sandbox_••••••••
Idempotency-Key: 7c1e9a52-0b7e-4f0e-9a51-2f6f3b1c8d10
Content-Type: application/json
{
"player_id": "pl_9041",
"amount": 2500,
"currency": "EUR",
"reference": "round_58210"
}Illustrative example. Endpoints and payloads are finalised during onboarding.
Next step
Tell us about your operation. We will show you the platform on the parts that matter to you.