← All Work
B2B Fintech Payments 2024 → Present

Merchant Cabinet:
one QR, five banks,
40,000 merchants

Kazakhstan's first interbank Unified QR — and the SME platform it runs on. I led design and discovery from a thin MVP to 40K+ active merchants.

98.5%Transaction Success Rate
4.92VoC Score (12 months) — #1 in KZ
40K+Active Merchants per Month
#1Interbank Unified QR in Kazakhstan
RoleSenior Product Designer · Lead scope
CompanyHome Credit Bank KZ
PeriodJul 2024 → Present (2+ years)
PlatformiOS · Android
01 · SYSTEM SIDE — WHAT THE DESIGN ABSORBS 02 · MERCHANT SIDE — WHAT THEY SEE THE LINE FIVE ISSUING / ACQUIRING BANKS BANK A BANK B BANK C BANK D BANK E Unified QR switch routing · settlement · reconciliation interoperability kyb / kyc paths payment states states absorbed: success · processing · declined · refund ONE STANDARD OUT the merchant never sees the left side One QR dynamic / static · pos-linked 3 TAPS · UNDER 3 SEC Deciding which complexity stays in the system — and which reaches the merchant's screen. That line, not the QR's looks, was the design decision. One QR, five banks behind it — which complexity stays in the system, and which reaches the merchant

Expose the five banks, or hide them

The design decision was never how the QR looked. It was which complexity stays inside the system — and which reaches the merchant's screen.

The obvious build was the honest one: let merchants pick which bank settles the payment, show the routing, surface the technical reality. Honest, and unusable. I made the opposite call — the merchant flow shows none of it. One QR, dynamic or static, three taps. The customer scans with any banking app in Kazakhstan and it works.

Fork 01 · The brief

Changed the brief, not the UI

50+ merchant interviews said the pain wasn't the interface. It was multi-bank complexity, and underneath it one fear: will the money actually arrive?

Information architecture rewritten before a screen shipped
Fork 02 · Architecture

Hid the routing completely

Showing which bank settles would have been transparent and unusable. The system absorbs interoperability, KYB/KYC paths and payment states instead.

3 taps · under 3 sec to a working QR
Fork 03 · Where the budget went

Spent it on the receipt, not the QR

If trust is the real job, the money goes into confirmation speed and receipt clarity — not into the screen everybody looks at first.

98.5% transaction success · 4.92 VoC
Fork 04 · Verification

Three compliance paths, not one

Sole traders, LLCs and the self-employed each need a different route. One generic flow would have failed all three, so I broke it into steps.

Compliance satisfied without reaching the merchant
Fork 05 · Scope under a deadline

Shipped intra-bank first, on purpose

Invoice to Pay needed a date. A half-built interbank flow was the easy path. I cut to one complete flow and put the rest on a visible roadmap.

Scope debt on the roadmap, not in production
Fork 06 · The design system

Parallel track, not a side project

Tokens in Token Studio syncing straight to GitHub, so features stopped waiting on handoff and the product stayed coherent across two years of additions.

92–96% of production colours on tokens
Walk the full decision tree — six forks, each with what I rejected
The long version — how the reframe happened

Home Credit Bank Business is the merchant banking platform for small and medium businesses in Kazakhstan — payments, QR acquiring, sales analytics, and business management tools in one place. I joined as lead product designer at the moment Merchant Cabinet was an MVP with limited features and low perceived value, while the bank was preparing for a national-level milestone: launching Kazakhstan's first interbank Unified QR, a state-driven initiative to unify QR payments across all major banks under a single standard.

Two challenges sat on top of each other: mature the merchant experience to match enterprise scale, and design a payment flow that hides the complexity of five banks behind a single QR a merchant can generate in under three seconds.

My process closes the loop between a hypothesis and the metric it moves: 50+ in-depth merchant interviews across 12 months covering offline retailers, e-commerce sellers, multi-POS chains and solo entrepreneurs; continuous usability testing on every major flow before release; A/B testing before and after launch; post-launch tracking of VoC, adoption and retention. No feature shipped without an explicit hypothesis tied to a measurable outcome.

The headline finding wasn't about UI. The #1 pain was multi-bank complexity, and the deepest anxiety was "will the payment actually reach me?" That moved the brief from "improve the merchant UI" to "enable any-bank payments and make settlement trustworthy". The reframe changed what we built, not how it looked. We were close to shipping an information architecture based on assumptions from the bank side; the interviews rewrote it.

Under that single QR sat three kinds of complexity I had to absorb so the merchant never felt them: interoperability — one code settling across five banks; merchant heterogeneity — sole traders, LLCs and the self-employed each needing a different verification and compliance path (KYB/KYC, limits); and payment states — success, processing, declined, refund, plus multi-POS merchants. I untangled the branching logic with a systems analyst on grooming calls and broke verification into steps, so the hard part stayed inside the system rather than on the merchant's screen.

The Payment Invoice cut worked the same way. The full cross-bank version would have taken too long for the date, and shipping a half-built interbank flow was the easy path and the wrong one. I made a deliberate, team-agreed cut: intra-bank first, a complete flow for clients of the same bank, with an explicit roadmap to extend it. That extension is in active build now. This is the job in fintech — deciding which complexity the user absorbs and which the roadmap carries, then defending that line in front of a commercial stakeholder or a deadline.

Unified QR merchant flow — branching map: merchant type → verification → bank routing → payment states Unified QR flow — the branching reality behind one merchant QR: merchant types, KYB/KYC paths, payment states

What made this hard

  • Regulatory — checkpoints with the National Bank of Kazakhstan; compliance had to pass before UX could.
  • Cross-bank on day one — every major bank at launch, with no local precedent to copy.
  • Trust, not task — merchants don't care about QR. They care whether the money lands.
  • Enterprise volume — every call had to hold inside the bank's business model and its backend limits.
HCB Business research process

Seven features, each scoped against a number

Unified QRInterbank standard, dynamic and static modes, POS-linked98.5% success · 60%+ primary
DashboardDaily KPIs — sales, transactions, payment mix — with widget pinning70% monthly adoption
Sales AnalyticsFour widgets: sales and returns, customer profile, per-POS, payment method45% regular export
Invoice to PayDigital invoicing straight from the merchant app to the customerIntra-bank live · interbank in build
QR Installments & CreditBuy-now-pay-later triggered by the scan, lifting average order value
Points of SaleMulti-POS editing, payment methods, addresses, promo material ordering
Sales HistoryFull transaction logs with advanced filters and export
HCB Business merchant cabinet overview
HCB Business design detail HCB Business interaction

A system, not a sticker sheet

Built from scratch as a parallel track to the features. Atomic tokens live in Token Studio and sync straight into the codebase over GitHub — no manual conversion, no handoff gap. Light and dark ship out of the box; components sit on top of the tokens, themeable and accessibility-checked.

92–96% of production colours on tokens, measured by a build-time script in the pipeline.

Components ship with rules, not pixels: a Button's doc names the pattern — one Primary per view — and the anti-pattern that breaks it. Writing down the why, and running the workshops around it, is how I lead the function beyond my title. The system holds without me.

Component spec sheet: Button anatomy, states, token bindings, DO/DON'T anti-patterns — plus Token Studio → GitHub → build pipeline Components ship with rules, not pixels — anatomy, states, anti-patterns, and the Token Studio → GitHub pipeline that enforces them
Design-system governance board: a documented decision with its 'why', contribution and review rules, and the workshop cadence that keeps the team aligned Governance, not just a library — a documented decision with its why, contribution rules, and the workshop cadence that keeps the system holding without me

Where it landed

Two years in, Merchant Cabinet is the highest-rated SME banking platform in Kazakhstan — a 4.92 VoC sustained across 12+ months, 40,000+ active merchants a month, and 98.5% transaction success on Unified QR. Behind the headline four: 70% monthly adoption of the analytics dashboard and 45% regular PDF/Excel exports.

HCB Business sales analytics screens

Discovery before pixels

We were one decision away from shipping an information architecture built on the bank's assumptions. The merchant interviews rewrote it. Unified QR then lowered the barrier to cashless acceptance in a country whose small businesses have historically defaulted to cash.

The lesson I keep relearning: in fintech the hardest design problem is usually the trust underneath the screen — making a busy merchant believe the money will arrive, across banks they don't control. You only find that by talking to the people who live in the product.

HCB Business result 1 HCB Business result 2
Next case

Interior Trends — AI Discovery

Named routes into the catalogue, and a product page that says why a thing fits.

Read it

Want to discuss this project?

Download CV ↗