Consumer fintech · QR payments · Nigeria

Shappay

A QR-driven payment resolution engine that picks the right financial rail — wallet, bank, or external network — from the merchant and user preferences.

The problem

Nigerian transfers still run on 10-digit account numbers read aloud, mistyped, and trapped inside individual banks. There is no shared way for a small merchant to be paid without giving out their account details.

The outcome
4screens end to end, one decision each
NQRlive EMVCo payload engine on NIBSS rails
2addressing modes: QR scan and name@shappay
Role
Product Designer & Engineer · Founder
Timeline
2025 – present
Team
Solo: design → front-end
Tools
Figma · React Native · Expo
Pre AlphaRead the full case study →
Solution at a glance

What it actually does.

Four screens carry the whole payment loop. Each one makes a single decision, so the path from opening the app to a settled payment stays short on purpose.

Shappay across four screens: phone-number login, wallet dashboard, receive-money QR, and the scan-to-pay camera
Phone-number loginNo email, no password — a number and a code, and the account exists.
Wallet dashboardBalance, quick actions, and recent transactions in one view.
Receive by QRA shareable code and a name@shappay address, both resolving through one engine.
Scan to payOpens straight to the camera — no menu, no account number.
Experience

See it in motion.

A 60-second walkthrough of the core payment loop: scan, resolve, and settle. Running on the actual React Native build.

iPhone frame

Scan → Resolve → Wallet debit → Confirmation

Live · The engine

This is the payload, built in real time.

Every NQR code is an EMVCo TLV string: a chain of Tag · Length · Value triplets sealed with a CRC-16 checksum. In the live build this regenerates as you type; here is the engine's output for a static merchant code.

Shappay · NQR Payload BuilderEMVCo MPM · CRC-16/CCITT
Static QR carries no amount; the payer types it at scan time.
Scannable EMVCo QR · currency 566 (NGN) · country NG
TagFieldValue
Raw payload
The core flow

Four screens, one decision each.

The whole payment loop is short on purpose. Every screen earns its place; here is what each one is doing and why.

Dashboard screen
01 · DashboardQuick overview of recent transactions and your wallet balance.
→
Scan screen
02 · ScanOpen straight to the camera. No menu, no account number to read aloud.
→
Confirm screen
03 · ConfirmSurfaces the resolved merchant and amount before settling, so the payer is always in control.
→
Done screen
04 · DoneInstant wallet debit with a receipt the payer can act on, not a spinner waiting on a bank.
Success metrics

What good looks like, defined up front.

Quantified targets set before build; not retrofitted after. These are the numbers the product is designed around.

RESOLUTION LATENCY

< 200ms

QR parsed and routing decision output before the user reads the merchant name.

WALLET-TO-WALLET

> 99%

Internal Anchor ledger transfers. Near-perfect reliability by bypassing bank uptime.

TIME TO CONFIRM

< 3 seconds

PIN entry to merchant alert dispatch. The standard every design decision defers to.

EXTERNAL PAYOUT

> 95%

Async outbound bank payouts via Anchor. Accounted for in UX with async confirmation states.