Operator back-office

The operator workspace is served at /admin/. Use a named staff account with the permissions required for your job. Your active brand determines tenant-scoped queries and actions; a platform administrator has separate global powers.

Enable or disable a market

1. Open Events & markets, choose the event status and sport, and search for the event by team, competition or ID.
2. Expand Markets and search by market name or ID.
3. To disable it, enter a useful reason and select Disable market. The change applies to your brand; the platform administrator’s control applies globally.
4. To enable it, select Enable market. This removes only your own hold.

The screen shows two independent facts: your team’s control and the market’s effective status. A market can be enabled by your team while still suspended by the feed, producer health, event status or the platform. Enabling it cannot bypass those restrictions. Disabling it also works while the feed has it suspended, so a subsequent feed update cannot accidentally reopen your offering.

The control is saved before the server confirms it. Existing bets are not deleted, voided or repriced by a market switch. Audit entries record the actor, market, scope, time and suspension reason. Traders without trading.write cannot mutate controls; read access alone is insufficient.

Exposure limits

Open Risk → Exposure rules & alerts. Propose a ceiling per event, competition, brand or explicit group of correlated events. An empty event or competition applies a separate ceiling to every event or competition. Alert does not block acceptance; Block new bets above the limit checks reserved capacity before debit and again before accepting the bet.

The total includes reserved/open payouts, unconfirmed payments and unrecovered corrections. Each bet counts once per matching group; opposing positions do not offset. Refunds and already confirmed cash-outs remain owed even above the cap. Disabling a rule does not reopen markets that it suspended.

The company aggregate limit sums its brands in the same currency and environment and requires two distinct platform administrators. Brand limits still apply. Every change requires a reason and approval of the current version; agree the ceilings with your risk team before enabling them.

Financial delivery is not the bet result

Open Operator workspace → Integration → Financial delivery and exceptions. This queue includes unresolved obligations of any age, for internal and seamless wallets. The wallet-call history below it concerns seamless callbacks.

State	Meaning	Operator action
Pending	Awaiting dispatch, confirmation or a preceding movement	Compare the original transaction ID with your wallet. Do not issue a new payment.
Processing	A worker owns the current delivery attempt	Let the bounded attempt finish. A crash is recovered with the same ID.
Review required	Definitive refusal, an unfunded correction, or an unconfirmed credit superseded by a correction	Investigate both ledgers using the original IDs. No automatic replay of an obsolete credit or collection of later deposits.
Waiting for previous movement	An older obligation of this bet is unresolved	Resolve that predecessor before considering later movements.

The table shows up to 200 oldest matching obligations. Search by transaction, bet or player ID; the indicators always count the brand’s complete unresolved queue. The callback history shows up to 200 latest matching calls, attempts and HTTP results. A payment can be owed even when no callback has been sent yet.

A correction that exceeds the player’s balance is refused in full. There is no negative balance, partial automatic collection or capture of future deposits. Never replace the transaction ID to bypass a refusal. Escalate using the original IDs and sanitized evidence; do not close the financial obligation merely by closing a support case.

Reconciliation of pending seamless calls uses the original identities and follows the approval workflow. It does not fabricate a new financial command or mark a refused posting paid. The current transport has no remote transaction-status API; wallet semantics explain recovery and its limits.

Operational responsibilities

Area	What to verify
Organization and access	Correct brand/company, named accounts, least-privilege roles, MFA and allowed IPs. A read-only support view cannot execute mutations.
Approvals	Sensitive configuration and financial actions go through the configured maker/checker workflow. Check the payload, scope and evidence before approval.
Risk and trading	Limits, exposure and feed health agree with the offered markets. Event exposure can overlap across accumulator selections; do not sum it as independent liability.
Bets and results	Distinguish accepted stake, sporting result, cash-out closure and wallet delivery. Manual result changes require an explicit reason and the applicable approval.
Players and support	Confirm tenant and player identity. Restrictions, cases and financial records have different lifecycles.
Integration	Correct callback URL, secret ownership, embed origins, current documentation and homologation evidence. Key rotation requires coordinated deployment.
Reports and billing	Confirm currency, timezone, filters and accounting basis. Owed settlement amounts in reports are not proof of wallet delivery or bank collection.
Content and promotions	Review draft, eligibility, limits and published terms before publishing. A feature toggle does not establish provider availability or contractual rights.
Operations and audit	Track incidents, errors, pending approvals and unresolved money. Health metrics describe their measurement window, not an unconditional uptime guarantee.

Before opening a brand

Complete certification, check the real environment and providers, and review the go-live checklist. A configured tenant, published theme or running staging deployment is not proof of live wallet or feed certification. Record release ownership and the rollback plan before activation.