KLIK

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

1. User opens the merchant checkout, taps Pay with KLIK.
2. Merchant backend asks the KLIK API for a transaction; gets a 6-digit code bound to that transaction.
3. User types the code into their KLIK app; the app shows the merchant name and amount, asks for confirmation.
4. 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.