What This Surface Shows
Transactions / Withdrawals is the operator queue for customer withdrawal requests. Use it to review payout requests, filter the queue, open provider request or response details, and act on postponed withdrawals when your permissions allow it.
This page is action-heavy. It is not only a history table: some rows can be moved back to Pending, approved, or rejected from this queue.
How To Read It
The grid combines player identity, provider, transaction id, amount, status, payout method, wallet balances, update time, review timing, PSP processing timing, and user tags.
The most important workflow columns are:
Statusshows the current withdrawal request status.Actioncan showTo Pendingfor rows currently inAPPROVE_REQUESTED.ApproveandRejecticons appear only for postponed rows and only when the operator has the matching permission.Provider Reqopens stored postponed provider/request payload data when it exists.Provider Respopens available provider response, status message, rejection reason, and provider context.
User tags appear twice in the wide grid. Both tag blocks behave the same way: clicking a tag copies it into Search by tag and reloads the queue.
Filters That Change The Queue
The filter form affects the table and CSV export:
Search playersearches by player identity text through the backend email/name search helper.Search provideris a case-insensitive contains match against payment provider.Statusnarrows by withdrawal status;Allis sent as no status filter.Search by tagis a case-insensitive contains match over user tags.Date startandDate endbound the withdrawal request creation-time window.
Actions
To Pending
To Pending appears only for rows whose status is APPROVE_REQUESTED. After confirmation, CRM asks the backend to change that withdrawal request to PENDING.
The backend only accepts the APPROVE_REQUESTED -> PENDING transition for this action. On success it sets the request as postponed and writes the submitted reason, or the default reason, into the status message.
Current backend behavior does not clear postponedResumeParams during this transition. If older notes say the stored postponed request payload is cleared, treat those notes as stale.
Approve Postponed Withdrawal
The approve icon appears only on postponed rows when the operator has Withdrawals / Approve.
The page first checks the current merchant balance by dividing the row amount by the current exchange rate for the row currency. That rate comes from the currencies list loaded for the page; it is not the rate stored when the withdrawal was created. A missing or zero current rate, a non-positive amount, or an unavailable merchant balance leaves the row on the warning icon and does not fire the approval call.
The server performs the final merchant-balance check again, forwards an allowed approval to the configured payout endpoint, and records the admin actor and action time on success. It also converts the stored withdrawal amount, but selects the current exchange rate by the player's current account currency rather than by the withdrawal row currency used on the page. If those currencies differ, a rate changes between the separate reads, or merchant balance changes before the server check, the preview and final result can disagree; the server result is final. If provider approval fails, the server stores the provider failure reason in the withdrawal status message when available.
The current server flow starts a best-effort Withdrawal Approved activity write before it tests the final balance and does not wait for that write to finish. An approval attempt rejected by the server balance gate can therefore still leave an approval activity even though no provider approval was sent. Use the withdrawal status and provider outcome, not that activity alone, to decide whether the payout was approved.
Reject Postponed Withdrawal
The reject icon appears only on postponed rows when the operator has Withdrawals / Reject.
The rejection dialog starts with Withdrawal verification failed and provides these fixed choices:
Withdrawal verification failedPayment details are invalidKYC verification requiredWagering requirements not metAdd Custom Reason
Add Custom Reason reveals a required multiline field. Leading and trailing spaces are removed, and Reject Withdrawal stays disabled while the trimmed custom reason is empty. The dialog tells the operator that the player will see the submitted reason in withdrawal history.
Canceling or closing the dialog does not reset its local reason fields. If the same row component remains mounted, reopening it can show the previously selected option and custom text. On success, the rejection is forwarded to the configured payout endpoint and the admin actor, action time, and exact submitted reason are recorded.
Timing Columns
Risk Review Time (Created -> Decision) is the duration from withdrawal request creation to the latest approval or rejection decision activity when that evidence exists.
PSP Processing Time (Sent -> Completed) is the duration from payout-send evidence to a successful terminal withdrawal update when the required evidence exists.
Blank timing cells mean the backend did not find enough evidence for that duration. They do not by themselves mean the withdrawal was never reviewed or processed.
Export Behavior
Download CSV exports the current withdrawal query when the visible list has at least one row. It uses the active filters and removes normal visible-page pagination for the export request.
The CSV can include source response fields that are not rendered as visible table columns.
Common Questions
Why do some rows have action icons and others do not?
The row must be in the required state and the operator must have the required permission. Postponed approval and rejection controls are intentionally not shown for normal non-postponed rows.
Does opening Provider Req or Provider Resp change anything?
No. Both are read-only inspection actions. They open payload details that already exist on the row.
Why does clicking a tag immediately change the queue?
Tags are treated as an investigation shortcut. Clicking a tag writes that value into Search by tag and submits the filter form.
Known Caveats
To Pendingsets the request as postponed but does not currently clear stored postponed request payload data.- The frontend merchant-balance check for approval is only a usability gate; the backend check is authoritative.
- The rejection dialog initially selects
Withdrawal verification failed; use the more specific fixed option or a clear custom reason when that default is not accurate. - Closing the rejection dialog does not clear the selected option or custom text while the row remains mounted.
- Timing columns depend on backend evidence from activities/history. Missing evidence renders a blank duration.
- The CSV export scope follows the query filters but can include fields that the visible table does not show.