KLIK
BLIK-style instant payment system: one-time codes, mobile confirmation, merchant API — a small but full-stack take on how a national payment scheme works under the hood.
- Date
- 2025-12-01
- role
- FullStack
- Tags
- PythonDjangoDevOpsReddisDocker
A toy implementation of a BLIK-like payment scheme — small enough to fit in a weekend repo, real enough to think about race conditions, idempotency and expiring tokens.
How a payment flows
- User opens the merchant checkout, taps Pay with KLIK.
- Merchant backend asks the KLIK API for a transaction; gets a 6-digit code bound to that transaction.
- User types the code into their KLIK app; the app shows the merchant name and amount, asks for confirmation.
- Confirmation flips the transaction state; merchant polls / receives a webhook and ships the order.
What’s in the box
- Code service — generates 6-digit codes, single-use, ~2 minute TTL, backed by Redis-style expiring keys in Postgres.
- Mobile-style confirmation UI — Next.js, fake user account.
- Merchant API —
POST /tx,GET /tx/:id, signed webhooks. - Admin view — recent transactions, manual cancel, audit log.
Things this taught me
- Why “exactly-once” is a polite fiction and idempotency keys aren’t optional.
- How much of a real payment scheme is just state machines and timeouts.
- That UX of confirmations is harder than the crypto.
Not a real payment system. Don’t put real money near it.