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 top-level Transactions page is only a landing/header page in the current Backoffice. The real work happens in the child surfaces listed below, each with its own fields, filters, actions, and caveats:

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

Surface map

This documentation pack covers these operator-facing transaction surfaces:

• 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. If an operator needs rows, filters, exports, approvals, provider payloads, or document review, start from one of the child surfaces.

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
• Failed Deposit Error Groups for maintaining the reason groups used by failed-deposit triage
• 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.

Current coverage

The module overview is verified against the current Backoffice navigation and page layout. It is intentionally an orientation page: detailed field lists, formulas, mutation side effects, and source-specific caveats live on the child surface pages where operators actually work.

Known limitation: the top-level landing page does not expose a grid, form, export, or mutation action, so there are no standalone transaction fields to document on this page itself.