The binary order desk

The table is configured canCreate: false, canEdit: false, canDelete: false, so no row carries an edit or delete action. The toolbar is a different code path: selecting rows reveals an Actions menu, and because this table declares no custom bulk actions it still offers the built-in Delete selected to anyone holding delete.binary.order.

binaryOrder is a paranoid model, so that is a soft delete — deletedAt is stamped and the rows disappear from every list. The table is configured isParanoid: false, so this screen has no deleted view and no restore button: from the admin panel the rows are simply gone.

They are recoverable through the API, which still honours the flags:

# see what was deleted
GET  /api/admin/finance/order/binary?showDeleted=true
# put them back
DELETE /api/admin/finance/order/binary?restore=true   {"ids": ["…"]}

Deleting binary orders is almost never the right move regardless. The rows are the evidence for every revenue figure and every dispute, and the wallet movements they caused are not deleted with them.

Both status routes declare an enum of PENDING, WIN, LOSS, DRAW, and the request body is validated against it, so a request carrying CANCELED or ERROR is refused with "Status must be one of the following: PENDING, WIN, LOSS, DRAW."

There is therefore no supported way to mark an order cancelled from the admin panel. Cancellation is a customer action with a refund attached — see Early cancellation and risk limits.

The side column on the model has ten values — RISE, FALL, HIGHER, LOWER, TOUCH, NO_TOUCH, CALL, PUT, UP, DOWN — but the desk's filter offers only RISE and FALL, and the view dialog's badge is a single test: it paints red Fall when side === "FALL" and green Rise for everything else.

So a LOWER, NO_TOUCH, PUT or DOWN contract — every downside barrier trade in the product — appears on this screen as an upward bet. Combined with type not being shown at all, a Touch contract and a Rise/Fall contract are indistinguishable on the desk.

If you are reconstructing anything other than a Rise/Fall trade, read the row, not the screen. Open GET /api/admin/finance/order/binary/{id} or query the binary_order table directly. This matters most in exactly the situation the desk exists for: a customer disputing a barrier settlement.

A binary contract is staked in the quote half of symbol — the wallet debited is the one whose currency is the pair — and binaryOrder has no column saying which asset that was. symbol is free text and the model's only association is to user.

So a book carrying 500 USDT of stakes and 0.01 BTC of stakes has no single sum, and the analytics deliberately render plain numbers rather than a dollar figure they have not earned. Do not read the KPI cards as dollars unless every one of your binary markets quotes the same asset.

A live binary contract is watched by two things at once:

• an in-process timer armed when the order was placed, which fires at expiry and settles it immediately; and
• processPendingOrders, a cron job that runs every 15 seconds and settles anything the timers missed, taking a Redis lock per order.

Settlement claims the row with SELECT … FOR UPDATE inside a transaction and a status = PENDING predicate, so it will not overwrite a terminal order. Your edit has no such protection. A row can move from PENDING to WIN between the moment the page loaded and the moment you press save, and the admin write lands on top of a settled contract whose wallet movements have already happened.

The safe move on a stuck contract is to fix the cause and let the engine settle it — 15 seconds is the worst case once the price feed answers. If a contract has genuinely settled wrongly, correct the customer's balance with a wallet adjustment, which is auditable and reversible, and leave the order row telling the truth about what the engine did. See Wallet administration.

1. Find the row. Search the desk by user email or symbol, or filter on status and createdAt. Open the row to get its id.

2. Read the full record, not the dialog: GET /api/admin/finance/order/binary/{id}. You need type, side, barrier or strikePrice, and profitPercentage — none of which the screen shows.

3. Confirm whether it was real money. isDemo: true ends the conversation: no wallet was touched, in either direction.

4. Check the contract's own arithmetic. price is the entry, closePrice is the settlement price, closedAt is the expiry instant. For a Rise/Fall contract that is the whole story; for a barrier type compare closePrice and barrier, remembering that Touch/No Touch is decided by whether the barrier was ever reached during the contract, not by where the price finished.

5. Check what they were sold. profitPercentage is the rate frozen at placement. If it disagrees with what the customer says the trading page offered, the payout configuration changed while their page was open — see Order types, durations and payouts.

6. Check the settlement timing. closedAt versus updatedAt is how late the settlement was. A large gap points at the backstop rather than the timer, which is a settlement problem, not a pricing one.

7. If the customer is owed money, adjust the wallet. Do not edit the order row: the row is your record of what happened, and rewriting it destroys the evidence while paying nobody.