After pressing Cancel, check the original order’s final state and cumulative execution before deciding on another order. Cancellation concerns the unfilled instruction. It does not undo trades that already happened, and clicking a button, processing a request and refreshing a screen need not occur at the same instant.
The additional half unit in a cancellation interval
Imagine an original target of four units. You see one executed when you request cancellation. Before the request is processed, another half unit executes. The remaining 2.5 units are then cancelled. Your final execution is 1.5, not the one unit remembered from the earlier screen.
| Point | Event | Cumulative execution |
|---|---|---|
| A | You inspect the order and request cancellation | 1 |
| B | An additional match occurs | 1.5 |
| C | The remaining instruction is cancelled | 1.5 |
This is an invented timeline, not a measurement of exchange or network speed. Its purpose is to show which quantity belongs in the next calculation. If the original order is confirmed finished and your target remains four, the difference is 2.5. A new order for four could take the total to 5.5.
Which status confirms the cancellation result?
Locate the same order ID in official records. Read its current or final status and its cumulative executed quantity, then inspect associated trades if necessary. A notification that a request was sent is not necessarily the result of processing it. A disabled button may simply stop another click in the interface.
The Binance status definitions distinguish user cancellation from full execution and other terminal outcomes. If the order had already completed when cancellation was handled, a filled result alone does not demonstrate duplicated execution. Reconcile the original and executed quantities.
A missing response is not a known failure
A connection problem establishes that you lack a clear response. It does not establish whether the exchange processed the request. Recheck the original order through an official interface and save its ID, pair, request time and any message you received.
Use the status returned by the query:
CANCELED: cancelled; keep any execution already recorded.FILLED: fully executed, with no remainder to cancel.NEWorPARTIALLY_FILLED: cancellation is not confirmed by this result.- No clear result: mark it pending and note the query time.
For another status, keep its exact wording and check its definition instead of recording a successful cancellation.
If phone and browser views differ, record when each was refreshed. One may still be showing an earlier state. Do not use two interfaces to place replacement orders at the same time as a way to resolve that disagreement.
Selling is not cancelling a buy
Suppose a buy is partially filled and your intention is to stop further buying. A new sell order is another transaction, not a cancellation of the original buy. The old buy can remain active and execute again later, even if the sale has already changed the wallet balance.
An opposite trade also uses a new price and quantity and can create additional price differences and fees. Decide whether you want to stop a future instruction or dispose of an existing holding. Those are separate decisions with different objects in the interface.
Define the new target instead of copying the old quantity
After the original order is resolved, you do not have to complete its original target. Your plan may have changed. Write the target you currently intend to keep, then compare it with confirmed execution that still belongs to that target.
Four minus 1.5 gives a difference of 2.5 only under that stated assumption. It does not choose a new limit, type or time-in-force, and it does not prove that the new order meets current input rules. Review those conditions before another submission.
The partial-fill reconciliation explains why an active remainder must stay in the calculation. A difference in quantities is not permission to ignore a still-open instruction that might satisfy the same target later.
A shared price does not identify a shared order
Several orders can have the same pair, side and limit. Match the order ID before acting. If you cancel several instructions, keep a separate result for each instead of treating one successful result as confirmation for all of them.
A control described as cancelling all orders also has a scope. That scope may depend on the current market, account or interface. Read what the current control actually covers rather than assuming it applies to every product in the account. This guide does not prescribe the position or scope of a button across all client versions.
Balance changes are supporting evidence
Funds associated with an unfilled instruction may become available after it ends, but balance displays and order lists can refresh separately. Other trades or instructions can also affect the same available balance. A balance increase should not replace a check of this particular order’s final state.
For a sell, stopping an unfilled instruction does not buy back the asset. It ends the planned sale of the remaining quantity. Keeping those descriptions precise helps prevent an availability change from being mistaken for a new trade.
Keep a concise record for an unresolved case
Save the complete pair, order ID, time zone, request time, latest status, cumulative execution and error text. Include repeated clicks if they occurred. The useful question is which instruction and request produced which result, not merely whether a button appeared to work.
Never provide a password, verification code or API secret to someone offering to look up an order. This site has no access to your account. Once official records resolve the result, replace uncertainty with a clear statement such as “1.5 executed; the remaining 2.5 cancelled,” then consider whether any new trade is still wanted.
If the returned state is EXPIRED, preserve that actual label. Do not rewrite the reason merely because you remember pressing Cancel. The recorded event sequence, rather than the action you intended, is what needs reconciliation.