Casino Back Office Software: Requirements Operators Can Test

A back office is where staff can change a player's access, money and entitlements. A polished search screen says little about whether those changes are safe. The useful question is what an authorised employee can see, decide and prove when a provider response is late or a player disputes the outcome.

This guide is for casino operations, product and engineering teams specifying or selecting a back office. It defines requirements through work that must remain explainable: support cases, financial corrections, configuration changes and restricted actions. The examples are hypothetical. Use them to shape a specification for your actual operating model and back-office development, rather than treating every feature as equally necessary.

Give staff a reliable player context

The player view should connect stable account identifiers, brand, currency, verification state, restrictions, wallet categories, provider operations and support history. A familiar email address is not a safe replacement for account identity; similar records must not be merged by an agent's guess.

Show where each fact comes from and how current it is. A cached balance, a pending payment and a confirmed ledger posting are different facts. If an integration is unavailable, label unavailable or stale information instead of displaying an empty list as proof that nothing happened.

Specify search by account, external transaction reference and case identity within the employee's permitted scope. Mask personal information by default where the task does not need it. Sensitive documents should have their own access rules. For acceptance, ask an ordinary support user to reconstruct a disputed deposit using the same tools and permissions they will have in production, including a deliberately delayed provider response.

Treat financial corrections as controlled operations

The back office should issue commands to the authoritative financial service, not let staff edit a balance cell. Each correction needs an operation identity, account and currency, affected balance category, reason, supporting case and traceable postings. Confirm the difference between correcting a recorded financial obligation and granting discretionary goodwill; their approval and accounting treatment may differ.

Hypothetical approval failure: an employee proposes a €25 correction. A supervisor approves it, but the employee changes the proposal to €250 before execution. If approval is only a flag attached to the case, a different transaction can execute under the old approval.

Apply OWASP's transaction authorization principles: server-side enforcement, protected transaction details and a final authorization check before execution. For a staff workflow, bind approval to the exact proposed account, amount, currency, category, reason and version. Material edits require a new decision. The maker-checker pattern means one person proposes and another permitted person approves; prevent self-approval where that policy applies.

Record proposed, approved, rejected, executing, confirmed and unresolved outcomes according to the financial service's real contract. A timeout is not proof of failure. A retry must reference the same business operation and recover its known result without creating another posting. Reconcile uncertain results with the financial service or provider before a separate correction. The UI must not turn a payout's unknown status into permission to pay it again.

Change game availability without losing open rounds

Define which employee may change game availability for which brand, market and channel, and what the change actually does. Hiding a game tile is different from rejecting a new launch or preventing a new wager. A control is incomplete if another route can start the same action.

Separate new activity from obligations already accepted. Disabling a game should follow a documented policy for open rounds, settlements and reversals, with provider references retained. Continue handling legitimate settlement and reversal callbacks under the provider contract; a control for new activity must not discard them. Otherwise, an operational containment action can leave a player with a stake but no explainable result.

Keep versioned configuration, a preview of affected scope, an effective time and an appropriate review step. Test propagation to caches and integrations. An emergency control needs a named owner and observable effect, not just a button. Restoring the previous availability setting does not erase wagers accepted while the new setting was active.

Keep bonus decisions tied to accepted rules

A bonus editor should expose the rules that staff can safely change: eligibility, participating games, contribution rates, expiry, award limits and cancellation behaviour. Specify currency, precision and time-zone semantics where they affect calculation. Do not let a vague free-text field become the only record of an executable promotion.

Store the version accepted by a player and the progress events evaluated against it. Changing a future campaign should not silently reinterpret an existing entitlement. If active bonuses may be changed or cancelled under the approved policy, make that a distinct, reviewed operation with its effects on cash, bonus funds and pending rewards shown before execution.

Require a preview on representative cases before publication. Include excluded games, an expiry boundary, a duplicate contribution and a cancellation with an unsettled round. Compare the resulting entitlement and financial records, not only the campaign's visible status. Bulk awards need operation identities, a result per player and a recoverable exception path.

Make verification and restrictions explicit

Verification is a workflow, not a green label. Define requested, received, under review, accepted, rejected and unavailable states as appropriate to the actual process. Keep evidence provenance, decision time, reviewer and the reason for a decision. Restrict document access independently of permission to see the account's verification status.

Map each relevant restriction to the actions it affects and the service that enforces it. Account suspension, a withdrawal review, a limit and self-exclusion are not interchangeable statuses. A support agent must not accidentally remove one control while resolving an unrelated case.

The operator and qualified advisers must define market-specific verification, safer-gambling, retention and review requirements. This guide does not prescribe a universal threshold or sequence. Implement the approved policy explicitly, including how unavailable verification data is handled. Test the player-facing and staff-facing paths against the same authoritative restriction, and make any permitted override narrow, reasoned and auditable.

Turn risk signals into accountable cases

Risk tools should distinguish a signal from a confirmed decision. A shared device, unusual activity or a provider alert may justify review; it should not be presented as proof of wrongdoing without the decision process the operator has approved.

A case needs source evidence, affected accounts and transactions, severity, owner, status, permitted containment actions and a review history. Separate internal risk notes from information support may disclose to a player. Access to a queue must not automatically grant authority to freeze funds or change verification decisions.

Specify escalation for unresolved cases and ownership when a shift changes. Track queue age and reassignment without making automatic closure a substitute for investigation. Test a false positive, a withdrawn alert and a late update: the final case should explain which evidence led to the decision and which restrictions, if any, remain active.

Design support around ownership and resolution

Support needs a timeline of relevant events and a case workflow, not unrestricted administrator access. Connect messages, provider references, ledger outcomes and controlled actions so that another employee can continue a case without reconstructing it from private notes.

Define assignment, handover, escalation, reopen and closure conditions. Keep a player-facing explanation separate from internal evidence. A case awaiting provider confirmation must remain distinguishable from a solved case, even if a reply has been sent to the player.

Useful queue views show owner, age, dependency and next permitted action. Set response and resolution targets for your staffing and workload rather than inventing a universal service promise. During overload, preserve read-only investigation where feasible and constrain expensive exports or bulk actions. Sensitive recovery paths must remain controlled; an incident is not justification for handing every agent permanent financial permissions.

Scope authority beyond the role name

Start with a permission specification that combines action, resource and context. For example, a support role may read masked accounts for one brand and create a correction request, while finance may approve that request within its assigned scope. Reading a record, downloading its documents, exporting a cohort and executing a financial change are separate permissions.

OWASP's authorization guidance recommends least privilege, denial by default and permission checks on every request. Enforce the decision in the backend. Hiding a menu or trusting a brand identifier sent by the browser is insufficient.

Cover API calls, saved searches, exports, background jobs and downloadable files. Test guessed identifiers from another brand, direct calls to a hidden action and permissions revoked while a request is awaiting approval. Recheck authority and relevant operation state at execution. Use individual identities and controlled temporary access; a shared administrator account undermines attribution even if the action itself is recorded.

Produce evidence that survives a dispute

For a sensitive action, preserve who requested it, their scope, the resource, proposed change, decision, execution outcome, reason, policy or configuration version and links to the case and financial operation. Distinguish an attempted action from an approved one and an approved one from a completed one. Record relevant denied attempts without exposing the protected data.

OWASP's logging guidance addresses sensitive-data exclusion, protected access and tamper detection. Do not copy passwords, access tokens or raw verification documents into ordinary logs. Protect the evidence independently of the employee who can initiate the business change.

Design append-only business history with access controls and tested detection of alteration or deletion. An immutable checkbox in a vendor proposal is not evidence. Define the approved retention and export policy, restore checks and behaviour if evidence capture fails. Do not dispatch an irreversible financial command before its intent is durably recorded. If downstream confirmation is lost, preserve an unresolved state and reconcile the eventual outcome. No system can fix an external payment merely by deleting its audit entry.

Compare proposals through reports and operating scenarios

A report needs a defined metric, source, currency treatment, time zone, cutoff and refresh status. Financial reports should distinguish posted amounts from pending operations, corrections and reversals. A player count or revenue figure without these definitions cannot be reliably reconciled across teams.

Require drill-down from an aggregate to the authorised underlying records, plus an export that retains filters, cutoff and stable references. Control downloads like other sensitive actions. Long-running reports need limits, cancellation and an owner for failures; they must not make operational queues unusable.

When comparing vendors or custom development, use the same scenarios and production-like roles. Ask who owns the financial service, where restrictions are enforced, how configuration propagates and what happens when a dependency fails. Standard integrations can remain replaceable where their contracts and exports meet your needs; custom work is valuable where the operator's workflow or authority model requires it. Include operation, migration, permission maintenance and support costs in the comparison.

Start with one complete, high-impact workflow and its evidence before expanding the feature list. The acceptance checks below are a starting point for an evaluation, not a certification. For deeper design, see back-office roles, workflows and auditability, wallet and transaction ledger design, and security architecture.

• Using a production support role, find a disputed operation by its external reference and identify current, stale and unavailable facts.
• Approve a correction, change its amount and prove the old approval cannot execute the edited proposal; reject self-approval where required.
• Repeat a financial request after a lost response and prove that it refers to the original operation without adding another financial effect.
• Disable new game activity through every supported entry path while retaining the tested handling of open rounds and provider settlements.
• Change a campaign and prove the accepted version and progress of an existing bonus remain explainable under the approved policy.
• Attempt a restricted player action and an unrelated staff override; verify the authoritative control and permission checks hold.
• Request another brand’s record, a document and an export through direct API calls; prove prohibited access is denied.
• Export an authorised case history and reconcile proposal, approval, postings and report cutoff; test recovery when evidence capture or a dependency fails.