Fintech app · Cards · 2026

What does it take to put a real card in a crypto app?

An issuing flow the user can abandon and resume — waiting on identity checks, deposits and a payment network, for as long as it takes.

My role

Sole designer

Product

Visa card inside a crypto app

Client

Under NDA

Scope

Issuing flow, card tab, top-up, second generation

The problem

A card is the moment crypto has to become ordinary money.

Everything inside the app is balances and positions. A card is the first thing that leaves it — it has to work at a checkout, in a country with rules, on a payment network with requirements.

That turns issuing a card into something most product flows never have to handle: a process the user cannot finish in one sitting, and that waits on events outside the interface.

The core idea

The card page is a state, not a screen.

Issuing starts from the menu, from the home screen, or from a deep link. Along the way it can require identity verification or a deposit — and either can take the user five minutes or three weeks.

So instead of trapping the flow in a chain of modals, the card page itself changes according to the step: it waits for verification, or it waits for funding, and it says so. The user can close the app at any point and come back to a page that remembers where they stopped.

An interruptible flow needs a home, not a wizard. Modals assume the user finishes now; a page can wait indefinitely.

Fig. 01 — The issuing flow: the same page waiting on verification, on funding, on the network

The rest of the surface

What else the card needed

01 — Before issuing

Explaining a product that doesn't exist yet

Before launch the card lived as a waiting list: what it is, where it works, what it costs at launch, and nine questions people actually ask — fees, top-ups, Apple Pay and Google Pay, ATM withdrawals, which countries. Plus the disclaimer that the country list may change, so pre-registration guarantees nothing.

Fig. 02 — The questions answered on the page itself, before anyone has to write to support

02 — After issuing

Top-up, transactions, control

Once a card exists, it needs the unglamorous half: funding it from a crypto balance with a visible conversion, the record of what was spent, and the controls people reach for when something looks wrong.

Fig. 03 — After issuing: the card, the confirmation code every sensitive action needs, and the controls

Fig. 04 — Top-up from a crypto balance: limits, conversion, and both endings — accepted and refused

03 — Craft

The carousel, and a prototype instead of a description

Card art needed motion — a carousel with a background animation. Rather than describing the behaviour in a comment, I built a working HTML prototype and attached a recording to the ticket, so the front-end could see the timing instead of interpreting adjectives.

Fig. 05 — The carousel component: card in view, next one peeking, art that had to move

04 — Second generation

Promo codes and what they do to a flow

The next iteration added promotional codes — which sounds like one input field and is in fact a new branch: a code can be invalid, expired, already used, or valid but not for this user. Each of those is a state on the same waiting page.

Fig. 06 — Second generation: e-mail confirmation, the price, and each way it can fail

Where it went

From waiting list to a card people carry.

The issuing flow shipped, the card tab was redesigned in the main wave, top-up got its own pass, and a second generation with promo codes is in review.

Alongside the product work I designed the campaign that sells it — five audience segments, and the constraint that the word “crypto” never appears in the copy.