Operator guideENtransactionscrmgridsoperations

Transactions Overview

Operator map for banking, casino, withdrawal, failed-deposit, and KYC transaction surfaces in Backoffice CRM.

Reader view

Clean portal guidance

This page keeps the operator explanation, field and action descriptions, and screenshots visible without exposing repo paths, raw sidecars, or editorial-only implementation details.

Narrative content

Page body

What this module is for

Use the Transactions area when an operator needs to inspect money movement, game transactions, payout queues, failed payment triage, or KYC document flow.

The module is not one single report. It is a group of operational surfaces with different ownership:

  • banking transactions and payment-state investigation
  • casino transaction monitoring
  • withdrawal processing
  • failed deposit triage
  • KYC document review

Surface map

This Cycle 1 pack covers these operator-facing surfaces from nx-admin-fe-workspace:

  • transactions/banking
  • transactions/casino
  • transactions/casino/[transactionId]
  • transactions/withdrawals
  • transactions/failed-deposit
  • transactions/failed-deposit-error-groups
  • transactions/kyc
  • the shared transaction detail modal used by banking, withdrawals, and failed deposits

The bare /transactions route currently behaves as a navigation landing page, not as a working grid. The real work starts on the child routes above.

How to use this documentation

Open the surface that matches the operator task:

  • Banking for deposit, withdrawal, bonus, and payment-provider transaction history
  • Casino for game-level bet and win rows
  • Withdrawals for action-heavy payout handling
  • Failed Deposit for payment failures and error grouping
  • KYC for document verification workflow

Use the shared Transaction Detail page when the CRM opens the reusable “More Info” modal instead of a dedicated route.

Where users usually get confused

The most common transaction questions are:

  • what is the difference between banking and casino transactions?
  • why does a row open a modal in one screen and a full page in another?
  • which actions really change transaction state and which only show provider payloads?
  • why do some filters use tag chips and some use free-text search?

The surface pages below explain those differences instead of treating the whole module as one grid.

Verification status

  • module status: draft
  • module note: the routes, filters, columns, and visible actions are mapped from nx-admin-fe-workspace
  • backend note: mutation and aggregation semantics still need route-to-service verification in gs-admin-backend and gs-casino-backend
Related references

Related pages

pageTransactions / Banking

Filterable banking transaction dashboard with weekly summary cards, backend stats charts, CSV export, and a detailed ledger-style table.

pageTransactions / Casino

Game transaction dashboard with real-time list mode, monthly analytics mode, filterable table, and a dedicated transaction detail route.

pageTransactions / Casino Transaction Detail

Read-only detail page for a single casino transaction identified by `casinoTransactionId`.

pageTransactions / Failed Deposit

Triage grid for failed deposit rows, their provider reasons, and the error-group classification used for later analysis.

pageTransactions / Failed Deposit Error Groups

Configuration surface for creating, editing, importing, exporting, and assigning failed-deposit error groups and their reasons.

pageTransactions / KYC

Action-heavy KYC document queue exposed under the transactions area for document review, verification, re-request, download, and third-party checks.