Designing a deposit flow where mistakes can’t be undone

TokenWin was an early-stage crypto-first iGaming platform with casino and sportsbook, built from scratch. I spent eight months there as the product designer, working directly with the CPO and CTO.

The platform hadn’t launched by the time I left, so none of this was validated against real users. What follows is the reasoning behind the decisions, not a claim about their results.

I worked across the whole product: lobby, games, sportsbook, account. The part I owned end to end, and the part worth writing about, was deposit.

Everything else on a gambling platform is entertainment. Deposit is the moment it becomes money leaving someone’s account.

And in crypto, the mistakes are permanent. There’s no chargeback, no bank to call, no support ticket that recovers the funds. If a deposit goes wrong, it’s gone. That makes it the highest-stakes flow in the product and the one where interface decisions have the most direct consequences.

Four failures, all unrecoverable:

Four things weren’t mine to decide, and they shaped the whole flow.

The payment provider supported five currencies: BTC, ETH, USDT, BNB and TRX. That list was theirs.

Their API rejected any deposit without an explicit network, so network selection couldn’t be inferred or defaulted. It had to be a decision the user made.

The 0.00005 BTC minimum was their threshold, not ours.

And the deposit address is generated per transaction by their system, which means it doesn’t exist until both currency and network have been chosen. That’s why the address block sits below both fields rather than beside them. The field order isn’t a layout preference, it’s a consequence of how the system works.

Crypto deposit is a solved problem, and getting it wrong is expensive, so I started by checking how settled the pattern actually was. Stake, Betfury and BC.Game all handle it the same way: pick a currency, pick a network, get an address. Then I looked at Binance and Bybit. Exchanges do this at a volume no casino comes close to, and if there were a better pattern, they would have found it. There wasn’t. The structure was consistent everywhere.

That told me the value wasn’t in a new flow. It was in how carefully the known one gets built.

Currency and network are separate, adjacent fields. Not one combined dropdown. Network is the decision that produces the unrecoverable mistake, so it gets its own field and its own attention rather than being treated as a property of the currency.

The address block carries both a copy control and a QR code. The copy button removes transcription from the equation on desktop. The QR does something more useful: it lets someone deposit from a phone wallet without moving 34 characters between two devices by hand.

The minimum-deposit warning states the consequence, not the rule. Not “minimum 0.00005 BTC” but that anything below it won’t be credited or refunded. A threshold is a number people skim. A consequence is something they read.

A live fiat conversion sits at the bottom of the flow. People hold crypto but think in dollars. Entering $100 and seeing 0.003234 BTC is how the amount becomes real to them.

And directly beneath it, the caveat: the value may change between now and the time the payment is received. The conversion is a guide, not a guarantee, and saying so is more useful than a number that looks more certain than it is.

The wallet holds both paths. Same balance header, same promo code position, same deposit button. One product, not two.

The divergences are deliberate. The fiat flow has quick-amount chips: 50, 100, 500, 1000. Card users think in round fiat amounts and the chips save them typing. The crypto flow has none, because you can’t offer round crypto amounts when the rate moves. A “0.001 BTC” chip means something different every hour. So crypto gets the live conversion instead, which does the same job in the only way that works when the underlying value isn’t fixed.

Two payment paradigms, different failure modes, made to feel like the same product.

Eight months at an early-stage company meant working across most of the product. A few of the other surfaces:

The network mismatch warning is passive. It sits below the fields as static text, present whether or not the user is about to make a mistake.

If I were doing it again I’d make it conditional, appearing only when someone selects a combination that’s easy to get wrong, so it’s noticed rather than skimmed past. A warning that’s always on is a warning nobody reads, and this is the one failure in the flow that can’t be undone.