The application your staff live in all day

A casino is operated by people who are not engineers, at speed, under pressure, at three in the morning. The back office shipped module by module alongside the API — never afterwards — so there has never been a period where operating this platform meant editing the database by hand.

Eight groups, and the menu is data

The payment configuration screen, with its audit history — Payment configuration at 1440px. The group bar and the row of pills under it render from a permission table, not from markup. The History panel on the right is the audit trail for this screen — who changed which field, and when.

Dashboard

What happened today, in your timezone.

Deposits, withdrawals, gross gaming revenue, new players and the queues that need a person. The day boundary is cut in the operator timezone you configured, and the timezone is printed on the screen so nobody argues about which midnight it means.

Money

Work the deposit queue and approve withdrawals.

A deposit sits pending until a staff member matches the transaction id against the agent account. Nothing auto-credits. A withdrawal shows the turnover still owed at the moment the player asked, not at the moment you look, so approving it later cannot quietly change the rule it was judged against.

Players

Find an account and see everything about it in one place.

Profile, balance, ledger, deposits, withdrawals, bonuses, referral position, sessions and the reason for every block. Adjustments require a reason before they can be written, and the reason lands in the audit log next to the amount.

Games

Curate the lobby your players actually see.

Sync the catalog, set what is visible, ordered, featured or hot, and set the turnover weight each game contributes. A re-sync overwrites only what the provider owns, so your curation survives it.

Content

Change the site without calling us.

Banners, promotions, announcements, FAQ, the theme, the brand name. All of it is rows. A theme change takes effect on the next load, in every locale.

Rewards

Run bonuses, VIP, rewards and referral.

Bonus policies with their wagering multipliers, VIP tiers with both thresholds, daily and streak rewards, rebate and cashback, and the agent commission schedule. Each of these is a configuration screen, not a code change.

Reports

Answer a question without a database client.

Betting, transaction, bonus and referral records, read from the one ledger. A row in the betting record is a round, not a transaction, because that is how a player describes their own session.

Settings

Brand, appearance, staff, audit log, your own account.

Payment channels and agent number pools live here too. A staff member sees only the groups containing a page their role can open.

A screen a role cannot open is absent, not greyed out

The menu is rendered from a table of groups, pages and the permission each page needs. A page whose route has not shipped is simply not in the table. The result is that the navigation can never advertise a screen that does not exist, or one the person in front of it is not allowed to reach.

Permissions are bundled into roles

Finance, support, content, games and administration. A role is a set of bundles, so granting someone the deposit queue does not accidentally grant them the theme.

five bundles

Every action writes an audit row

Who, what, which record, the before and the after, and the reason where one was required. The audit model refuses update and delete at the schema level — there is no code path that can edit history, including ours.

append-only

Staff see classified errors, not stack traces

The same classifier the player app uses. A failed action is a toast; a screen whose data did not arrive shows the failure inline with a retry that reloads the whole screen, not half of it.

four surfaces

Two languages shipped, and a third held back on purpose

English and Bangla are at exact key parity. The third is a placeholder until an operator needs it — shipping a half-translated admin screen is worse than shipping one language.

1,329 keys

The deposit queue is the screen that pays for the rest

bKash and Nagad give no merchant API to a gambling account, so a deposit is an agent flow with a person at the end of it. That is a constraint of the market, not a shortcut, and the whole screen is designed around making the match fast and the mistake reversible.

The deposit reconciliation queue — The reconciliation queue. Nothing on this screen credits a balance without a transaction id matched by a person.

Agent numbers come from a pool

Claimed by a single atomic update, so two players submitting at the same instant cannot be handed the same number and produce two transfers nobody can tell apart.

round-robin

A transaction id can only be used once

The guard is an index on the method and the id together, not a check in application code that two staff members can race.

unique index

Approving is a ledger write like any other

The queue does not have its own way to move money. It calls the same entry point a bet does, so a manual credit is as auditable as an automatic one.

one entry point

These four rails — bKash, Nagad, Rocket and Upay — are reference adapters for one market. The queue, the pool and the audit trail are market-agnostic; the rail is not. A new market means a new payment adapter, and we would rather quote that than tell you we support any payment method.

Bring the person who will work this queue to the demo

They will find the awkward case faster than any of us, and that is the point of showing it to them early.

Book a demo