Case file 02 · 2026

Crypto in.Dollars out.

2026 · Payments · Mobile + Web · Pilot · Azerbaijan

Designing a payments product that lets shops take stablecoins at the counter and get paid in dollars, from the landing page that sells it to the app that runs it.

Live: navispay.com

Project: NavisPay
Product: Mobile app, merchant dashboard, landing page
Role: Product designer, research to iteration
Year: 2026

00.1 Opening and TL;DR

To a shop owner, "accept crypto" sounds like risk and paperwork. The design job was translation.

I designed NavisPay around one principle: show the money, hide the machinery.

Users: Small and medium merchants and their customers
Market: Pilot in Azerbaijan
Accounts: Personal and merchant, under one login
Built with: Claude Code, Figma, Figma Make

01.1 One coffee, three percent gone

A card sale leaks money at every step.

Every card sale pays three times: a fee, a wait, and the risk of a dispute.

07:45 AM€4.80 sale.
07:45 AMThree percent leaves before the money arrives.
FridayThe money lands three days later.
Next monthAnd a dispute takes it back.
End of file
Scroll down to see the counter now.

1 / 5

Illustrative scenario · dummy data

card_sale_trace.log€4.80 sale · before NavisPay

01Customer taps a card✕ 2–4% goes to the processor
02Processor holds the money✕ 1–5 business days
03Foreign card✕ FX markup on top
04Customer disputes✕ merchant pays the chargeback
05Owner wants a better rail✕ integration takes weeks

01.2 Why it's hard

The rail was ready. The words weren't.

Stablecoins already solve the fees, the holds and the chargebacks. Everything around them was the hard part.

E1 · Trust

Reads as risk

Merchants judge a rail by fee, speed and risk. Wallet addresses land in the risk column.

Market research

So: speak in dollars, cards and balances.

E2 · Both sides of the counter

Two sign-ups

Shop owners pay as customers too. Two apps would mean two sign-ups.

Pilot merchants

So: one download, two roles.

E3 · Which side am I on?

Wrong side

Merchants with both accounts tried to take payments on the personal side.

Pilot feedback

So: the whole screen changes with the account.

E4 · Second-language reading

Long strings

Users read English as a second language, and Azerbaijani strings run long.

Pilot market

So: one word per status, the same word everywhere.

02.1 Flows and structure

One login, two accounts, one payment.

The hard part was state: one login with two accounts, a card that hides itself, and a payment two phones agree on.

Object	States	Rule
Account	personal / merchant, under one login	The theme follows the account: light for personal, dark for merchant. The other type can be added later.
User	onboarding → signed up (2 steps) → identity verified → active	Sign-in detects the account type.
Card	empty → added → details masked / revealed (hides again after 15 s)	A card with a balance, never a wallet address. Screenshots blocked.
Payment	keyed → ready to tap → biometric approval → confirming (1/3 → 3/3) → complete	5 statuses, each a dot plus a word. "Complete", never "settled".
Receipt	issued	Shows the network fee and transaction hash.
Sale refund	requested → confirmed in a named dialog	Irreversible, so a dialog, never a snackbar.

Fig 01 · Information architecture

NavisPay

Onboarding

3 panes: Tap to pay · Your keys never leave · Settles in seconds
Merchant entry on the last pane

Account type: I'm paying / I'm a merchant
Step 1 of 2 · step 2 of 2
Identity verification Gate
Sign in detects the account type

Personal tabs Main screens · light

Home · Cards · Activity · Profile
Biometric approval before every payment Gate
Receipt Sub-screen

Merchant tabs Main screens · dark

Take · Sales · Payouts · Profile
Sale refund Named dialog

Account switcher

From the home avatar, in both accounts

Merchant dashboard (web)

Overview
Receipts → receipt detail
API keys
Token settlement
Payment links

ScreenGate

Notice the two gates. Hover a table row to light the screens that use that object.

User flows

Fig 02 · A · First run

Launch
Onboarding 3 panes · Skip and Back
Merchant? Yes: merchant entry on the last pane · No: sign up
Sign up I'm paying or I'm a merchant
Step 1 of 2 · step 2 of 2
Identity verification Gate
Personal: "Add your first card" Light theme
Merchant: Take tab Dark theme

DecisionGateSafe outcome

Notice the account type is asked once and sets the first theme.

02.2 The research-to-design strategy map

Every decision traces back to research.

Research evidenceCore insightDesign decision

Card fees of 2–4%, 1–5 day settlement and chargebacks paid by the merchant.Market research

I1Merchants judge a payment rail by what they keep and when, not by the technology.

D3Hide the crypto

Pilot shop owners are often customers somewhere else too. Two apps would mean two sign-ups and two identity checks.Pilot merchants

I2Two apps means two sign-ups, two identity checks and two brands to trust.

D1One app with two roles

Merchants with both account types tried to receive payments from their personal side; they couldn't tell which side they were on.Pilot feedback

I3People with two accounts need to know which side they're on before they act.

D2The account type decides the theme

Two strong messages, ease and global reach, and no data on which one merchants respond to.Hero concepts

I4We didn't know which message would land, so we shouldn't guess.

D4Test the message with two heroes

Users read English as a second language, and Azerbaijani strings run long.Pilot market

I5Words have to survive second-language reading, and color alone isn't enough.

D5A dot plus a word for every status

02.3 Key design decisions

Five decisions that shaped the screens.

Decision 01 D1 What I decided

One app that is both a personal wallet and a merchant terminal. The account type is picked first, at sign-up, and a switcher hangs off the home avatar.

Switcher · from the home avatar

Live prototype screens · dummy data

Decision 02 D2 What I decided

Personal accounts use the light theme and merchant accounts the dark theme, across the whole app.

Personal · light

Merchant · dark

Live prototype screens · dummy data

Decision 03 D3 What I decided

The product speaks in dollars, cards and balances. The x402 protocol only appears in the FAQ; receipts keep the network fee and hash.

A card with a balance

Receipt keeps the fee and hash

Live prototype screens · dummy data

Decision 04 D4 What I decided

Two hero versions behind a switcher. Devices shows how simple tap to pay is; Globe shows payments without traditional banking limits.

Devices hero: Take USD at the counter, with a customer phone and a merchant terminal held in two hands. — Hero A · Devices

Globe hero: Stop losing 2–4% of every sale to payment fees, next to a globe with live settlements. — Hero B · Globe

Landing page heroes · dummy data

Decision 05 D5 What I decided

Each of the five payment statuses is a colored dot plus one word, used everywhere: "complete", never "settled".

Sales · complete, 1 / 3 conf

Terminal · approved, 3 / 3

Live prototype screens · dummy data

Try it · decision 02

Bluejay Coffee House Merchant accountMerchant

Today's takings3,480.00

Take a payment→

A theme per account: the whole screen turns dark the moment you're on the merchant side. Illustrative mock · dummy data

02.4 Two design systems

Same brand, different physics.

The dashboard is square and hairline-ruled. The app is soft and floating. In the app, the account type picks the band.

Web design system cover: The components that build NavisPay, with square surfaces and hairline borders. — **Home**Personal wallet on the light band, merchant takings on the dark band. Same layout, different physics.

Mobile design system cover: The components that build NavisPay on a phone, with soft surfaces and floating cards. — **Home**Personal wallet on the light band, merchant takings on the dark band. Same layout, different physics.

03.1 Landing page

Sell the counter, not the chain.

The page leads with what a shop keeps and when. The hero rotates the currency a shop can take.

NavisPay landing page hero: take crypto at the counter, with a customer phone and a merchant terminal held in two hands.

Open live site

Explore the live page

The live page at 1440px, scaled to fit · press Esc or move away to scroll this page againVisit live site

03.2 App prototype

Tap, approve, paid. On both phones.

Twenty screens: 14 mobile and 6 dashboard. Tap to pay alone holds 11 of the app's 28 states.

Fig 09 · What one tap sets off

Tap✓
Biometric approval✓
Confirming 1/3✓
Confirming 2/3✓
Confirming 3/3✓

Customer · Payment completeMerchant · Payment received

Illustrative mock · dummy data

Both screens move together, so nobody asks whether it went through.

Fig 10 · The whole app, screen by screen

Live prototype screens · dummy dataPlays while in view

Highlights

01One app that is both wallet and terminal
02The account type picked before anything else
03A card with a balance, not a wallet address
04Both screens move through tap, approve, confirming, complete together

Whole project · Big idea

You can tell from across a counter whether a phone is spending or taking money.

One screen · Merchant home

Dark band, today's takings, and one big Take a payment button.

One small part · The band color

One surface value, #EEF1F6 or #0A1730, carries the whole signal.

03.3 Reflection

One app, two very different people.

The hardest part of NavisPay was designing one app for two people on opposite sides of the counter. A customer wants to pay and walk away. A merchant needs to know, at a glance and from a step back, that the money arrived. That is why the merchant side is dark: you can tell which side a phone is on before reading a word.

I also wanted a crypto payment to feel like any other tap to pay. People see a card with a balance in rAZN, not a wallet address, and the testnet details stay in the profile and on receipts. Security had to be visible without being scary. Keys stay in StrongBox, every payment asks for a fingerprint or face, and card details hide again after 15 seconds, so nothing is left on screen by accident.

Localizing for Azerbaijan shaped the words as much as the layout. Azerbaijani strings run long, so every status is one short word with a dot.

Next, I would watch pilot merchants use the full tap flow at a real counter, and design the moments when a tap fails or the network is slow with the same care as the happy path.

Başak Uğur Önem · Product Designer