The spot desk — orders, withdrawals and customer tickets

A customer says their order is stuck, or their payout has not arrived. This page is the map of the screens that answer that, in the order you would actually open them — and, just as usefully, the list of things those screens will not do for you.

Where the screens are

Five of these have a menu entry. The other four — Markets, Charts, Balances and Fees — are reached from the exchange hub's Quick Actions grid or by typing the URL.

The permission keys for each are in Permissions, background jobs and Redis keys.

Spot orders

/admin/finance/order/exchange — one row per exchangeOrder, joined to the customer.

On the row: the trader (avatar, name, email), symbol, type (MARKET / LIMIT), side (BUY / SELL), price, amount and status.

Behind the expander and in the view dialog: id, referenceId, timeInForce, filled, remaining, cost, average, fee, feeCurrency, trades, metadata, createdAt, updatedAt, deletedAt. The view dialog adds a Fills table built from trades and an Order reference section pairing your id with Binance's referenceId — the id you would quote to Binance support.

status is one of OPEN, CLOSED, CANCELED, EXPIRED, REJECTED. Note the single L in CANCELED; that is the column's enum.

This screen is read-only

canCreate, canEdit and canDelete are all false on the table. There is no form, no per-row edit and no per-row delete. What remains:

• View — the detail dialog.
• Delete Selected — selecting rows and using the Actions menu still offers the built-in bulk delete, gated on delete.exchange.order. The table is paranoid, so this is a soft delete; the Show deleted toggle exposes Restore and Permanent delete.

Deleting an order row deletes a record. It does not cancel anything at Binance and it does not release the customer's hold.

The API does carry write routes that the screen does not expose. If you reach for them directly, know that their accepted status values do not match the column:

The two status routes advertise CANCELLED (two Ls) and PARTIALLY_FILLED. Neither is a member of the exchangeOrder.status enum, and the request body is validated against the advertised list before it reaches the database — so the one spelling the column accepts, CANCELED, is rejected by the route, and the spellings the route accepts are rejected by the column. Treat both routes as unusable for anything other than OPEN and CLOSED.

The analytics tab is the useful part

Four figures on the Analytics tab answer the questions a ticket usually raises:

Notional traded and Settled notional deliberately carry no currency symbol: cost is priced in the quote half of a free-text symbol, so a book that settled 50,000 USDT and 2 BTC cannot honestly be added up.

The withdrawal desk

/admin/finance/withdraw/log opens filtered to status = PENDING, sorted oldest first — the row that has waited longest is the one to decide next.

Columns: the customer, Age (from createdAt), status, amount, Wallet — rendered as BTC (SPOT), which is how you tell a spot payout from an Ecosystem or fiat one, because there is no wallet-type filter — Destination (the address and chain pulled out of metadata, or a masked bank account for fiat), fee, referenceId, trxId, description and metadata.

Decisions are available from two surfaces, and they take different permission keys:

• From the list — the Approve and Reject entries on a PENDING or PROCESSING row, and the same pair in the bulk menu for a selection. Both raise the same confirmation dialog and both send PUT /api/admin/finance/withdraw/log/status, so both need edit.withdraw. Rejecting always demands a reason; approving does not.
• From the detail page /admin/finance/withdraw/log/{id} — the buttons there call the wallet routes directly and need edit.wallet.

The list route does not reimplement anything: it hands each id to the very same approve and reject handlers, so the wallet-type routing, the fee accounting, the idempotency key and the customer email cannot drift between the two surfaces. Partial success is reported, not rolled back — the response names which ids failed and why, because forty approvals are forty independent money movements.

{id} is a transaction id, not a wallet id, despite the path.

What Approve does, in order

Status codes are preserved rather than flattened to 500 — a 400 or 409 means "refused for a permanent reason, do not retry".

The fee added at approval

The handler looks for the withdraw fee of the chain named in the transaction's metadata — currency.chains[].withdrawFee on the exchangeCurrency row — and adds it to the amount before the balance check.

There is nothing there to find. exchangeCurrency has exactly seven columns — id, currency, name, precision, price, fee, status — and no chains. The spot currency import computes a standardised per-network table and then writes only currency, name, precision, fee and (on creation) status. So the network fee resolved at approval is always 0, and the guard reduces to "amount must not exceed wallet.balance".

What Reject does

Reject accepts PENDING, PROCESSING and TIMEOUT, which is what un-freezes a payout stranded mid-flight. It requires a reason, stores it on the transaction as metadata.note, credits the amount plus the fee back to the wallet, and emails the customer with the reason. ECO rows refund through ecoRefund so the chain balance is corrected too; everything else uses a plain credit.

The exchange hub

/admin/finance/exchange is the provider's own screen. It has three tabs:

Verify Credentials sits in the header and is available on every tab.

The result renders as a banner under the tabs. On failure it prints the literal APP_BINANCE_API_* variable names it expected and reminds you that .env changes need a restart. A green result proves your .env is correct; it does not prove the running processes are using it — see Switching the active exchange provider.

The proxy field accepts http://, https://, socks4:// and socks5://. Credentials embedded in the URL are masked on read as //***:***@, so the value you see after saving is not the value you typed. Test Proxy opens a separate connection and does not disturb the running one; save only after a successful test. Saving also evicts the cached connection in that process, so the next request rebuilds through the proxy.

The Quick Actions grid links to Markets, Charts, Currencies, Balances and Fees. Balances and Fees are disabled until credential verification passes, because both fail with an authentication error otherwise.

If no provider is enabled at all, the page replaces itself with "No active exchange provider" and a link to Admin → System → Extensions, filtered to exchanges — which is where the on/off toggle actually lives.

Exchange balances

/admin/finance/exchange/balance — asset, available, inOrder, total, read live from fetchBalance on every load. Searchable, sortable and paginated client-side.

Three failures have distinct codes, and they mean different things:

That last one is the important one, and it is also the least informative. The route does raise its own Exchange or provider not available when startExchange() returns nothing, but it raises it inside its own try, and the catch only recognises ccxt's authentication and network errors — everything else is re-wrapped as 500 Failed to retrieve exchange balance. So that message never reaches the browser, and a 500 here tells you only that it was not a credential or a connectivity problem. With everything else looking healthy it is usually the rate-limit ban rather than a broken screen; check the ban key, not the message.

Charts

/admin/finance/exchange/chart lists every market with its interval count, candle count, gap count, cache size and date range, and carries four actions.

A build streams its progress to the page over a WebSocket at /api/admin/finance/exchange/chart/build (manage.exchange.chart). Closing the page stops the monitoring, not the job.

The stat tiles read Total markets, Cache size, Intervals and Cache days. The banner above them is where a rate-limit ban becomes visible in the panel at all. For the cost of a large build, see Currencies, markets and charts.

Fees

/admin/finance/exchange/fee groups by feeCurrency and gives you, per currency, the total amount traded, the fee your platform calculated, the fee Binance's own maker/taker rate implies, and the difference.

The paper trail

When a ticket needs evidence rather than an action:

• /admin/finance/transaction — every money movement, filterable by type (DEPOSIT, WITHDRAW, EXCHANGE_ORDER, REFUND, PAYMENT, and the rest) and status (PENDING, COMPLETED, FAILED, CANCELLED, EXPIRED, REJECTED, REFUNDED, FROZEN, PROCESSING, TIMEOUT). referenceId is the exchange's id; trxId is the chain hash; metadata holds the rest. Rows can be deleted, not edited.
• /admin/finance/wallet — one row per customer per currency per wallet type. balance is spendable, inOrder is held. The Adjust Balance row action adds or subtracts from balance with a description, an optional customer notification and a per-dialog nonce so a network retry is de-duplicated while two deliberate adjustments are not.
• Admin → System → Cron — whether the reconcilers have actually been running.

A ticket, end to end

What we could not determine

• Nothing on any screen records which admin approved a given withdrawal in a place the withdrawal row itself exposes. The action is on the admin audit trail (logModule: ADMIN_FIN, logTitle: "Approve Withdrawal"), not on the transaction.
• The spot order table's metadata and trades columns are rendered raw in the view dialog. Their shape is written by the order settlement path and is not documented as a stable contract.

Related

• Float, treasury and reconciling the ledger
• Deposits and withdrawals — the customer-side mechanics behind these queues
• Permissions, background jobs and Redis keys
• Troubleshooting