Paying Straight From an Exchange: How Withdrawal-as-Payment Works (and Why Most Checkouts Can't Do It)
A huge share of crypto holders keep funds on Binance or Coinbase and have no browser wallet. Here's the design that lets a plain exchange withdrawal be a complete payment — and why wallet-connect-only checkouts silently turn these customers away.
The short answer: a large share of the people who hold crypto keep it on an exchange — Binance, Coinbase, OKX — and have never installed a wallet extension. They can still pay a merchant in one step: withdraw to the payment address. For that to work, the checkout must give every order a dedicated address and detect plain transfers; checkouts built around "Connect Wallet" structurally cannot accept these customers, and lose them at the exact moment they were trying to pay. This article explains the mechanics, the customer's exact steps, the edge cases a serious gateway must handle — and why this unglamorous feature quietly decides your conversion rate.
The customer everyone designs around, and the customer who actually exists
Crypto checkout UX is usually designed for the crypto-native: browser wallet installed, comfortable signing transactions, knows what a network switcher is. That person exists — and is outnumbered. The larger population bought crypto on an exchange, keeps it there, and interacts with it through the exchange's app. No extension, no seed phrase ritual, no signing experience.
Put a "Connect Wallet" button in front of the second group and the funnel ends right there. Not because they can't pay — they have the money and the intent — but because the checkout speaks a dialect they've never learned. The one crypto operation every exchange user already knows is withdrawal. They've done it, or they've at least seen the screen: paste address, pick network, confirm. A checkout that accepts a withdrawal accepts them.
Why most checkouts can't take a plain transfer
Accepting bare transfers sounds trivial and isn't. Wallet-connect checkouts lean on the connected wallet to identify the payer and often on a contract interaction to tag the payment. A plain withdrawal offers neither: it arrives from an address you've never seen (the exchange's hot wallet — not the customer's), with no signature, no message, no metadata. Just tokens landing somewhere.
To turn that into a payment, the gateway needs a different architecture:
- 1A dedicated address per order. If order #1042 has its own address, then whatever arrives there belongs to #1042 — identity comes from the destination, not the sender. This is the load-bearing trick, and it's why shared-address designs can't do this (why dedicated addresses matter everywhere).
- 2Detection by watching the chain, not by waiting for a wallet callback — the gateway's own nodes spot the deposit the moment it enters a block (the full payment flow).
- 3Amount matching with real edge-case handling — exchanges sometimes deduct a withdrawal fee from the sent amount, customers sometimes send in two goes, and quotes sometimes expire mid-withdrawal. Partial and late payments must be surfaced and recoverable, not lost.
This is exactly how Finality's checkout works, on all five chains: every payment gets a dedicated address with settlement rules welded in, plain transfers are first-class citizens, and the QR code carries the full payment for mobile wallets too (done right, with the decimal-vs-atomic pitfalls handled).
What the customer actually does (worth putting on your checkout page)
- 1Open your exchange app → Withdraw → pick the token (say, USDC)
- 2Paste the payment address shown at checkout
- 3Pick the network the checkout specifies (e.g., Solana) — this is the one step that deserves emphasis
- 4Enter the exact amount shown, confirm
- 5Done — the checkout page flips to "paid" on its own, usually while they're still looking at it
No wallet installation, no signatures, no gas management — the exchange handles the transfer mechanics the way it always does. From the customer's perspective they did a thing they've done before, and the order confirmed itself.
The edge cases a serious implementation must own
- The withdrawal-fee haircut. Some exchanges deduct their withdrawal fee from the amount sent, so $49.00 leaves as $48.90. A good checkout shows the shortfall and lets the customer top up the same address; the order completes when the total arrives.
- The wrong-network risk. USDC exists on many chains; the customer must withdraw on the chain the address expects. Clear labeling at checkout prevents most of it — and multi-chain support means you can simply offer the chains customers already use (choosing chains).
- Late arrivals. Exchange withdrawals occasionally queue behind manual review and land after the payment window. The funds sit safely at the dedicated address, flagged and recoverable — annoying, visible, not lost.
- Refunds must never go "back where it came from." The sending address is the exchange's hot wallet, not the customer. This deserves its own article and has one: how crypto refunds work.
What this is worth to a merchant
Run the thought experiment on your own checkout: of everyone who holds crypto and wants your product, how many have a configured browser wallet on this device, right now? Wallet-connect-only checkout serves that minority and silently discards the rest. Withdrawal-as-payment doesn't improve conversion at the margin — it changes who can pay you at all. It's the difference between "we accept crypto from crypto people" and "we accept crypto."
It compounds with everything else non-custodial: the same dedicated address that identifies the payment also settles it atomically into your own wallet — one design decision, paying twice.
FAQ
Does the customer need a memo or reference code?
No — the dedicated address is the reference. Whatever arrives at order #1042's address is order #1042's payment. Memos are for shared-address systems.
Which exchanges work?
Any exchange that can withdraw the token on the right network — Binance, Coinbase, OKX, Bybit, Kraken and the rest. From the exchange's side it's an ordinary withdrawal; nothing special is required of it.
What if the customer sends slightly less because of the exchange's fee?
The order stays open showing exactly what's missing; a small top-up to the same address completes it. Nobody's money is lost, and you never ship against a partial payment.
Is this less secure than wallet-connect?
The payment lands on the same chain with the same finality. What changes is who identifies the payer: the destination address does, instead of a wallet signature — which is exactly what makes it work for people without wallets.
Is it safe to withdraw from an exchange straight to a merchant's address?
Yes on dedicated-address checkouts — the address exists for your order, amount-matching does the reconciliation. The safety habit is the same as any transfer: match the named network.
Which exchanges can I pay from?
Any that withdraws the token on the checkout's chain — Binance, Coinbase, OKX, Bybit, Kraken and the rest. It's an ordinary withdrawal from their side.
How long does an exchange-withdrawal payment take?
Exchange processing (minutes; longer on first withdrawals) plus chain time — seconds on fast chains.
What are the fees when paying by withdrawal?
Your exchange's withdrawal fee — theirs, not the chain's — plus a network fee measured in cents or less. Good checkouts absorb any shortfall via top-up.
Is there a minimum withdrawal amount?
Exchanges set their own minimums per token and network — worth a glance before small payments; below the minimum, pay from a wallet instead.
Can a merchant tell I paid from an exchange?
They see the payment arrive at your order's address — which is all reconciliation needs. Refunds are the one place it matters: you'll provide a proper receiving address.
See it from the customer's side: create a sandbox payment, open the checkout it gives you, and note what's not there — no connect button ultimatum, just an address, a QR code, and every way of paying that actually exists.