Appearance
Payments (admin)
Back-office payment management covers the unified transaction list, cashier configuration, provider routing, and deposit presets. Withdrawal operations remain on the dedicated withdrawals queue below.
Payments hub (/billing)
The Payments page has six tabs:
| Tab | Purpose |
|---|---|
| Transactions | Unified deposit + withdrawal list with filters (date, type, status, method, email, user id, amount) |
| Cashier methods | Per-currency methods with segment targeting, min/max limits, active toggle |
| Sort methods | Drag-and-drop order of active cashier methods (scoped by direction and currency) |
| Provider methods | Integrated provider configuration (name, fields, icon, integration JSON) |
| Routing | Provider cascade per cashier method — up to 10 providers, traffic %, daily/monthly caps |
| Presets | Up to 8 deposit amount buttons per currency; one default auto-selected in the player cashier |
Configured deposit methods are consumed live by the player fiat deposit API (/payments/methods, /payments/create).
Provider routing
When a player creates a deposit, the API walks the configured provider chain on decline:
- Skip providers over daily/monthly volume caps
- Apply traffic share per provider
- Prefer the player's last successful provider in the chain
- Fall back to sort order
On success, the last successful provider is remembered for the next attempt.
Permissions
| Action | Permission |
|---|---|
| View transactions, cashier, presets, routing | players.payments.view |
| Mutate methods, presets, routing, approve/cancel withdrawals from billing | payments.manage |
Cancel and reject both refund the player's balance when a withdrawal deduction exists (idempotent).
Withdrawals
When a player requests a withdrawal, it lands in a queue for the operations team to review and process. This is the back-office side of the wallet flow described in Wallet & payments.
The queue
The withdrawals screen opens on the work that's waiting: a pending count broken down by currency, how many were processed today, and the total number of requests. A collapsible analytics panel adds a 30-day view — approval rate, average processing time, volume over time, and a breakdown by currency — for anyone with payments.report.view.
From there you filter by status (processing, confirmed, rejected, cancelled), search by user, address, or currency, and sort by amount or date. Approving or rejecting can be done inline from the list.
Billing's transaction list links withdrawal rows to the detail page for chat and full context.
A single request
Opening a request shows the full picture: amount, currency, the destination address, the transaction hash once it exists, any admin comment, and who processed it. It also carries a message thread, so an operator can ask the player for clarification before approving a payout — the player sees the same thread from their side.
Status flow
A request starts as processing. An operator either approves it, moving it to confirmed, or rejects it. Cancelled requests are tracked as well. The deduction from the player's balance already happened at request time, so approval is about releasing the funds, not moving the balance again.
Permissions
Viewing the queue needs players.payments.view, the analytics panel needs payments.report.view, and acting on a request — approving, rejecting, or posting in the thread — needs payments.manage.