Transaction types and statuses

Every money screen in the platform is a filtered view of one table. Deposits, withdrawals, internal transfers, binary orders, staking, NFT sales, marketplace purchases and your own platform fees are all rows in transaction, separated by one column: type.

That is why the vocabulary is large, and why it is worth learning. An operator reading PLATFORM_FEE and TRADING_FEE as the same thing double-counts their revenue. One reading ORDER_PASSTHROUGH as revenue reports money that belongs to a courier and a tax authority.

The screen

Finance → Transaction Management → Transaction Logs (/admin/finance/transaction) is the unfiltered view.

It is read and delete only. view.transaction loads it, delete.transaction removes rows, and there is no create path at all — no endpoint, no button. Money enters this table by being moved, never by being typed.

Eight types are hidden from the global list

The list deliberately excludes DEPOSIT, WITHDRAW, INCOMING_TRANSFER, BINARY_ORDER, EXCHANGE_ORDER, FOREX_DEPOSIT, FOREX_WITHDRAW and ICO_CONTRIBUTION, because each has a dedicated admin screen and leaving them in would make this page a duplicate of six others.

The exclusion is lifted when the list is scoped to one user. The customer profile at /admin/crm/user/<id> mounts the same endpoint with a userId filter and is headed "complete transaction history", so it shows everything — there is no per-user Deposits page for the hidden rows to live on instead.

INCOMING_TRANSFER is on that list, which is why an internal transfer appears once here (as its OUTGOING_TRANSFER row) rather than twice.

The type vocabulary

The column accepts 44 values. Grouped by what they mean rather than alphabetically.

Money in and out

Internal transfers

These always come as a pair. One transfer writes both. The outgoing row is written when the transfer is created; the incoming row is written when it settles, which is why a PENDING transfer has an outgoing row and no incoming one. Reports that count both legs double-count every completed transfer. See Internal transfers.

Trading and products

Marketplaces

The fee family, and the direction of each

This is the group operators misread. All five used to be written as PAYMENT, which is why SUM(amount) WHERE type = 'PAYMENT' on an older install is a number with no meaning: it mixed the payer's debit, the collector's credit, treasury payouts and shipping pass-throughs into one bucket.

ADJUSTMENT_ANCHOR is bookkeeping scaffolding, not a payment. When an admin balance adjustment arrives with no client-supplied idempotency token, the endpoint mints a short-lived PENDING row purely so its id can seed a stable key, then soft-deletes it once the real credit or debit lands. A PENDING ADJUSTMENT_ANCHOR you can still see is the fingerprint of a request that crashed between the two — check the wallet's balance ledger to find out whether the adjustment actually happened, then delete the orphan. It is typed distinctly so it can never be mistaken for a payment the customer never made.

The filter dropdown is not the full list

The Type filter on /admin/finance/transaction offers 24 options and stops at P2P_TRADE. The fee family, the eight NFT types, ECOMMERCE_PURCHASE, FUTURES_ORDER, FX_TRADING_DEPOSIT, FX_TRADING_WITHDRAW, the marketplace pair and ADJUSTMENT_ANCHOR are not in the dropdown even though rows carry them.

The column is searchable, so type the value into search to reach those rows, or call the API with an explicit filter. A type missing from the picker does not mean the platform never writes it.

The ten statuses

What a queue will still act on, precisely:

• Deposits (/admin/finance/deposit/log) — PENDING only.
• Transfers (/admin/finance/transfer) — PENDING only.
• Withdrawals (/admin/finance/withdraw/log) — PENDING and PROCESSING. PROCESSING is included on purpose: a payout stuck mid-flight is exactly the row an operator needs to resolve, and excluding it is what used to freeze those indefinitely.

Every settlement handler re-checks the status inside a row lock before it moves money, so two operators approving the same row concurrently cannot both settle it. The loser gets Only pending transactions can be updated.

Column behaviours worth knowing

amount and fee are strings

Both are DECIMAL(36,18). The MySQL driver returns every DECIMAL as a string to avoid floating-point loss, so they reach application code — and any API client you write — as "12.50", not 12.5.

Consequences you will actually meet:

• Adding two of them concatenates. "10" + "5" is "105".
• Sorting them without declaring them numeric is lexicographic: "9" sorts after "10".
• Comparing one against 0 is a string comparison.

The admin screens coerce before they format. If you export or script against this table, do the same.

referenceId is UNIQUE across the whole table

There is a unique index on referenceId, and it is not scoped to a type, a user or a wallet. idempotencyKey carries the same constraint.

metadata is TEXT holding JSON

The column is DataTypes.TEXT, not a JSON type, and the model defines no getter. It arrives as a raw string that every consumer parses by hand.

Two things follow:

1. Filters and queues cannot look inside it. Every list, count and SLA query in the admin panel matches on real columns — type, status, createdAt, walletId. A rule that depends on something living only in metadata cannot be expressed as a queue filter. If you need to select on a value, it has to be a column. (The one place the platform does reach in is a raw LIKE on the serialised text, hunting for an in-flight adjustment anchor. That is a substring match on a string, not a JSON query, and it does not generalise.)
2. Malformed JSON degrades to empty, not to an error. Parsers here return {} on anything unparseable, so a corrupted blob makes fields quietly disappear rather than throwing. The view dialog is the exception — it prints Invalid metadata in the destructive colour when it cannot parse.

What lives in there is genuinely load-bearing: a pending transfer's destination wallet and converted amount, the original debit a refund is capped against, and an operator's rejection reason at metadata.message — which is the field the customer's email is composed from.

Other columns

Where to go next

• Working the deposit queue and the withdrawal queue — the two settlement screens.
• Internal transfers — the paired-row queue.
• The wallet balance ledger — the append-only record of what each of these rows did to a balance.
• Reading the revenue screen — how PLATFORM_FEE rows become reported revenue.