Operator guideEN

Transactions / Shared Detail Modals

Reusable read-only transaction payload modals for banking-style rows on banking, withdrawals, and failed-deposit surfaces.

How to use this guide

Start with the main guide

Follow the explanation and examples first. Extra definitions and formulas are available below when you need them.

What this surface shows

This pack covers the shared transaction detail helpers opened from several transaction grids when the row exposes additional payload data.

It currently includes:

  • the generic More Info modal fed by moreDetails
  • the withdrawal-only Postponed provider-request modal fed by postponedResumeParams

Both modals are read-only inspection surfaces. They do not fetch a separate detail route. They format payload objects already loaded into the parent row and inherit their backend semantics from the parent list query that produced that row.

How to read it

The generic More Info modal groups keys into operator-friendly blocks:

  • primary identifiers
  • currency and amount fields
  • date and time fields
  • all remaining provider payload fields

It also derives a visual transaction label such as Deposit, Withdrawal, or Bet from the payload when possible, plus a frontend-only status chip.

The withdrawal-only Postponed modal adds:

  • a fixed Postponed header chip
  • a postponement-reason card
  • an optional expected-resolution card
  • the same shared key-value renderer for the raw provider payload

When to use it

Use these modals when the grid row itself is too compact and the operator needs raw provider or transaction metadata without leaving the current list page.

Known caveats

  • The generic More Info modal depends entirely on selectedTransaction.moreDetails; it does not run its own fetch.
  • The postponed modal depends entirely on selectedTransactionAdditional.postponedResumeParams; it also does not run its own fetch.
  • Banking, withdrawals, and failed-deposit pages all reuse the generic modal, but they feed it from different parent list data. Treat it as a shared payload viewer, not as a standalone source of truth with one guaranteed schema.
  • The postponed modal is withdrawal-only. Banking and failed-deposit rows do not mount it.
  • Payload shape differs by source system, so field inventory is not guaranteed to be identical across rows.
  • Both modals open only when the parent row exposes the required payload object. A row with no moreDetails or no postponedResumeParams does not show the corresponding action button.
  • The header chips, transaction-type labels, status labels, and field grouping are page-only presentation logic.
  • When either modal opens before its payload is ready, the page shows a skeleton placeholder rather than a dedicated source-driven loading contract.

Shared modal behavior, grouping logic, payload gating, parent-list ownership, and withdrawal-only postponed payload behavior have been traced. Treat this modal layer as a reused payload viewer rather than a dedicated detail contract.

More details

Definitions and formulas

Open only the section you need. The relevant section opens automatically when you request help for a specific item on screen.

Calculations4 topicsOpen details

Payload-gated open behaviour

How It Works
The generic detail modal opens only when the selected row has `moreDetails`. The postponed modal opens only when the selected withdrawals row has `postponedResumeParams`.
What To Check
Operators cannot open these helpers for rows that do not already carry the required payload.

Modal header derivation

How It Works
The generic modal derives its transaction label from `type | transaction_type | transactionType` and derives the status chip from `status | transaction_status | transactionStatus | selectedTransaction.statusEnum`.
What To Check
The labels in the header are presentation helpers, not dedicated backend enum contracts for this modal.

Grouped key-value render

How It Works
Both modals pass the payload object into `KeyValueDisplay`, which filters out `null` and `undefined` values and groups the remaining keys into identifiers, currency, dates, and other fields.
What To Check
A row can disappear from the modal simply because its payload key is absent or null.

Skeleton placeholder state

How It Works
When the modal component mounts without a payload object, it renders a local skeleton layout instead of a backend-driven loading state.
What To Check
This helper state is frontend-only and should not be read as proof that a detail request is still in flight.
More help

Related pages

Transactions / Banking

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

Transactions / Casino

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

Transactions / Casino Transaction Detail

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

Transactions / Failed Deposit

Triage grid for failed deposit rows, provider failure reasons, normalized error groups, raw detail inspection, and CSV export.

Transactions / Failed Deposit Error Groups

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

Transactions / KYC

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