Most fixed-rate swap problems come down to three things: the timer, the amount, or the network. They have different endings, and only some return your money without a support request. Below: ten problems mapped to cause and fix, the real timer rules, and what support needs from you.
Fixed-rate deposits are time-boxed. The Fswap terms of use require the exact amount to be sent "within the specified time up to 15 minutes", and state that Fswap provides no custodial services and does not store users' assets on the platform.
There is a stated market-movement threshold. The same terms allow order terms to be recalculated at the current market rate after significant market fluctuations of 1% or more — and also if an incorrect amount is sent or a time limit is missed.
Expired and failed orders do not refund themselves. Fswap's status documentation states that funds from EXPIRE and FAIL orders are not returned automatically; you contact support with the order ID and the deposit transaction hash.
"Refunded" is not yet "received". For some liquidity providers the refund status is set the moment a refund is initiated, before the transaction is broadcast, and the refund hash can still be empty.
TON has a specific trap. Under the terms, TON tokens sent without a Jetton Notification carry a refund fee equivalent to $100, deducted from the transferred amount — and a deposit smaller than that fee cannot be returned at all.
Refreshing faster changes nothing. There are no webhooks, and statuses refresh from the liquidity provider no more often than every 20 seconds, so checking more often than every 20–30 seconds shows you the same answer.
The timings, statuses and refund rules below are Fswap's documented behaviour, read from its terms of use and public API documentation as at October 12, 2026. Other services use different windows, status names and refund policies — check the one you actually used. This is general information, not financial advice.
Find your symptom in the left column. The third column is the only one that changes what you do next, and three of these ten you can still fix yourself if you act before the timer runs out.
Problem | Why it happens | What to do |
|---|---|---|
"Deposit below minimum" and the order is still waiting | You sent less than the pair minimum, or your wallet deducted its network fee from the amount you typed | Send the remainder before the deadline — the order waits while it is still in the waiting state. Check the expected amount on the order, not your own arithmetic |
Timer is counting down and you have not sent yet | A fixed quote holds the rate only for a short window | Send the exact expected amount in one transaction now, or let it lapse and request a fresh quote. Do not start the transfer with two minutes left on a slow network |
You sent slightly more than expected | Rounding up, or a second transfer "to be safe" | Nothing, while the order is still waiting. Once it has moved to the exchange stage, anything further you send is not credited |
Status has been "confirming" for a while | The deposit is waiting for the number of network confirmations the chosen provider requires | Wait. Nothing you do speeds up confirmations — see why a swap sits pending |
Order has been on hold for a long time | The liquidity provider's AML or verification check is running; the hold state is not final | Keep checking at normal intervals. Contact support with the order ID only if the status stops moving |
You received less than the quote showed | The payout figure is already net of the service commission and the provider's network fees | Compare what arrived against the payout figure you confirmed, not against the raw rate multiplied by your amount |
The rate is different from what you saw | A floating quote recalculates at execution. The terms also allow recalculation at the current market rate after fluctuations of 1% or more, or if the amount or timing was wrong | Use a fixed rate when the figure has to hold, and send the exact amount inside the window. Nothing can be re-fixed after the fact |
Deposit arrived after the timer expired | The window closed while the order was still waiting; expiry is a final status | Do not send anything more to that address — a late deposit is not reflected in the order. Contact support with the order ID and deposit hash |
Deposit was too small to cover the payout network fee | The amount sent leaves nothing payable on the receiving side | The order fails. Recovery is a support matter; send the order ID and the deposit hash |
TON sent without a Jetton Notification, or any asset sent without a required memo or tag | The transfer does not register against the order; extra IDs are passed through without validation | Contact support immediately. For TON the terms deduct a refund fee equivalent to $100, and a deposit smaller than that fee cannot be returned |
Ordered by whether you can still change the outcome yourself: the first three rows are fixable while the order is waiting, the middle four need patience rather than action, and the last three are support matters. Rules and figures are Fswap's own, from its terms of use and status documentation as at October 12, 2026.
The timer is not a convenience setting. It is the price of the guarantee: someone has to carry the risk that the market moves between your quote and your deposit, and on a fixed rate that someone is the liquidity provider rather than you. The shorter the window, the less risk they are underwriting — which is why the fixed window is a fraction of the floating one.
Rate type | How long the quote stays valid | Deposit window after the order is created | What happens if the market moves |
|---|---|---|---|
Fixed | 5 minutes | Up to 15 minutes (shorter with some providers) | Nothing, inside the window — the amount you receive is locked |
Floating | 2 hours | 120 minutes | The payout is recalculated at execution, so you may receive more or less than the estimate |
Fixed-rate first, because that is the type where the quote is binding and the window is tightest. Values are Fswap's documented ones as at October 12, 2026; the exact deadline is returned per order and can be shorter depending on which liquidity provider handles it.
Three consequences are worth internalising before your next swap:
Start the transfer at the beginning of the window, not the end. A congested network can take longer to broadcast and confirm than the window has left, and the deadline is measured by when funds arrive, not when you pressed send.
The exact amount is part of the agreement. The terms treat an incorrect amount the same way as a missed deadline: both allow recalculation at the current market rate.
Expiry closes the door, it does not park the money. An expired order is final. The address stays visible, but transfers to it are no longer matched to anything.
Fswap's own how-it-works page puts a typical swap at 5 to 15 minutes end to end, with network congestion as the usual reason it runs longer. That is the completion time, not the deposit deadline — the two get confused constantly, and only the second one can expire on you.
A refund happens when the deposit arrived but the exchange could not be completed, so the funds are sent back to the refund address. Understanding three mechanics saves most of the panic.
A refund needs somewhere to go. The refund address is captured when the order is created, and it is the only destination the money can return to. Some providers reject a fixed-rate order that has no refund address at all, which is why a service will ask for one even though most swaps never need it. If you created an order without one, that is the first thing support will ask about.
The refund status can appear before the money moves. With some liquidity providers it is set the moment a refund is initiated — before the transaction is broadcast — and the refund hash can still be empty at that point. So an order showing "refunded" with nothing in your wallet is usually a timing gap rather than a lost transfer. Give it time to appear on-chain before escalating.
Expiry and failure are not refunds. This is the distinction that costs people the most. A refund is an action the system takes; expiry and failure are states it stops in. The documentation is explicit that funds from expired and failed orders are not returned automatically — those need a support request. And a refund is not free in every case: under the terms, a TON deposit sent without a Jetton Notification has a refund fee equivalent to $100 deducted from it, and if the deposit was smaller than that fee it cannot be returned at all.
Worth knowing for context: because Fswap states in its terms that it provides no custodial services and does not store users' assets, a "refund" is not a balance being released from an account — it is a transfer back out of the exchange route. That is also why there is no account to log into and chase it from, and why the order ID matters so much.
Three of the ten problems above need a human, and the rest do not. Knowing which party actually controls the thing that went wrong saves a day of writing to the wrong one.
Who | What they control | Problems they can resolve | What they cannot do |
|---|---|---|---|
You | The amount, the network, the timing, the memo, the refund address | Below-minimum top-ups, sending inside the window, the exact amount, required extra IDs | Nothing, once the order reaches a final status |
The swap service — Fswap | The order record, the routing, and contact with the liquidity provider | Tracing an expired or failed order, chasing a refund that has not arrived, explaining a recalculated rate | Reverse a confirmed on-chain transfer, or re-fix a rate after the fact |
The liquidity provider | The deposit address, the compliance check, the payout | Releasing an order held for review, processing the actual refund | Be contacted by you directly — requests go through the service |
The network | Confirmation speed and fees | Nothing on request | Be hurried, and it cannot undo a transfer to a wrong address |
Ordered by how much of the outcome each party controls, starting with the one who can still change it before the timer runs out. The last column is the useful one: it marks where a request will not help no matter how it is worded.
When the problem is genuinely in the support column, one well-formed message resolves it faster than five follow-ups. Include all of this:
Order ID — the 12-character code from the order page. This is the primary key; without it nothing else is actionable.
Deposit transaction hash — from your wallet or a block explorer.
The exact network you sent on — "USDT on TRC20", not "USDT".
Amount and time sent — the amount that actually left your wallet, with the timestamp and time zone.
Status now, and when you noticed — both, because the order may have moved since.
The refund address on the order — if you are asking for a return.
What you want — one sentence: a refund, a payout, or an explanation.
And two things not to do while you wait. Do not open a second order to retry, because you then have two deposits to reconcile instead of one. And do not send a follow-up transfer to the same deposit address hoping to nudge the order along — on a final status it will not be credited.
The deposit arrived but the exchange could not be completed, so the funds were sent back to the refund address. The usual causes are a compliance check that did not clear, the liquidity provider withdrawing the pair or quote, or a deposit that could not be processed as sent — wrong amount, late arrival, or a missing memo.
One of three things. Below the pair minimum, the order keeps waiting and you can still send the remainder before the deadline; if it does not arrive in time, the order expires with your funds already received. Above the pair minimum but below the expected amount, some providers continue and pay out on what arrived. Too small to cover the payout network fee, and the order fails.
Fswap's terms of use state that the exact amount must be sent within the specified time, up to 15 minutes. The deadline is shown on the order and can be shorter depending on the liquidity provider. A floating-rate order allows 120 minutes.
Either the quote was floating, which recalculates at execution, or the order was re-priced. Fswap's terms allow recalculation at the current market rate if an incorrect amount is sent, if a time limit is missed, or after significant market fluctuations of 1% or more.
No. The documentation states that funds from expired and failed orders are not returned automatically. You contact support with the order ID and the deposit transaction hash. Do not send anything further to that deposit address — a late deposit is not reflected in the order.
With some liquidity providers the refund status is set when the refund is initiated, before the transaction is broadcast, and the refund hash can still be empty. Allow time for it to appear on-chain, then contact support with the order ID if it does not.
The transfer does not register against the order, and the terms of use deduct a refund fee equivalent to $100 from the transferred amount. If the deposit was smaller than that fee, the funds cannot be returned. Contact support with the order ID and the transaction hash as soon as you notice.
Every 20 to 30 seconds at most. There are no webhooks, and statuses refresh from the liquidity provider no more often than every 20 seconds, so faster checking returns the same answer.
Three of these problems you can still fix while the order is waiting, four only need patience, and three need a support request with two identifiers in it. The pattern underneath all ten is the same: a fixed rate is a short-dated promise, and it holds only if the exact amount arrives on the right network inside the window. Get those three right and the rest of this article stops being relevant.
Starting a swap and want the amount fixed before you send? Fswap shows the final amount before you confirm, at a fixed or floating rate, with the deposit deadline on the order itself — the how-it-works page walks through the four steps.
Elena leads marketing at Fswap and writes about cryptocurrency exchange: how swaps work, how to compare rates and fees, and how to keep funds safe without unnecessary KYC.
