Casino software: the stack, component by component
The same operation as the platform page, viewed from the engineering side. What each component is responsible for, where the seams between them sit, and which ones you can safely let somebody else own.
- Technical founders
- CTOs
- Heads of product
Why the seams matter more than the features
Feature lists for casino software converge quickly — everyone has a wallet, everyone has bonuses, everyone has reporting. What differs is where the boundaries are drawn, because the boundaries decide what breaks and who can fix it.
The seams that matter are the ones money crosses: the game provider callback that reports a bet, the payment webhook that reports a deposit, and the internal boundary between a wallet balance and the ledger it is derived from. Each is a place where two systems can disagree, and the design question is what happens when they do.
A good answer looks like this: one system is authoritative, disagreement is detectable, and reconciliation is a routine job rather than an incident. A bad answer is two systems each holding a number and a nightly export hoping they match.
The components
- Identity and sessions
- Player registration, authentication, session lifecycle and revocation. Player identity is deliberately separate from operator identity — different tokens, different guards, different storage — because a bug that conflates them is a privilege escalation.
- Wallet and ledger
- Double-entry accounting underneath a balance projection. Player wallet accounts are credit-normal liabilities: a credit increases what the player can spend. Posted entries are immutable, and the projection is updated in the same transaction that posts the entry, so the two cannot drift.
- Catalogue and game sessions
- Syncing games from the aggregation layer, enabling them per brand, and starting, polling and ending a game session. This boundary owns catalogue and session integration and nothing downstream of it — bets, wins and rollbacks belong to the wallet.
- Payments
- Payment intents, provider connections per brand, webhooks in both directions, and the mapping from a provider's vocabulary to a ledger entry. Credentials live in a secret store and never appear in a DTO, a log or a frontend payload.
- Bonus engine
- Provider-neutral, driven by wallet and betting events rather than by hooks inside a specific game integration. That is what lets bonus mechanics survive a change of game provider.
- Compliance
- Identity checks, AML screening, monitoring subscriptions and responsible-gaming restrictions, each with an audit record. A restriction that only writes its own table is a badge — it also has to move the primitive the login and launch gates actually read.
- Back office
- Where the operator works: Dashboard, Players, Catalog, Sportsbook, Payments, Treasury and the rest. Permissions are granular, and platform-admin and operator role namespaces are deliberately distinct even where the role names look alike.
Integration slots
Named by what they do rather than by vendor, because the seam is the durable thing and the vendor behind it is swappable and under contract.
| Slot | What it carries |
|---|---|
| Game aggregation | Slots, live dealer and table content through one authenticated catalog sync. |
| Sportsbook engine | Pre-match and in-play, settled against the Casinofy wallet over signed callbacks. |
| Crypto rails | Address derivation, deposit observation and AML screening across the enabled assets. |
| Fiat PSP | Cards, bank transfer and wallets through a hosted payment connection per brand. |
| Email delivery | Transactional player and operator mail on a dedicated sending domain. |
| Bonus engine | Provider-neutral bonus lifecycle driven by wallet and betting events. |
Multi-tenancy is an architectural decision, not a feature
Whether one deployment can safely run several brands is decided at the data layer, and it cannot be retrofitted cheaply. The two common approaches are an instance per brand — simple, expensive, and it multiplies every operational task — or row-level isolation with the brand as the tenant.
Casinofy takes the second: the brand is the tenant, and every downstream row carries that tenant identifier, enforced by row-level security in the database rather than by a WHERE clause somebody has to remember. The runtime connects as a non-owner role precisely so those policies actually apply.
The practical consequence is that a second brand costs a configuration, not a deployment — and that a query which forgets its tenant returns nothing rather than everything.
The API
The platform publishes 724 REST paths covering brands, players, catalogue, wallet, payments, sportsbook, compliance and the operator console itself. Everything the back office does is available programmatically, because a back office built on a private API is a back office you cannot automate around.
Brands get their own API keys and webhook subscriptions, with test delivery, so an operator integrating a CRM or a BI tool is not waiting on anybody.
Common questions
Is casino software the same as a casino platform?
In most conversations, yes. Where a distinction is drawn, 'software' covers the whole category including game content, and 'platform' means the operational core that content plugs into.
Can I use my own game provider?
Game content reaches the platform through the aggregation slot. A direct studio relationship is an integration question rather than a platform limitation — worth discussing against what the aggregation layer already reaches.
Do you offer an API?
Yes — 724 REST paths, with per-brand API keys and webhooks including test delivery.
How is player data isolated between brands?
The brand is the tenant, and isolation is enforced by row-level security in the database rather than by application filtering. The runtime connects as a non-owner role so the policies are not bypassed.
Look at the real thing
The demo is a live storefront running on this stack — lobby, live tables, cashier and sportsbook — with no signup.