Kenapa Keamanan di Tablet Kasir Itu Beda — dan Gimana PIN Auth Jadi Solusinya

Kalau kamu pernah berdiri di belakang meja kasir kafe yang lagi rame, kamu tahu betapa cepatnya semuanya harus berjalan. Pesanan datang bertubi-tubi, pelanggan antri, dan kasir harus fokus — bukan ngulik password.

Tapi di balik kecepatan itu, ada tantangan keamanan yang sering banget di-skip: tablet POS itu dipakai bareng oleh banyak orang. Beda banget sama laptop kantor yang satu orang satu device. Di dunia F&B, satu tablet bisa dipakai 3-5 kasir dalam satu hari. Dan setiap orang yang pakai harus bisa dipertanggungjawabkan — siapa yang proses transaksi ini? Siapa yang kasih diskon? Siapa yang void pesanan?

Ini cerita kenapa kita di CrescendPOS serius banget soal keamanan shared device, dan bagaimana desain PIN-based auth lahir dari kebutuhan nyata di lapangan.

Masalah: Email + Password Nggak Cocok buat Kasir

Coba bayangin skenario ini: shift pagi, kafe lagi penuh. Kasir A selesai handle pesanan, terus Kasir B mau gantiin karena Kasir A mau istirahat. Kalau pakai email + password standar, Kasir B harus:

• Logout dari akun Kasir A
• Buka halaman login
• Ketik email lengkap
• Ketik password (yang mungkin lupa karena jarang diketik manual)
• Tunggu loading

Sementara itu, pelanggan di depan nunggu. Antrian makin panjang. Kasir B stres. Akhirnya? Mereka nggak logout sama sekali — dan semua transaksi tercatat atas nama Kasir A. Akuntabilitas hilang.

Dari percakapan kita sama pemilik kafe, ini bukan skenario hipotetis. Ini realita sehari-hari. Banyak yang cerita bahwa kasir mereka akhirnya share satu akun sepanjang hari karena proses login terlalu ribet.

Dan ini bukan salah kasirnya. Ini salah desain sistemnya.

Solusi: Dua Layer Auth yang Saling Melengkapi

Di CrescendPOS, kita pisahkan dua jenis autentikasi karena perannya memang beda:

Layer pertama: Devise (email + password) — ini untuk owner dan manager. Mereka login sekali di awal hari, dan sesi mereka bertahan selama tablet aktif. Ini layer yang berat — butuh email, password, bahkan bisa ditambah two-factor authentication (TOTP) untuk keamanan ekstra.

Layer kedua: PIN 4 digit — ini khusus untuk kasir. Nggak ada email, nggak ada password. Kasir punya model data sendiri yang terpisah dari User. Mereka cuma butuh nama dan PIN 4 digit untuk switching.

Kenapa desainnya begini? Karena trade-off antara kecepatan dan akuntabilitas itu harus diselesaikan di level arsitektur, bukan di level UX hack.

Gimana PIN Auth Bekerja di Balik Layar

PIN kasir bukan sekadar 4 angka yang dicek pakai if-else. Ada beberapa lapisan keamanan yang kita terapkan:

• Bcrypt hashing — PIN disimpan sebagai bcrypt digest, sama seperti password. Bahkan kalau database bocor, PIN asli nggak bisa dibaca langsung.
• Lockout bertingkat — setelah 5 kali salah PIN, akun kasir terkunci selama 5 menit. Salah lagi? Lockout naik: 10 menit, 15 menit, sampai maksimal 60 menit. Ini mencegah brute-force tanpa menghukum kasir yang genuinely salah ketik sekali dua kali.
• Rate limiting — di level jaringan, kita batasi 10 percobaan PIN per IP per menit via Rack::Attack. Jadi meskipun seseorang coba bypass lockout, ada pagar tambahan.
• Audit log yang bersih — PIN digest di-redact dari audit log. Kita catat siapa yang login dan kapan, tapi nggak pernah expose data sensitif.

Flow-nya sendiri cepat banget dari sisi kasir: pilih avatar di grid, ketik 4 digit PIN, langsung masuk. Nggak ada form email, nggak ada loading halaman login. Pergantian kasir bisa terjadi dalam hitungan detik.

Switch Cepat Tanpa Kehilangan Konteks

Salah satu keputusan desain yang kita banggakan: ada dua jalur sign-out yang berbeda.

Ganti Kasir — ini cuma clear sesi kasir, tapi sesi Devise (owner/manager) tetap aktif. Kasir berikutnya tinggal pilih nama dan masukkan PIN. Tablet nggak perlu login ulang dari nol.

Kembali ke Admin — ini full logout. Sesi kasir dan sesi Devise sama-sama di-clear. Cocok untuk akhir hari atau kalau tablet mau dipindah ke area lain.

Bedanya penting. Ganti Kasir yang cepat berarti kasir nggak punya alasan untuk skip pergantian. Dan kalau mereka nggak skip, setiap transaksi tercatat atas nama kasir yang benar.

Manager Override: Akses Sensitif Butuh Persetujuan

Nggak semua operasi di POS boleh dilakukan semua orang. Ada aksi-aksi yang rawan penyalahgunaan kalau dibuka bebas:

• Void pesanan yang sudah selesai
• Kasih diskon di atas threshold tertentu
• Batal pesanan yang sudah dikirim ke dapur
• Penarikan kas atau setor tunai dari cash drawer
• Tutup shift dengan selisih kas yang besar

Untuk aksi-aksi ini, CrescendPOS membutuhkan PIN approval dari manager. Mekanismenya: saat kasir mau melakukan aksi sensitif, muncul dialog yang minta PIN manager. PIN ini diverifikasi dulu secara real-time sebelum form utama dikirim — jadi kalau salah PIN, dialog tetap terbuka dan kasir bisa coba lagi tanpa kehilangan konteks.

Kenapa ini penting? Karena tanpa pre-verify, PIN salah akan redirect ke halaman lain, dan kasir harus buka ulang cart, buka ulang modal edit, buka ulang dialog approval. Kehilangan konteks kayak gitu bikin flow terasa rusak — padahal cuma salah ketik PIN.

Setiap approval tercatat di audit log lengkap dengan siapa manager yang approve dan alasannya. Ini bukan cuma soal mencegah fraud — ini soal punya paper trail yang jelas kalau ada pertanyaan di kemudian hari.

Shift: Mengikat Transaksi ke Pertanggungjawaban

PIN auth dan manager override jaga keamanan per-aksi. Tapi ada layer akuntabilitas yang lebih besar: shift.

Setiap kasir harus buka shift sebelum bisa memproses transaksi. Shift mencatat:

• Siapa kasirnya
• Kapan shift dibuka
• Berapa saldo kas awal
• Semua pesanan yang diproses selama shift
• Semua pergerakan kas (setor, tarik, refund)
• Saldo kas akhir dan selisihnya dengan ekspektasi sistem

Saat shift ditutup, sistem otomatis menghitung expected balance berdasarkan semua transaksi tunai dan pergerakan kas selama shift. Kasir memasukkan actual balance — berapa uang yang benar-benar ada di laci. Selisihnya langsung kelihatan.

Kalau variance-nya di atas threshold, shift close butuh approval manager. Ini memastikan kalau ada ketidaksesuaian kas yang signifikan, ada orang kedua yang tahu dan menyetujui.

Yang penting: setiap order terikat ke satu shift, dan setiap shift terikat ke satu kasir. Nggak ada transaksi yang orphan tanpa pemilik. Kalau ada pertanyaan soal transaksi tertentu, kamu bisa trace balik: transaksi ini, shift ini, kasir ini, jam segini.

Audit Trail: Setiap Aksi Punya Jejak

Semua layer di atas nggak akan berarti tanpa pencatatan yang proper. Di CrescendPOS, setiap mutasi pada Order dan OrderItem dicatat di audit log dengan atribusi kasir yang jelas:

• opened_by_cashier — siapa yang buat pesanan
• closed_by_cashier — siapa yang selesaikan transaksi
• cancelled_by_cashier — siapa yang batalkan
• discount_applied_by_cashier — siapa yang kasih diskon
• added_by_cashier / removed_by_cashier — per item, siapa yang nambah atau hapus

Ini bukan log teknis yang cuma developer bisa baca. Ini data yang bisa diakses owner lewat dashboard untuk review aktivitas per kasir, per shift, per hari.

Desain yang Lahir dari Kebutuhan Nyata

Semua keputusan di atas bukan datang dari textbook keamanan. Mereka lahir dari satu pertanyaan sederhana: gimana caranya kasir bisa ganti giliran dalam 3 detik, tapi tetap setiap rupiah bisa dipertanggungjawabkan?

Jawabannya bukan satu fitur. Jawabannya adalah lapisan-lapisan yang saling melengkapi: PIN auth yang cepat tapi secure, manager override untuk aksi sensitif, shift untuk batas waktu pertanggungjawaban, dan audit trail untuk transparansi penuh.

Kalau kamu lagi evaluasi sistem POS untuk bisnis F&B kamu, jangan cuma tanya fitur apa aja yang ada. Tanya juga: gimana sistem ini handle situasi di mana 3 kasir pakai 1 tablet dalam 1 hari? Jawabannya akan membedakan sistem yang benar-benar didesain untuk restoran, dari yang cuma adaptasi software kantor biasa.