Kenapa Kami Terobsesi dengan Flow Pembayaran — Setiap Tap Itu Penting

30 Detik yang Menentukan Segalanya

Di sebuah transaksi kafe, payment flow itu momen terakhir — customer udah pilih menu, kasir udah input pesanan, tinggal bayar. Harusnya simpel, kan? Tapi dari observasi kami, ini justru momen di mana paling banyak friction terjadi.

Kasir harus pilih metode bayar, input nominal, hitung kembalian (kalau cash), pastiin pembayaran sukses (kalau digital), baru bisa move ke customer berikutnya. Setiap detik yang hilang di payment flow itu detik yang nggak bisa diambil balik — dan kalau ada 50 transaksi per shift, inefficiency kecil di payment flow jadi masalah besar secara aggregate.

Keputusan Desain Pertama: Numpad, Bukan Keyboard

Waktu mendesain input nominal pembayaran, opsi yang paling "gampang" buat developer adalah pakai keyboard standar. Tapi keyboard standar di tablet itu nightmare untuk kasir: tombol kecil, ada huruf yang nggak relevan, dan posisinya di bawah layar yang bikin tangan harus stretch.

Kami pilih numpad custom — angka besar, posisi yang natural untuk jempol, dan layout yang konsisten. Ini keputusan yang kedengerannya trivial, tapi dampaknya significant: kasir bisa input nominal tanpa lihat ke layar, karena posisi tombol sudah muscle memory.

Ada trade-off: numpad custom berarti kami harus build dan maintain komponen sendiri. Keyboard standar itu "gratis" dari sistem operasi. Tapi trade-off ini worth it karena payment flow dipakai di setiap transaksi — improvement di sini punya multiplier effect terbesar.

Quick Amount Buttons: Menghilangkan Kebutuhan Input

Observasi menarik: di banyak transaksi cash, customer bayar dengan nominal umum — Rp 50.000, Rp 100.000, "uang pas". Kalau setiap kali kasir harus ketik nominal ini manually, itu repetitive work yang seharusnya bisa dieliminasi.

Kami tambahkan quick amount buttons: tombol-tombol shortcut untuk nominal yang paling sering dipakai. Satu tap, nominal terisi, kembalian otomatis dihitung. Untuk transaksi Rp 28.000 yang dibayar Rp 50.000, kasir cuma butuh satu tap — nggak perlu ketik 5-0-0-0-0.

Yang lebih menarik: quick amount buttons ini bisa intelligent — suggest nominal berdasarkan total transaksi. Kalau total Rp 28.000, suggest Rp 30.000 dan Rp 50.000. Kalau total Rp 85.000, suggest Rp 100.000. Ini mengurangi cognitive load kasir dari "berapa ya customer bayar?" ke "tap yang sesuai."

Split Payment: Fitur yang Kami Hampir Nggak Bangun

"Customer mau bayar setengah cash, setengah QRIS." Ini use case yang kami awalnya anggap edge case — berapa sering sih? Ternyata: cukup sering untuk bikin kasir bingung.

Tanpa split payment, kasir harus workaround: proses satu metode bayar, void sisanya, proses metode kedua... kacau. Dengan split payment yang proper, kasir bisa: pilih metode 1 → input nominal → pilih metode 2 → input sisa → selesai. Clean, tercatat, reconcilable.

Pelajaran kami: edge case yang melibatkan uang itu bukan edge case. Kalau salah handle, dampaknya langsung ke selisih kas dan rekonsiliasi. Lebih baik support dari awal daripada bikin kasir improvise workaround.

Kembalian Otomatis: Menghilangkan Mental Math

Ini philosophi yang kami pegang di seluruh payment flow: kalau bisa dihitung otomatis, jangan suruh manusia hitung. Bukan karena kasir nggak bisa hitung — tapi karena hitung manual di bawah tekanan (antrian panjang, customer nunggu) itu sumber error yang preventable.

Total Rp 28.000, customer kasih Rp 50.000 → kembalian Rp 22.000 otomatis ditampilkan. Kasir tinggal ambil uang dari laci sesuai angka yang ditampilkan. Zero mental math.

Efek samping yang positif: kasir baru yang belum terbiasa dengan transaksi cepat tetap bisa handle payment tanpa error, karena sistem yang bantu hitung — bukan ingatan mereka.

Kenapa Kami Pilih "Pilih Metode Bayar Dulu, Baru Input Nominal"

Ada dua flow yang mungkin:

• Opsi A: Tampilkan semua metode bayar → kasir pilih → lalu input nominal (kalau cash) atau tunggu konfirmasi (kalau QRIS).
• Opsi B: Kasir input nominal dulu → lalu pilih metode bayar.

Kami pilih Opsi A. Alasannya: metode bayar menentukan apa yang terjadi selanjutnya. Kalau cash, kasir perlu input nominal dan lihat kembalian. Kalau QRIS, kasir perlu tampilkan QR dan tunggu konfirmasi. Dua flow yang beda — dan memilih metode di awal memastikan kasir langsung masuk ke flow yang benar tanpa backtrack.

Di Opsi B, kasir input nominal dulu tapi belum tahu flow selanjutnya apa. Ini bikin experience yang less predictable.

Satu Layar vs Multi-Step Wizard

Perdebatan internal terpanjang kami: apakah payment flow harus satu layar (semua opsi visible sekaligus) atau multi-step (satu langkah per layar)?

Kami settle di hybrid: metode bayar dan numpad di satu layar (minimize taps), tapi konfirmasi QRIS di layar terpisah (karena butuh QR code yang besar dan jelas). Ini compromise antara kecepatan (satu layar = less navigation) dan clarity (QRIS butuh dedicated space).

Metric yang Kami Track

Kami nggak cuma desain payment flow berdasarkan intuisi — kami hitung:

• Jumlah tap dari "mau bayar" sampai "selesai." Untuk cash payment nominal umum: 2 taps (pilih metode + quick amount). Ini target yang kami jaga.
• Waktu average dari pilih metode sampai transaksi complete. Target: di bawah 10 detik untuk cash, di bawah 15 detik untuk QRIS (termasuk waktu customer scan).

Intinya

Payment flow itu "cuma" 30 detik per transaksi. Tapi 30 detik × 100 transaksi per hari × 30 hari = 1.500 menit per bulan = 25 jam. Improve payment flow 5 detik per transaksi = save 4 jam per bulan. Untuk kasir yang kerja 7 jam per hari, itu setengah shift yang "dikembalikan." Makanya kami obsesif soal setiap tap — karena di level aggregate, setiap detik benar-benar penting.