klientakarte.lv, loyalty without surveillance

Stopping stamp fraud

A paper card can be forged with a €2 stamp from a hardware store. A digital one has to be harder to cheat, by staff or customers.

• No anonymous stampingEvery stamp needs a signed-in staff member or an internal system action, and the ledger records which one.
• Staff sessions locked downStaff sign in with a PIN, a locked session asks for the PIN again on every page, and each staff member can be signed in on one device only.
• No double stampsIdempotency keys mean a retried request or a double tap records one stamp. Merchants also set a daily stamp limit per customer.
• Offline without double rewardsThe scanner keeps working offline. When two devices redeem the same reward, the server accepts the first and shows staff a conflict warning for the second.
• An audit trail by designStamps and redemptions go into an append-only ledger, so "your app says 7, I counted 6" always has an answer. Merchants see a staff activity log.

Privacy by design

• Zero-field enrollmentNo email, password or phone number to get a card. Session keys and short rate limits keep bots out without a sign-up form.
• Consent kept separateAdding a pass never counts as marketing consent. Consent is recorded on its own, and customers can unsubscribe from the pass itself.
• Each merchant owns its dataNo shared card across businesses, and staff can only reach their own merchant's data, checked on the server for every action.
• Data stays in the EUThe database and its backups are stored in the European Union.
• Monitoring without personal dataError reports carry route patterns and a merchant ID only, with emails scrubbed. Analytics run only after consent.

Accounts and operations

• Hardened merchant sign-inSelf-hosted Better Auth, one-time sign-in links behind a confirm page, a redirect allowlist, and rate limits per email and IP.
• Admin kept apartThe admin panel runs on its own host with two-factor authentication, an audit log and origin checks.
• Encrypted, tested backupsThe database is backed up, encrypted, to EU storage, in full every week and incrementally every day. I've run and timed a full restore drill.
• Database off the internetThe database server only listens on a private network, with key-only SSH and password logins off.
• Kill switchesAdmin switches stop sign-ups, uploads, emails or wallet jobs in seconds, and new cards can be paused per merchant. Incident response starts with being able to stop things.
• Audited before launchI ran a security audit and an external scan, fixed the findings, and keep the audit reports private.

Still open before launch

• OPENRepeat the restore drill with real data now that production runs on the new database.
• OPENLegal review of the privacy notice and terms.
• OPENRun the database integration tests in CI as well as on my machine.
• OPENA one-page incident response runbook, including the 72-hour notification path for personal data.
• OPENA written data protection impact assessment (DPIA) for customer and merchant data.
• EXPLORINGMoving merchant sign-in from self-hosted Better Auth to Clerk, a managed service, so I'm not maintaining the login layer myself.
• EXPLORINGA tamper-evident stamp history, with daily fingerprints of the ledger anchored publicly and no personal data leaving the database.