Withdrawal Not Working: Stuck Payouts

Signs a payout is stuck

Three symptoms cover almost everything: a request sitting far beyond the published window, a rail-level failure message, or a form that will not submit at all.

Naming the symptom precisely is the whole of the diagnosis, because each one points at a different part of the chain. People who describe a payout as "not working" usually mean one of these three and have not yet separated them.

Long pending status

The request was accepted and has not moved. Measure the elapsed time in business days rather than calendar days, and compare it against the published figures: three business days for processing, extendable to fourteen, and within five business days for funds leaving the account. A request inside that range is not stuck; it is queued.

Failed-rail message

The request was released and the payment did not complete. This is a plainly different situation: the operator has done its part and something on the receiving side refused or could not accept the money. Card issuers, wallet providers and banks all produce this, and the message usually names the rail rather than the reason.

App or form errors

The request never existed. A cashier that will not load, a submit button that does nothing, a validation error on a field that looks correct — none of these are payout problems at all. They are client-side problems, and they are the easiest of the three to fix.

• Long pending: the operator has it.
• Failed rail: the receiving side rejected it.
• Form error: it was never submitted.
• Declined with a reason: a condition, not a fault.

Before doing anything else, open the transaction history in your account and read what state the request is actually in. A surprising share of stuck payouts turn out to be requests that were never successfully created, and no amount of waiting resolves those.

The rest of this page works through the three causes in the order they occur, with the fix for each. Following it in sequence is faster than guessing, because the checks are cheap and the wrong assumption is expensive.

It helps to know roughly how these divide up in practice. Requests waiting on documents and requests waiting out an ordinary review account for most of what gets described as stuck. Rail-level failures are the next largest group and are concentrated in card refunds and mistyped destinations. Client-side glitches are the smallest group and the quickest to clear. If you are about to skip a step because it seems unlikely, skip the last one rather than the first.

One thing worth ruling out early is the possibility that the request simply does not exist. A cashier that failed silently, a session that expired mid-submission, or a confirmation screen closed before it registered will all leave you waiting for something nobody received. That check takes ten seconds in the transaction history and it saves the most time of anything on this page.

Identify which of the three symptoms you actually have before trying to fix anything.

Verification-side blocks

The most common reason a payout does not move is that the account has not satisfied an identity check, and the request is waiting on paperwork rather than on processing.

The AML policy describes verification as carried out when the company requests it, and states that full verification of name and address is required for depositing or withdrawing by bank transfer. The public offer adds that the client is obliged to provide identification and address documents. A payout meeting one of these for the first time is being asked, not obstructed.

Incomplete KYC

Documents requested and not supplied, or supplied partially. The request will not move until the set is complete, and it will keep not moving indefinitely. This is the case where waiting is the worst possible response, because nothing is going to happen without action from you.

Flagged documents

Documents supplied and not accepted. Almost always a presentation problem rather than a substantive one: blur, glare, a cropped corner, an expired date, or a name spelled differently on the account than on the passport. The fix is a better copy or a corrected profile, not an explanation.

Manual review holds

Documents in review, with the payout queued behind them. This looks identical to a stuck payout and resolves on its own. The distinguishing question is whether the status is asking you for something or simply reporting a state.

• Check the verification section of the account, not just the withdrawal status.
• Send one complete, high-quality set rather than several partial ones.
• Correct account profile details before resubmitting documents.
• Do not submit further payout requests while documents are pending.
• Never pay anyone to accelerate verification — no legitimate fee exists.

Because verification is completed once and then serves every future withdrawal, this whole category is overwhelmingly a first-payout phenomenon. Traders who finish documents before their first deposit essentially never meet it.

There is a variant worth flagging because it surprises people who did verify. An account that was verified some time ago can be asked for a refreshed address document, or for evidence connecting a newly added payment instrument to you. Neither means the earlier verification was rejected; both are the sort of periodic check any payments business runs. Having a recent statement to hand turns a second round into a same-day exchange.

If documents have been rejected twice without a clear reason, that is the point to ask specifically what is wrong with the file rather than sending a third version and hoping the outcome differs.

Phrase that question narrowly. "Which document was rejected and what specifically was unacceptable about it" gets an actionable answer; "why is my verification failing" usually gets a restatement of the requirements you have already read. The reviewer knows exactly what stopped the file, and asking for that single detail is the fastest route to a submission that passes.

Check the verification section, not just the payout status, because a document task never resolves by waiting.

Payment-side failures

When the operator has released the payout and the money still has not arrived, the problem belongs to the destination — a card that cannot receive it, a wrong network, or a closed account.

These are the failures where contacting the platform first wastes time. The operator has done its part; something at the far end refused the money or could not accept it.

Rejected card refund

A card refund needs the card that made the original deposit. An expired card, a reissued card with a new number, or an issuer that declines refunds from this merchant category will each produce a failure. Some issuers forward refunds to a replacement card automatically and many do not, which is why a card approaching expiry is a reason to withdraw early rather than late.

Wrong crypto network

The most serious failure on this page, because it is the only one that is not recoverable. A token sent on a network the receiving wallet does not support is very likely lost, and neither support nor the operator can reverse a confirmed blockchain transaction. Where an exchange recovers funds sent this way, it is doing you a favour rather than meeting an obligation. Read the network label on both screens before confirming, every time, without exception.

Closed wallet account

A wallet that has been shut, suspended or restricted cannot receive a credit. Since the closed wallet was probably the deposit source, opening a new one does not automatically make it an acceptable destination — the payment policy ties payouts to the deposit account, so an alternative has to be approved.

• Check the destination account itself before opening a ticket with the platform.
• Confirm the card is still valid and the wallet still active.
• For crypto, verify the transaction hash on a public explorer.
• Ask the receiving institution whether they have held or refused an incoming credit.
• Keep the payout confirmation to show the source of funds if asked.

Banks and wallet providers do hold incoming credits pending a routine question, and they do not always send a prominent notification. A single message to them resolves more of these than any number of tickets to the platform, and it is usually answered the same day.

Where a rail has failed twice with no fault visible on your side, stop retrying it. The answer is a different approved route, established through support, rather than a third attempt at the same one.

Keep in view that a failed rail does not put the money at risk. A payout that could not complete returns to the balance rather than disappearing, though it can take a few days to reappear while the failed transfer unwinds. That is normal and it is worth waiting out before assuming the amount has been lost. What it does cost is time, and on a bank transfer the payment policy attaches a commission where the failure was caused by an error in the details you supplied.

Once the platform shows a payout as sent, the receiving institution is the party who can tell you where it is.

App and form glitches

A cashier that will not load or a form that will not submit is a client-side problem. Nothing is wrong with the account, the balance or the payout process.

This is the least serious category and the one people worry about most, because a broken form at the moment you want your money feels like the platform refusing you. It almost never is.

Outdated app version

Payment interfaces change more often than the rest of a trading app, and an old build can be pointing at an endpoint that has moved. Updating from the official store is the first thing to try and it resolves a meaningful share of these cases on its own.

Cache and login issues

A stale session, a cached script or a browser extension interfering with the page will all produce a form that silently fails. Logging out and back in, clearing the cache, or trying a different browser separates a client problem from a platform one in under a minute.

Retrying cleanly

1. Update the app from the official store, or reload the site with the cache cleared.
2. Log out fully and log back in on a stable connection.
3. Try the other client — the web cashier if the app is failing, or the reverse.
4. Disable browser extensions and try again in a private window.
5. If the request now submits, check the history to make sure only one exists.

That last step matters. Repeated attempts against a failing form sometimes create several requests once it starts working, and duplicate payout requests attract exactly the manual review you were trying to avoid. Check the transaction history before assuming nothing went through, and cancel any extras before they reach the review queue.

• A form error is not a refusal.
• Try the other client before opening a ticket.
• Never install a payment app from anywhere but an official source.
• Check the history for duplicates after a series of failed attempts.

One warning belongs here. Search results and messaging apps are full of cloned trading applications that exist to capture logins, and a trader whose real app is misbehaving is exactly the person most likely to install one. Only ever update from the official store or the operator official site.

The same caution applies to help offered in comment threads and direct messages. Somebody replying to a public complaint with an offer to fix your withdrawal is not a support agent, whatever their profile picture suggests, and no legitimate process asks for a payment to release a payout. Real support lives inside the account you logged into, and it never contacts you first.

Update, re-login and switch client before assuming a form failure is a payout problem — and check for duplicate requests afterwards.

Unblocking step by step

The whole diagnosis fits in one ordered pass. Work down it without skipping and the cause surfaces in the great majority of cases.

Each step is cheap, and doing them in this order avoids the two expensive mistakes: waiting on something that needs action, and escalating something that needed a browser refresh.

Isolating the cause

1. Open the transaction history and confirm the request actually exists.
2. Read the status and any message attached to it, literally.
3. Count the elapsed time in business days against the published windows.
4. Check the verification section for anything outstanding.
5. Check the free balance, open positions and any active bonus.
6. Confirm the destination is the deposit source and is still open and valid.
7. If the request never submitted, update the app and retry on a clean session.

Fixing and resubmitting

Address the single thing you found rather than changing several at once, and confirm the fix has registered before submitting again. If verification was the issue, wait for the documents to be accepted before requesting, since a payout submitted into a pending review simply queues behind it. Keep the new reference separate from the old.

Escalating with records

• Include the request reference, method, amount and submission date.
• State the elapsed time in business days.
• Quote any status or failure message exactly.
• Say what you have already checked and changed.
• Keep it to one thread rather than several parallel tickets.

Support cannot act on a report that does not identify the request, and a complete first message frequently resolves in one reply what an incomplete one takes four exchanges to resolve. Being specific is not politeness; it is the fastest available route.

Set a realistic expectation for the reply as well. A ticket about a request still inside the published window will be answered with the published window, which is frustrating but correct. A ticket sent after that window, with a reference and a clear account of what has already been checked, is the one that gets a substantive answer. Timing your escalation is as important as writing it well.

Most of this page never applies to an account that verified early, deposited on the method it wants to be paid on and ran one small test withdrawal while the amount did not matter. Registration is free and verification can be completed before any deposit, which is where the whole problem is best solved. A test payout run in the first week costs a few dollars in fees at most and surfaces every one of these failure modes at a moment when none of them matter.

Diagnose in order — status, documents, balance, destination, client — then fix one thing and resubmit once.