Casino backoffice software

The room your team runs the casino from.

Not an admin panel bolted onto an API. The workspace the operation actually happens in.

Callisto Operator OS is the backoffice that ships with the platform: players and their money, brands and their settings, payments awaiting review, games and bonuses, marketing, reports, support tickets and platform administration — one workspace, one set of permissions, one audit trail.

One workspace
Every domain, one login
Role-based access
Down to the individual permission
Multi-brand
One backoffice, many skins
Every action logged
Who did what, and when
What it looks like

Screens, not a feature list.

The artwork below is the product as it ships. Nothing here is a mock-up drawn for a website.

01

Operations dashboard

The numbers an operator opens the day on — deposits, withdrawals, GGR, registrations and the alerts waiting for someone — scoped to the brand and the period they picked, and remembered for the next visit.

Callisto Operator OS dashboard showing deposits, withdrawals, GGR and player registrations
02

Player management

One player, everything about them: balances across wallets, transaction and game history, KYC status and documents, responsible-gaming limits, bonuses, notes and the log of everything staff have done to the account.

Player profile in the Callisto backoffice with balances, transactions and KYC status
03

Payments and providers

Deposits and withdrawals as a queue rather than a report: what is waiting for approval, what is on hold and why, which provider handled it, and manual entries when something has to be corrected by hand — each one signed by the person who made it.

Payment review queue in the Callisto backoffice with provider and status columns
04

Site Builder

The storefront of each brand — layouts, branding, published pages, legal content and analytics configuration — edited with a live preview and published per skin, without a deployment.

Site Builder in the Callisto backoffice editing a casino storefront with live preview
05

Support desk

Two tiers in one place: players write to their brand, operators write to the platform. Threaded tickets, attachments, internal notes that the player never sees, and a ticket number that survives the conversation.

Support desk in the Callisto backoffice with a threaded ticket and internal notes
What is in it

Every domain the platform has, in one place.

The backoffice is not a subset of the platform with the interesting parts sold separately. If a service exists, its screens are here.

Players and brands

  • Player search, profiles and balances
  • KYC review and document queues
  • Responsible-gaming limits and interventions
  • Customers, brands and per-skin settings
  • Countries, currencies and languages

Money

  • Deposit and withdrawal review
  • Payment providers per brand
  • Manual adjustments, signed
  • Statements, invoices and billing
  • Agent and affiliate commissions

Product

  • Games, providers and lobby configuration
  • Bonus campaigns, free spins and wagering
  • Progressive jackpot pools
  • Marketing campaigns, segments and journeys
  • Site Builder and Content Studio

Oversight

  • Reports and dashboards with CSV export
  • Risk alerts and compliance cases
  • Support tickets, both tiers
  • Users, roles and permissions
  • Audit log of every action
Who can do what

Permissions that reach a single button.

A casino backoffice holds money, player data and the controls a regulator asks about, so access is not a job title — it is a set of permissions somebody granted, and a record of them granting it.

Roles are made of individual permissions

A role is a named set of permissions rather than a fixed tier, so a payments reviewer who may approve withdrawals up to a threshold and read nothing else is a role you define rather than a feature request.

Scoped to the brands a person works on

Access is bounded by tenant and skin. An operator working one brand does not see the players, payments or reports of another, and a platform-level user sees across them by permission rather than by accident.

Every action is written down

Who approved the withdrawal, who changed the limit, who reopened the case — with a timestamp, in an append-only log. A status that moved with nobody attached to it is the one thing the audit trail exists to prevent.

Session and password policy are yours to set

Password rules, two-factor authentication, session length and idle timeout are platform settings rather than assumptions baked into the code, because the answer differs by market and by operator.

Running more than one brand

Configure once. Override where it matters.

Settings cascade from the platform to each customer and on to its skins: the platform carries the base defaults, the customer adapts them, and a skin inherits everything it does not need to change. The narrowest defined level wins, which is what makes a second brand a configuration exercise rather than a second deployment — and what keeps a stricter market from inheriting a looser market’s defaults.

Common questions

Backoffice questions.

What operations teams ask when they are the ones who will live in it.

Included. Callisto Operator OS ships with the platform, in source, and it is the same workspace we use — not a cut-down demo build. There is no per-seat licence in the architecture and no module of it held back as an upsell.

Yes, and that is the point of receiving the source. The backoffice is a React application that talks to the platform through a documented BFF; your engineers can change a screen, add a column, or build a screen that only your operation needs. Nothing here is compiled behind a licence check.

That is the normal case rather than an edge case. Users, roles and data are scoped by tenant and skin, so a group can run many brands from one workspace while each brand’s staff sees only its own. Settings cascade platform → customer → skin, so a new brand starts from sensible defaults and overrides only what differs.

State changes with the person attached: payment approvals and rejections, manual adjustments, limit and policy changes, KYC decisions, case decisions and reopenings, role and permission changes. The log is append-only and, where it matters most, written in the same transaction as the change it describes — so a status cannot move without the record moving with it.

It is built for a desk. The screens are dense on purpose — a payments queue and a player profile are tables, and shrinking a table to a phone makes it worse rather than more portable. It is usable on a tablet; the operation it is designed for happens on a monitor.

Longer than a demo suggests and shorter than a platform of this size implies, because the screens are consistent: the same filters, the same table behaviour, the same detail-page shape across domains. A walkthrough on your own data is the honest way to judge that, and it is what we would rather do than write a number here.

Look at it with the people who will use it.

Bring your operations lead, your payments reviewer and whoever answers to your regulator. A walkthrough on real screens settles in an hour what a feature list argues about for a week.

Request a guided walkthrough

We reply within a day, usually the same one.