How long does a crypto withdrawal take?

A merchant asks how long a withdrawal takes and wants one number. There are two, and only the first one belongs to Paymos.

The first has no duration to quote. A payout is initiated the moment the request lands: no batch window, no payout schedule, no approval queue, nothing held back while somebody looks at it. That is not a speed record. It is the absence of a queue, which is a different kind of claim and a more durable one.

The second half is the chain doing what chains do. It moves with the network the merchant picked and with whatever traffic that network is carrying this afternoon, and it is not a Paymos timing. No page here quotes a settlement time for it, and the reason is the rest of this article.

What happens the moment a payout is requested?

Two figures leave the available balance, and a transaction goes out.

The amount and the network fee for the chosen route move into a hold together, which is why the Balance page carries available and on hold as separate lines and why only the available one funds the next payout.

Then it is sent. Nothing sits in the gap, because there is no cut-off to miss and nobody to approve it. The merchant chooses the destination network at the moment the payout is created, from the routes enabled for that asset, and an asset-and-network route that is temporarily unavailable is missing from the picker and refused at the door rather than accepted and parked. The balance is untouched while that is true.

Why is no settlement time published?

Because the clock that decides it is not ours to start or to stop.

After the broadcast, arrival is a property of the network: its block production, its finality rule, the load it happens to be under. Publishing a figure for that means quoting somebody else's infrastructure as a commitment of ours.

The conflation is easy to make, because a merchant lives through one wait where there are two. Money leaves the balance, time passes, money appears in the wallet. A processor advertising payouts in under a minute has taken the second half — the half it does not operate — and printed it as a promise. What it can honestly claim is the first half: that nothing on its own side is waiting for anything.

The difference only shows up on a busy day, which is exactly when a merchant goes looking for the page. A platform that promised the absence of a queue is still telling the truth that afternoon. A platform that promised a minute is explaining a chain to a customer who was given a number.

Why does "confirmed" mean something different on every chain?

Each protocol defines finality for itself, and the definitions are not close to one another.

On proof-of-stake Ethereum, time is cut into slots and epochs, and finality is currently settled across two epochs rather than inside a single slot.

Tron counts heads instead of watching a clock. A block is solidified once at least 19 distinct active super representatives out of 27 have each produced a block at that height or above, and a solidified block cannot be replaced by a fork.

TON settles the whole question in one block. A transaction reaches finality after a single masterchain block confirmation, and once a shardchain transaction appears in a masterchain block it is irreversible.

Three different objects are wearing one word there. Seen from the incoming side, Paymos already sorts its networks along that line: six of them — BSC, Polygon, Solana, TON, Avalanche and Plasma — settle a payment at network finality rather than at a block count, while on the rest the confirmation policy is set by network and by payment size. Multiplying any of that into minutes is arithmetic anyone can do. Standing behind the result is a different undertaking, and it is not one the chain has made either.

Where can a payout stop?

In one of seven states, three of which are the end of it. On the wire they are created, signed, completed, failed, cancelled, pending_review and cancelling. Every payload also carries is_final, true for exactly completed, failed and cancelled. Branch on the flag, not on a list of names you keep current by hand.

The states in the middle describe our side of the work, and none of them is a progress bar. One is worth recognising on sight: pending_review shows to the merchant as Unconfirmed, which means the network has not confirmed the payout yet and the amount is still sitting in its hold.

How long is the window to cancel?

Narrow, and it closes before the transaction does.

Cancelling works only while the payout is still created and has not started executing; after that the call is refused. A second cancel on one that is already cancelled comes back 200 with the same payout rather than an error, so a retrying client needs no special case for it. The endpoint behaves the same way.

What cancel is not is a recall. A transfer already on a chain is not unwound from this side at all; the money comes back only as a new transfer, sent by whoever received the first one.

What does a payout that never leaves cost?

Nothing at all.

A payout ending as failed or cancelled puts its whole hold back: principal and network fee both return to available, and nothing is netted out of either on the way. Nobody is charged for a transfer that did not go. The question does not arise in Sandbox, where no hold is posted in the first place.

Who finds out is the part that catches integrators. A failed payout fires its webhook (withdrawal.failed and withdrawal.cancelled are both in the event contract) and sends no email and no in-app notice at all. Software finds out. A human finds out by going and looking. The notice the merchant does see is short by design: the payout did not go out, the hold has been released, and no reason accompanies either sentence. Why the notice stops there rather than naming the reason is a hot wallet decision.

Is sending fifty payouts slower than sending one?

Fifty transactions go out, each on its own, and none of them is waiting on the other forty-nine.

The dashboard sends a payout run: at most 50 recipients in one dialog, one asset on one network, approved together against the whitelist. A run is a Production feature and cannot be rehearsed in Sandbox, and every Merchant API withdrawal route still takes exactly one recipient, so this shape lives in the dashboard and has no API equivalent.

Two account limits sit around it, and both are visible before anything is sent: a ceiling on the size of a single payout, and a cap on how many payouts may be in flight at once. The remaining in-flight slots come back to the payout form before the merchant has typed anything, which is the difference between a limit and a rejection. A run needing more slots than the account has free is refused whole, with the numbers in the message.

What none of that is, is a window. Nothing pools the fifty and waits for a clock.

Does the network you pick change the wait?

It is the one part of the wait a merchant chooses.

The route is fixed when the payout is created, and the choice is narrower than the list of networks Paymos accepts payments on. A payout needs a whitelisted destination, and only four address groups can be whitelisted: EVM, Tron, TON and Solana. That is why 11 of the 13 accepted networks can be paid out to, and why NEAR and Sui take payments without being able to receive one. One EVM entry covers every EVM payout network at once, because a whitelist row is keyed by address and group, and the group carries all the networks inside it.

Cost travels with that choice and is not the subject here. Paymos takes no processing commission on a withdrawal; the route's network fee is shown before the merchant confirms, and Paymos subsidises it, so the merchant pays under what the transfer costs on the network. The price list is where that number lives.

What should your own system do with the wait?

Follow state, and delete the timer.

• Branch on is_final. It rides on every payload, which spares you a list of state names to keep current by hand.
• Treat webhooks as the payout notification channel, not as a convenience. A failure arrives nowhere else on its own: no email, no in-app notice. Delivery retries on a ladder, so a receiver that was down comes back to the event.
• Show your own customer the state and the network, never a countdown. A countdown is a promise about somebody else's chain, and the person reading it will hold you to it.

The incoming side of this question has a different answer and a different shape. What a payer waits for is a confirmation policy that moves with the network and with the size of the payment, and why that wait varies is its own piece. Where the money sits between the two, and why a released hold shows up as two entries and not as a missing number, is the ledger's job.

So the honest version of the answer has a shape rather than a duration. The half a processor runs is over before there is anything to time, and the half that takes the time is a public chain settling at its own pace. A merchant who plans around that is never surprised. A merchant who was promised a number is surprised about as often as the network is busy.