An exchange order status tells you which part of the operation has been reached, but it does not always describe what is happening on the blockchain. “Waiting for deposit,” “confirming,” “processing,” and “completed” may refer to different layers: your wallet, the receiving network, the exchange service, or the outgoing transaction. Understanding those layers helps you decide whether to wait, verify a transaction, or contact support.
Main Takeaways
- An order being created does not mean that cryptocurrency has been sent.
- A wallet’s “sent” notification does not necessarily mean the exchange has received enough network confirmations.
- BTC, ETH, and USDT deposits can follow different confirmation paths. USDT also exists on multiple networks, so the selected network must match at both ends.
- “Processing” usually means the service is handling an already detected order, while “confirming” normally points to an incoming or outgoing blockchain transaction.
- “Completed” should be checked against the destination wallet and, when a transaction hash is available, a suitable blockchain explorer.
The Minimum Vocabulary You Need
Exchange order
An order is the service’s record of the requested exchange: the selected assets, addresses, network where applicable, and other conditions shown before confirmation. It allows the service to associate an incoming payment with an expected outgoing transfer. Creating this record does not broadcast a blockchain transaction.
Transaction hash
A transaction hash, often called a transaction ID or TXID, identifies a broadcast blockchain transaction. It can be entered into an explorer for the relevant network to check the sender, recipient, transferred asset, confirmation state, and execution result. A hash should be copied from the wallet or order page rather than from messages sent by an unknown third party.
Network confirmation
A transaction begins to gain confirmations after it is included in a block. In Bitcoin, each additional block increases its confirmation count; a broadcast but unconfirmed transaction has zero confirmations. [1] The exchange service decides how much confirmation evidence it requires for a particular operation, so an explorer may show a valid transaction before the order advances.
Network and token contract
BTC is transferred on the Bitcoin network, while ETH is the native asset of Ethereum. USDT is a token available on multiple blockchains rather than a transfer format with one universal address and network. [2] For a USDT deposit, the asset name alone is insufficient: the sending network must be supported for that order and must match the deposit instructions.
Service processing
Some stages happen outside the blockchain. The service may need to identify the deposit, verify the order conditions, perform compliance checks, prepare the payout, or review an exception. Requirements can vary by exchange direction and compliance results; the current conditions should be checked before creating an order.
Mechanism Map: From Order Creation to Payout
| User action | Service or application mechanism | Network mechanism | Observable result and check |
|---|---|---|---|
| Create the order and review its details. | The service generates an order record and displays deposit instructions. | No transaction exists yet unless the wallet has separately sent funds. | The page may show “created” or “waiting for deposit.” Check the asset, network, deposit address, destination address, and order validity conditions. |
| Send BTC, ETH, or USDT from a wallet. | The wallet signs the transfer and submits it to the selected network. | Network nodes receive and validate the transaction before possible inclusion in a block. | The wallet may show “sent” or “pending” and provide a transaction hash. Open that hash in the correct explorer and compare the destination with the order address. |
| Wait after broadcasting the payment. | The service monitors the specified deposit address and attempts to match the transfer to the order. | The transaction may remain pending or be included in a block and gain confirmations. | The order may change to “payment detected” or “confirming.” Check whether the explorer recognizes the hash and whether confirmations are increasing. |
| Allow the service to handle the detected deposit. | The service checks that the asset, network, received transfer, and order data correspond. Additional review may apply depending on the operation and compliance checks. | The incoming transaction is already recorded, but an outgoing transaction may not have been broadcast. | The order may show “processing,” “checking,” or “under review.” The incoming hash can be confirmed even when no payout hash is available yet. |
| Wait for the payout to be sent. | The service prepares and broadcasts the outgoing transfer to the destination address. | The new transaction enters the destination network and awaits inclusion or further confirmations. | The order may show “sending” or “payout sent.” A second transaction hash should identify the outgoing transfer. |
| Verify receipt. | The service marks the workflow as finished after its completion conditions are met. | The outgoing transaction remains independently visible on-chain. | The order shows “completed.” Check the payout hash, destination address, asset, network, and wallet balance rather than relying only on the status label. |
What the Most Common Statuses Mean
Created or waiting for payment
The order exists, but the service has not matched an incoming transfer to it. If you have not sent anything, follow the displayed instructions only after checking every detail. If you have already sent the deposit, find the transaction hash in your wallet.
If no hash exists, the wallet may not have broadcast the transaction. If the hash exists but an explorer cannot find it, confirm that you are using an explorer for the network actually selected in the wallet. A genuine transaction on one network will not appear in the explorer of another.
Payment detected or confirming
The service has likely identified the incoming transfer but is waiting for its acceptance conditions to be met. A Bitcoin transaction can be visible with zero confirmations before it is included in a block. [1] An Ethereum transaction may remain pending when its fee settings are insufficient for current network conditions. [3]
Do not send a second deposit merely because the first one is taking longer than expected. First compare the transaction hash, address, asset, network, and order details. Sending again creates a separate transfer and may complicate resolution.
Processing, checking, or under review
The blockchain deposit may already be confirmed while the service is still handling the order. This stage can cover payment matching, operational processing, or compliance review. The label alone does not reveal the exact reason or establish a fixed completion time.
Check whether the order page requests information or displays an error. If support is needed, provide the order identifier and transaction hash. Never provide a seed phrase, private key, wallet password, or remote access to your device.
Payout sent
The service reports that it has broadcast the outgoing transaction. There should normally be a payout hash once the transaction is available to track. Use the explorer for the payout network and verify the destination address. A pending outgoing transaction means the exchange workflow has advanced, but the receiving wallet may not yet display a confirmed balance.
Completed
The service considers the order finished. This does not replace independent verification. Confirm that the outgoing transaction exists, has the expected success state, and points to your destination address.
On Ethereum, a transaction receipt includes a status indicating whether execution succeeded or failed. A transaction can be included in a block yet have a failed execution status, which matters particularly for token transfers and smart-contract interactions. [4]
Expired or cancelled
The order was not completed under its displayed conditions. For example, the expected deposit may not have been detected before the order ceased to be active. “Expired” does not by itself prove that no payment was sent.
If you sent funds, preserve the order identifier and transaction hash and contact official support instead of creating assumptions from the label. Do not resend funds to an address from an unsolicited message claiming to “reactivate” the order.
Failed, rejected, or action required
The workflow encountered a condition that prevented normal completion or requires user input. The cause could be visible on the order page, in the blockchain record, or only through support. A failed on-chain transaction and a service-level rejection are different events: one is recorded by the network, while the other belongs to the service’s internal workflow.
A Realistic Order Scenario
Suppose a user creates an ETH-to-USDT order. Before sending ETH, the user checks that the deposit address belongs to the order and confirms which USDT network is specified for the payout. Availability of a particular exchange pair or network must be verified at the time of the operation.
- The order starts as “waiting for payment.” At this point, only the order record exists.
- The user sends ETH and receives a transaction hash from the wallet. The wallet’s “sent” label shows that it attempted to broadcast the transfer, not that the full exchange is complete.
- The Ethereum explorer shows the incoming transaction as pending and later included. The order changes to “confirming.”
- After the service accepts the deposit, the status becomes “processing.” The incoming ETH transaction is already verifiable, but there may be no outgoing USDT transaction yet.
- The service broadcasts the payout on the network specified in the order. A new hash appears, and the status changes to “payout sent.”
- The user checks that the USDT token transfer is successful and that the recipient address matches the intended wallet. The service then shows “completed.”
This scenario explains the sequence without implying that every order uses identical wording, confirmation requirements, checks, or processing conditions.
Where the Model Changes
The sequence works as a general mental model, but the exact result depends on the asset, selected network, wallet behavior, network conditions, exchange direction, and compliance outcome. Status names are interface labels rather than universal blockchain standards.
- USDT network choice: Different USDT implementations operate on different blockchains. A matching-looking address format is not proof that the network is correct.
- Confirmation requirements: A transaction can be valid and visible while the service still waits. The order page or support information, not a generic rule, determines what the service requires.
- Compliance checks: An on-chain confirmation does not guarantee immediate processing. Requirements depend on the operation and the results of applicable checks.
- Wallet display: A wallet may update later than an explorer, may hide a token until it is added to the interface, or may show a local status that differs from the service status.
- Availability: The service supports several assets, including BTC, ETH, and USDT, but this does not establish that every pair, direction, or network is currently available.
- Country-specific rules: Access, verification duties, reporting obligations, and restrictions can differ by jurisdiction. An order status cannot determine the user’s legal or tax position.
No status can prove the exchange rate was optimal, predict an asset’s price, or guarantee that funds sent to an incorrect address or network can be recovered. Blockchain transfers are generally designed to be irreversible once validly recorded, so prevention is more reliable than attempted recovery.
Failure Points and the Signs You Can Observe
No transaction hash after pressing Send
The wallet may not have broadcast the transaction, or the operation may still be awaiting approval inside the application. Check the wallet’s activity page and official documentation. Do not treat a screenshot or copied text as proof of an on-chain payment.
Hash exists, but the order still awaits payment
Check the explorer first. If the transaction is pending, the service may not yet accept it. If it is confirmed, compare the deposit address, asset, transferred amount shown in the order, and network. A mismatch can prevent automatic association with the order.
USDT was sent on the wrong network
The clearest sign is a mismatch between the network in the order instructions and the network shown by the sending wallet or transaction explorer. Do not attempt to “correct” the problem by sending more funds. Preserve all records and contact official support; recovery may be impossible and should never be assumed.
Ethereum transaction is included but unsuccessful
The explorer may display a failed or reverted execution status. In that case, inclusion in a block does not mean the intended token transfer occurred. The transaction receipt’s success or failure result is the relevant evidence. [4]
Processing does not produce a payout hash
The outgoing transfer may not have been broadcast yet. Review the order page for requests or notices, then contact support through the service’s official interface if clarification is necessary. Share only the order ID, public addresses, transaction hashes, and other information specifically required through the legitimate support channel.
A message asks for a seed phrase or private key
Treat it as a phishing or wallet-theft attempt. A seed phrase grants control over a self-custody wallet, and legitimate support should not need it to inspect a public transaction. Ethereum’s official guidance likewise warns never to share a seed phrase with anyone claiming to provide recovery assistance. [3]
Safe Next Step
After checking the intended asset, available direction, network, addresses, and current verification conditions, you can review the available exchange order options. Read the displayed instructions before transferring funds, because availability and requirements can change by operation.
What You Can Now Explain and Verify
- Explain why creating an order, broadcasting a deposit, confirming it, processing the exchange, and sending the payout are separate events.
- Identify whether a status belongs to the wallet, blockchain, or exchange workflow.
- Use the incoming transaction hash to check the deposit network, destination, confirmation state, and execution result.
- Use the outgoing transaction hash to verify that the payout was broadcast to the intended address.
- Recognize that USDT requires an explicit network check, not merely confirmation of the token name.
- Distinguish a pending transaction from a confirmed but unsuccessful Ethereum transaction.
- Know when waiting is reasonable and when an address, network, transaction, or compliance issue requires official support.
- Recognize phishing requests and keep seed phrases, private keys, passwords, and remote device access confidential.