Skip to content
← Back

CryptoCard

Crypto-fintech: wallets, virtual cards, exchange, analytics — a Go backend and a SwiftUI client.

Type
Fintech platform — API, iOS app, web client
Role
Backend, iOS, web, design system
Year
2026
Visual showcase
CryptoCard interface
static previewopen in a new tab ↗
Overview

Hold crypto, issue virtual cards, spend anywhere. Wallets in USDC, USDT, BTC and ETH; virtual cards with instant freeze and per-period limits; deposits with live confirmation tracking; an integrated exchange; spending analytics; KYC and membership tiers.

Problem

Card products fail in the parts nobody sees. Balances that drift under concurrency, quotes that can be replayed, refresh tokens that survive theft — none of it shows in a mockup, and all of it decides whether the product can exist.

Solution

A Go API where correctness is structural: balances move through atomic conditional updates inside transactions, exchange quotes are single-use and expire in thirty seconds, card limits are consumed atomically, and every sensitive action lands in an audit log. On top of it, a SwiftUI client and a web client that share the same contract.

Technology
  • Go 1.23
  • Fiber
  • GORM
  • PostgreSQL 16
  • Redis
  • JWT
  • WebSocket
  • Swift 6
  • SwiftUI
Key features
  • Wallets across USDC, USDT, BTC, ETH and EUR with live fiat valuation
  • Virtual cards: issue, freeze, per-period limits, audited PAN reveal
  • Deposits progressing detected → confirming → completed over WebSocket
  • Exchange with a thirty-second single-use quote
  • Smart payment routing across assets
  • Spending analytics and insights, KYC, three membership tiers
CryptoCard screen
CryptoCard screen
Technical challenges

Money that cannot drift

Balances are debited and credited with atomic conditional SQL updates inside transactions, so a concurrent spend cannot read a stale balance. Card limits are consumed the same way.

Quotes that cannot be replayed

An exchange quote lives in Redis and is claimed with GETDEL — the read that consumes it also destroys it. It expires after thirty seconds. Financial POSTs additionally carry idempotency keys.

Refresh tokens that survive theft

Refresh tokens are stored only as SHA-256 hashes and rotate on every use. Presenting a rotated token revokes the entire token family, so a stolen token burns itself and locks the thief out.

A demo mode that is architecture, not a mock

The iOS client ships repository protocols as a seam between demo and live data, with one actor holding a coherent demo world. The web client shown here was given the same seam: the transport is replaced, every screen above it is the real client.

Get in touch →