Operator guideENtransactionsdetailmodal

Transactions / Shared Detail Modals

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

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 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 services. 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 frontend-only presentation logic.
  • When either modal opens before its payload is ready, the component shows a skeleton placeholder rather than a dedicated backend-driven loading contract.

Verification status

  • status: verified_fe_only
  • last verified: 2026-04-18
  • note: shared modal behavior, grouping logic, payload gating, and parent list-service ownership are traced. It remains verified_fe_only because the modal layer is still a reused FE payload viewer rather than a dedicated backend detail contract.
Operator actions

Actions

action

More Info

Location
parent-row-action
Availability
Visible only when the parent row exposes `moreDetails`.
Result
Opens `TransactionMoreDetailsModal` with the already loaded row payload.
action

Info

Location
withdrawal-provider-request-action
Availability
Visible only on withdrawals rows that expose `postponedResumeParams`.
Result
Opens `TransactionPostponedModal` with the provider-request payload.
action

Close

Location
modal-shell
Availability
Standard modal close control from `ModalContainer`.
Result
Closes the current helper modal and returns the operator to the parent list.
Calculation notes

Calculations

calculation

Payload-gated open behaviour

Formula Text
The generic detail modal opens only when the selected row has `moreDetails`. The postponed modal opens only when the selected withdrawals row has `postponedResumeParams`.
Operator Note
Operators cannot open these helpers for rows that do not already carry the required payload.
Verification Status
verified_fe_only
calculation

Modal header derivation

Formula Text
The generic modal derives its transaction label from `type | transaction_type | transactionType` and derives the status chip from `status | transaction_status | transactionStatus | selectedTransaction.statusEnum`.
Operator Note
The labels in the header are presentation helpers, not dedicated backend enum contracts for this modal.
Verification Status
verified_fe_only
calculation

Grouped key-value render

Formula Text
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.
Operator Note
A row can disappear from the modal simply because its payload key is absent or null.
Verification Status
verified_fe_only
calculation

Skeleton placeholder state

Formula Text
When the modal component mounts without a payload object, it renders a local skeleton layout instead of a backend-driven loading state.
Operator Note
This helper state is frontend-only and should not be read as proof that a detail request is still in flight.
Verification Status
verified_fe_only
Operational notes

Notes

item

The generic shared modal is fed by parent list queries rather than a modal-specific backend route.

item

The postponed modal is fed from `withdrawals.tsx` through `selectedTransactionAdditional.postponedResumeParams`.

item

Status and type badges are frontend-derived from common payload keys.

item

Currency/date grouping is frontend-only organization, not a backend schema contract.

item

Banking and failed-deposit pages mount only the generic modal; the postponed modal is withdrawal-only.

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.