GhostGames Admin — Complete Knowledge Base

§Executive summary

What this system is, in one paragraph.

1Content analysis & purpose

What the product is, who it serves, and what every piece of visible text is telling you.

1.1 Value proposition

The system's implicit promise to an operator is "run a full multi-vertical gambling site without building anything." Sports feed, casino aggregation, minigames, cashier, affiliate settlement, bonus engine, risk tooling and reporting all ship in one console. Configuration is exhaustive — nearly every commercial parameter (rollover ratios, bet limits per level, cancellation windows, payback rates, comp ratios, referral bonuses, promotion visibility) is editable in the UI rather than hard-coded, which is the signature of a platform built to be resold to multiple operators.

1.2 Who uses it

1.3 Product surface — what is actually on screen

Every page shares a three-band chrome:

1. KPI band — Deposit (count, people), Withdrawal (count, people), Cash Profit, Live Betting amount + live-player count, total user Balance, total user Points, Casino Funds, Active Users. Refreshed from GET /backend/stat/header.
2. Alert strip — 13 counters, each a deep link into a work queue: Deposit Application, Withdrawal Application, Member Registration, Inquiry, Account Inquiry, High Betting (Casino / Sports / Minigame), Casino Unprocessed, Minigame Unprocessed, Account Check Pending, Agent Withdrawal, Unmatched Deposit Message, Result Reversal, Admin Notice. Polled from GET /backend/stat/alert, which returns a {count, last_id} pair per queue so the client can fire a sound only for genuinely new items.
3. Module bar — Content · Agents · Betting Status · Sports Game Management · Minigame · Finance · Analytics · Members · Coupon System · Crypto Payment · Settings, each a hover/click dropdown. Plus Site Home, language switcher (English / 한국어) and Logout.

Below the chrome, screens follow one of four templates: filter + table (about 70 % of pages), settings form, composer (message / coupon / bulk payment), or dashboard (KPI cards + chart). Table pages almost always carry a "• Search Filter" panel with a date range plus quick presets (Last week / This week / Next week / Yesterday / Today, or the monthly equivalents), one or more status/type selects, a search-field selector, and often an Excel export.

1.4 Policies, help text and rules surfaced in the UI

There is no legal/T&C surface in the admin, but operational rules are written into inline help. The most substantive:

• Bank account verification — "Records exceeding 10 minutes without approval/rejection remain in pending status."
• Login-failure blocking — "Members who failed login 3+ times within 30 minutes."
• Attendance — "If an attendance streak exceeds 30 days, attendance after day 30 restarts from day 1."
• Rolling challenge — resets Weekly (Mon 00:01), Biweekly (1st & 16th 00:01) or Monthly (1st 00:01); changes apply from the next round.
• Market config — "Deactivation on this page takes priority over match-level market-type deactivation."
• Casino min bet — "0 means no limit. Bets below this amount are rejected in the game BET callback."
• Point conversion — rollover ratio expressed as an integer percentage where 300 = 3×.
• Coupon revoke — "⚠️ This feature revokes coupons for multiple users at once. Use with caution."
• Page banners — "Banners are auto-generated and only images can be edited."
• Rolling Challenge feature flag — "When enabled, the Rolling Challenge settings page appears in the Content menu, and rolling points accrue on betting."
• Notices & deposit notes accept markdown links in [label](https://example.com) form; message templates accept a {회원명} (member name) placeholder.

The public rulebook itself is authored here too — the Notice & Rules screen contains per-sport regulation documents (football, basketball, baseball, ice hockey, volleyball, American football, MMA/boxing, e-sports), plus platform rules such as "양방 베팅 강력 규제 안내" (strict arbitrage-betting regulation), "축 베팅 및 보험 베팅 안내" (arb/insurance betting), "게임별 롤링 안내" (per-game rolling), "회원 등급별 베팅/당첨 상한" (bet/win caps by member grade) and virtual-sports guidance.

2Functionality mapping

Every interactive pattern, navigation path, real-time feature and integration point.

2.1 Navigation model

A flat two-level menu: 11 modules → 4–18 leaf pages each, no third level. There are no breadcrumbs; the module bar is the only persistent wayfinding. Cross-navigation happens through three other channels, which matter more in daily use than the menu:

• Alert deep links carry pre-applied query state, e.g. /betting/casino?status=BETTING and /finance/unprocessed-deposits?is_matched=false — the counter is a saved search, not just a badge.
• Entity chips — a member chip [LV.2-C] id (nickname) or an agent chip id (name) Main Branch code appears in almost every table and opens the corresponding detail modal in place. This is the real navigation spine.
• Modals — Member Detail, Agent Detail/Edit/Add-Sub, Market management, Bet detail, Adjust Money/Points, Manual Cash. No route change, so modal state is not linkable.

2.2 Interactive element inventory

2.3 Real-time & dynamic content

• GET /backend/stat/header — KPI band; GET /backend/stat/alert — 13 work-queue counters with last-seen IDs; GET /backend/api/admin-notices/unread-count. All polled on an interval on every page.
• GET /backend/stat/refresh-cash — manual "refresh cash" action behind the circular arrow in the KPI band.
• Active session monitor (/backend/users/active-sessions) shows who is online right now with device, IP, last action and an "as of HH:MM:SS" stamp.
• Top Notice pushes a one-line banner to currently-connected players, with a preview endpoint that resolves the audience before sending.
• Live sports — ongoing matches carry live bet counts, staked amount and expected win per match, with a per-match Refresh.
• Dashboard cards carry their own "Cards Updated: <timestamp>" line, i.e. a separate cache from the chart data.

2.4 Integration points

2.5 Automated processes

• Auto level-up on deposit approval, by cumulative deposit tier (and separately by attendance days).
• Auto deposit matching — OnePay / TronScan / bank-message matching, with an unmatched queue and a "Split Suspected" flag for deposits broken into pieces.
• Bet settlement from the feed, with an audited result-reversal path (Feed · Single Edit · Bulk Edit · Data Refresh) that records the affected members.
• Rolling-challenge rounds open/close on the configured cycle and hold an unpaid → paid state per round.
• Scheduled top notices, scheduled banners/popups/events (start & end dates).
• Login-failure auto-block and suspicious-IP detection.
• Payback / attendance / referral accrual evaluated against condition sets rather than manually granted.

3Business logic & processes

The money model, the commission model, the bonus economy and the decision trees behind each queue.

3.1 Business model

This is B2B2C. The platform vendor licenses the stack to an operator; the operator recruits players through a five-tier affiliate tree and pays those affiliates a share of turnover and losses. Revenue for the operator is the classic gambling margin — bet amount − win amount per vertical — presented throughout as "Cash Profit", "Net Profit" and "Total Game Profit". There is no subscription, no cart and no price list anywhere in the product.

3.2 The agent (affiliate) hierarchy

Five tiers observed on live records: Head Office → Main Branch → Sub Branch → Distributor → Distributor 1 (본사 / 부본사 / 총판 / 매장 in the domestic vocabulary). Each agent has a referral/signup code; members are permanently bound to the agent whose code they signed up with, and every table in the product carries an "Agent" column so any figure can be rolled up the tree.

Commission

Two components, both visible on /finance/agent-withdraw:

• Rolling — a percentage of turnover, broken out per vertical: Slot · Casino (Baccarat / Blackjack / Roulette / Others) · Sports · Minigame.
• Losing — a percentage of the sub-tree's net loss.

Settlement cycle

Semi-monthly. Columns are labelled Q1 (1st–15th) and Q2 (16th–end of month), tracked for both "Last Month" and "This Month". Agents then file a settlement request; /agents/settlement-transactions types it as Revenue Payment, Withdrawal or User Grant, records bank/account/depositor, amount, resulting balance, request and process time, status and a division field. An agent can also hold a balance and points and grant them to their own members — those grants are audited separately in /agents/member-money-history and /agents/member-point-history.

3.3 Deposit workflow (decision tree)

3.4 Withdrawal workflow (decision tree)

3.5 Bonus economy — six independent engines

A seventh, the Rolling Challenge, is a leaderboard: bets accrue points at a configurable rate per game type, rounds close weekly/biweekly/monthly, and a prize pool is split by rank bands, tracked per round as Active → Ended (Unpaid) → Paid.

3.6 Player lifecycle

Pending → Approved → (Blocked | Withdrawn), with Rejected as a terminal alternative to approval. Signup can require SMS OTP. Every member carries: level 1–8 (브론즈·실버·골드·플래티넘·다이아 + three unnamed), a level type letter A–X used as a routing/segmentation dimension (it selects which deposit account they are given), a test-user flag, colour tags (box colour / band colour) and free-text alias and memo. Staff accounts are flagged separately so they can be excluded from stats.

3.7 Risk & anti-abuse logic

• High-bet threshold per vertical → dedicated queues plus a repeating sound alert.
• VIP & watch-list tagging — separate betting views keyed on a member tag (/tag/VIP); members are visibly badged for arbitrage/shot-betting (양방/샷벳).
• Bet caps per level: max bet and max win for slot, live casino, sports (plus per-selection max cumulative bet) and minigame; per-match cumulative bet cap; max bets per selection; min/max odds; single-selection odds deduction.
• Odds delay configurable at sport, league, market-type and selection level, plus odds adjustment by total staked on a match, plus cross-betting rules and multi-folder bonus rules.
• Manual market control — hide a match, lock (suspend) a match, manage individual markets, revert a result.
• IP controls — login-failure auto-block (3 fails / 30 min), suspicious-IP detection, manual IP block list with reasons, plus IP whitelists for admins and agents with success/fail access counters.
• Callback failure log for provider wallet errors, so lost bets can be reconciled.

4User experience & usage patterns

How the console is meant to be worked, and where it helps or hurts.

4.1 The daily loop

The product is designed around an alert-driven queue-clearing loop, not around browsing. A shift looks like:

1. Land on Dashboard; glance at the KPI band and the 13-counter alert strip.
2. A sound fires (per-type sound file, optionally repeating until acknowledged). Click the counter → land in a pre-filtered queue.
3. Work the row: open the member chip modal to check balance, level, bank details, memo and history without leaving the page.
4. Approve / reject / allow / answer. Counter decrements. Repeat.
5. Periodically switch to Analytics or the agent settlement screens for the reporting half of the job.

Everything downstream of that loop — settings, sports configuration, bonus rules — is low-frequency, high-consequence work done by a different person.

4.2 Key use cases and their paths

4.3 Onboarding & getting started

There is effectively none for operators — no tour, no empty-state guidance beyond "No data available / No registered data" and "🔍 No search results — please change your search conditions". The single genuine documentation surface in the product is the Crypto Payment → Integration Guide, a developer-facing partner guide with a table of contents, architecture steps, network list, quick-start, fee structure, environment variables, cURL examples and a REST endpoint reference. Its presence (and its "Partner" framing) is strong evidence the crypto cashier is a separately-sold product embedded into this console.

4.4 Accessibility & responsive design

• Reasonable ARIA foundations: <nav aria-label="Main menu">, aria-haspopup/aria-expanded on menu buttons, role="combobox" + role="option" on custom selects, role="dialog" on modals, real <label> elements and semantic <table> markup.
• Responsive: the module bar is hidden md:flex, so a separate mobile menu exists; controls carry dual heights (h-[36px] md:h-[32px]) for touch vs pointer. In practice the data tables are far too wide for a phone — /analytics/games/slot alone has ~60 columns.
• Weak points: very low-contrast tertiary text, no visible skip link, colour-only status encoding in several tables, custom listboxes that need keyboard testing, and a dense 13-item alert strip rendered at ~11 px.

4.5 Personalisation

Per-admin: page and action permissions, an agent scope (scope_root_agent_id) that limits every query to a sub-tree, IP whitelist, TOTP, and per-notification alert sounds. Per-agent: their own scoped view of members, revenue and settlement. Per-member: level, level type, colour tags, memo, per-member rollover overrides and event restrictions. Language is a per-session toggle (English / 한국어).

5Technical architecture

Stack, conventions and observable engineering decisions.

5.1 Stack

5.2 API conventions

• Resource-oriented, kebab-case paths grouped by domain: /backend/users/*, /backend/transactions/*, /backend/agents/*, /backend/sports/*, /backend/admin/sports/config/*, /backend/casino/*, /backend/casino-config/*, /backend/minigames/admin/*, /backend/stat/*, /backend/global-config/*, /backend/campaigns/*, /backend/message/*, /backend/referral/*, /backend/roulette/*, /backend/crypto-payment/*, /backend/security/*.
• Sub-resource configuration is path-parameterised by entity id, e.g. /backend/admin/sports/config/market-configs/{sportId}, /backend/transactions/bank/level-bank-info/{level}/type-configs, /backend/minigames/admin/stats/{gameCode}.
• Filters are query parameters and are URL-addressable — the alert strip relies on this (?status=BETTING, ?is_matched=false).
• Audit is first-class: the audit log stores HTTP method (POST/PUT/PATCH/DELETE) plus before and after snapshots per category.

5.3 Security posture

5.4 Performance & SEO

Code-split per route group with hashed chunks; heavy reference data (agent tree, brand list, level list, sports list) is fetched per page rather than cached globally, so most screens issue 6–10 XHRs on load, five of which are the same chrome calls every time. SEO is irrelevant and correctly ignored — the app is behind auth, with no meta description, canonical or structured data. Dashboard cards are separately cached from chart data (they carry their own "Cards Updated" timestamp).

6Content structure & information architecture

The hierarchy, the tone, and the state of localisation.

6.1 Hierarchy

Plus 4 unmenued routes: /dashboard, /admin-notices, /admin/signin, /admin/signin/verify-totp.

6.2 Key landing pages

• /dashboard — the default landing page and the only true summary screen.
• /members/list — the operational centre of gravity; almost every investigation starts or ends here.
• /finance/deposits and /finance/withdrawals — the two highest-traffic work queues.
• /settings/basic — the highest-consequence configuration screen (cashier limits, rollover, blocked hours, auto-deposit keys).

6.3 Tone of voice

Terse, imperative, operator-to-operator. Section headings use a bullet prefix ("• Search Filter", "• Filter", "• Team List"). Help text is one line of consequence-first instruction — "Deactivated vendors are hidden from users", "Changes take effect only after pressing the Save button", "Set to 0 for no limit". Destructive actions get an emoji warning (⚠️). There is no marketing language anywhere, and no personality: this is a tool, and it reads like one.

6.4 Localisation — the weakest part of the product

Korean is the source language; English is a translation layer, and it is incomplete. Confirmed gaps:

• broken /crypto-payment/integration-guide — most section headings render as raw i18n keys (pages.cryptoPayment.integrationGuide.introduction.features.realtime.title). The whole guide is effectively unreadable in English.
• broken /finance/promo-comp-stats — the entire page is still Korean in English mode (검색 필터 / 조회기간 / 집계기준 / 게임사 / 콤프 지급액).
• partial /agents/settlement-transactions — one column header renders the literal key pages.agents.withdraw.table.memo.
• partial Analytics game tables keep the Korean total column 일별합계 and Korean sport and vendor names in English mode.
• partial Sports configuration screens (market types, region/league) list all 49 sports in Korean only.
• Domain data is intentionally bilingual — team management explicitly stores "Team Name (Original)" and "Team Name (Korean)" with a translation workflow.

6.5 Content freshness signals

Dashboard cards carry an explicit "Cards Updated: <date, time>" stamp; the active-session monitor prints "as of HH:MM:SS"; alert counters carry last-seen IDs; every notice/event/popup/banner row shows created, start and end dates; every ledger row shows "Created At"; audit entries show before/after with a timestamp. Freshness is well instrumented — nothing important on screen is undated.

7Competitive context

Where this sits in its market and what distinguishes it.

7.1 Category

This is a Korean-language online-casino/sportsbook platform back office of the kind sold to operators as a turnkey ("솔루션") package. Its DNA is visible in the vocabulary: 본사/부본사/총판/매장 agent tiers, 롤링 (rolling) and 루징 (losing) commission, 콤프 (comp), 페이백 (payback), 양방 (arbitrage/two-way betting) as a bannable offence, 홀짝 (odd/even) and 파워볼 (Powerball) minigames, 미니게임 as a first-class vertical. These are conventions of that specific market, not of Western iGaming.

7.2 Differentiators observed

• Depth of configurability — bet caps, comp ratios, rollover and payback are all per-level and per-vertical, and rollover can additionally be overridden per promotion, per coupon and per individual member.
• Level-type routing (A–X) — a second segmentation axis beyond level that determines which bank account a player is given. This is unusual and operationally clever: it lets an operator spread deposits across many accounts and quarantine cohorts.
• PayCore — a purpose-built restricted cashier role with per-transaction floors and ceilings, its own statistics and its own action log. Most competitors just hand a cashier a scoped admin login.
• Integrated crypto PSP with an in-product partner integration guide and REST reference.
• Six stacked referral rule types and a seven-engine bonus economy — more granular than typical.
• Result-reversal auditing that names the cause (Feed / Single Edit / Bulk Edit / Data Refresh) and the affected members — a direct answer to the biggest dispute source in this market.

7.3 Compliance & regulatory posture

7.4 Partnerships & supply chain

~110 casino and slot brands (Evolution, Pragmatic Play, PG Soft, NetEnt, Play'n GO, Habanero, Nolimit City, Red Tiger, Relax, Quickspin, Big Time Gaming, Thunderkick, CQ9, KA Gaming, JDB, Spade, Vivo, BetGames, Ezugi, Yeebet, Lucky Streak and many more) reached through one aggregator; five minigame providers (Lotus, BET365 virtuals, NEXT, Bogle, Token Game); one sports odds feed; CA-Payment for crypto; OnePay and TronScan for automated deposit confirmation.

8Actionable insights

8.1 The whole system in five sentences

8.2 Complete feature list

8.3 Gaps, bugs and improvement opportunities

8.4 Replication blueprint

To rebuild this system, the minimum viable domain model is:

8.5 If you own this product, do these five things first

1. Mask the crypto API key and wallet addresses; move third-party keys to a secret store with reveal-on-permission and rotation.
2. Fix the three localisation failures (integration guide, comp-stats page, settlement memo key) — they make the English build look unfinished.
3. Remove or implement /analytics/overview and the /membesr/list typo route.
4. Give the queue-clearing loop keyboard support and URL-addressable record modals — it is 80 % of daily usage and it is the slowest part.
5. Decide deliberately about responsible-gambling and KYC tooling. Its total absence is the single largest structural gap and the one that determines which markets this platform can legally serve.

◫Page catalog — all 108 routes

Every screen with its filters, table columns, actions and API calls. Type to filter; click a row to expand.

⇄API index

Every backend call observed, grouped by domain. All are same-origin under /backend/* unless noted.

Global calls fired on every page load

GET /backend/admin/me/permissions · GET /api/client-ip · GET /backend/api/admin-notices/unread-count · GET /backend/stat/header · GET /backend/stat/alert

Alert payload shape — GET /backend/stat/alert

{ id,
  deposit, deposit_id,
  withdraw, withdraw_id,
  user, user_id,
  inquiry, inquiry_id,
  account_inquiry, account_inquiry_id,
  casino, casino_id,
  minigame, minigame_id,
  highbet_casino, highbet_casino_id,
  highbet_sports, highbet_sports_id,
  highbet_minigame, highbet_minigame_id,
  bank_account_request_uncompleted, bank_account_request_uncompleted_id,
  agent_withdraw, agent_withdraw_id,
  unmatched_deposit_message, unmatched_deposit_message_id,
  sports_revert, sports_revert_id }

External API — CA-Payment (crypto PSP)

Base https://api.ca-payment.com (stage https://stg-api.ca-payment.com). Auth header Authorization: <API_KEY>. Env vars CRYPTO_PAYMENT_API_KEY, CRYPTO_PAYMENT_BASE_URL. Webhook target <your-domain>/crypto-payment/webhook with signature verification.

POST /customer/create · GET /customer/list · GET /customer/{id} · POST /invoice/issue · GET /invoice/detail · POST /invoice/cancel · GET /transaction · POST /transaction/withdraw · GET /transaction/detail/{id}

🔐Permission model

GET /backend/admin/me/permissions returns { id, account_id, nickname, role, page_permissions[], action_permissions[], scope_root_agent_id }. Roles observed: SUPER_ADMIN, SUPERVISOR, "Senior Admin". scope_root_agent_id restricts all data to one agent sub-tree.

Page permissions (94)

Action permissions (62)

≡Enumerations

Every controlled vocabulary found in the UI — useful for schema design and for writing test fixtures.

AGlossary