Sistem Kasir untuk Pembayaran Digital yang Rapi

Pembayaran digital terlihat sederhana saat pelanggan memindai atau menekan tombol bayar, tetapi di belakangnya terdapat permintaan, otorisasi, notifikasi, settlement, refund, dan kemungkinan dispute. Sistem Kasir harus membedakan semua tahap itu agar status order tidak disimpulkan hanya dari satu layar atau bukti pelanggan.

Desain yang lemah biasanya tampak ketika jaringan timeout: kasir tidak tahu apakah harus mengulang, pelanggan mungkin sudah terdebit, dan laporan menunjukkan order belum lunas. Solusinya adalah payment ledger, identifier unik, idempotensi, inquiry, serta rekonsiliasi—bukan menambahkan screenshot sebagai satu-satunya bukti.

Jawaban singkat

Pisahkan order ID, payment attempt ID, provider transaction ID, settlement ID, refund ID, dan dispute ID. Simpan amount, currency, method, status, timestamp, channel, provider, serta hubungan antarobjek.

Terima status sukses dari integrasi server yang terverifikasi atau inquiry provider. Proses webhook secara idempotent, tampilkan transaksi pending, lalu cocokkan payment ledger dengan settlement serta rekening bank secara berkala.

Modelkan lifecycle pembayaran

Status perlu mengikuti kemampuan metode, tetapi set minimum dapat berupa created, initiated, authorized, captured atau paid, pending, failed, expired, reversed, partially refunded, refunded, dan disputed. Jangan mengubah paid menjadi failed hanya karena callback terlambat.

Payment attempt berbeda dari order. Satu order dapat memiliki beberapa attempt ketika metode pertama gagal. Hanya attempt valid yang dialokasikan ke saldo, sementara seluruh histori dipertahankan.

Gunakan idempotensi dan correlation ID

Jaringan dapat mengirim request atau webhook berulang. Idempotency key memastikan pengulangan yang sama menghasilkan efek sama, bukan charge baru. Key memiliki scope, payload hash, hasil, dan masa retensi.

Correlation ID mengikuti perjalanan request dari POS ke payment service, provider, webhook, dan ledger. Tim support dapat menelusuri kegagalan tanpa mencari berdasarkan nama pelanggan atau screenshot.

Terapkan deduplication pada create payment, capture, refund, loyalty, receipt, serta inventory movement yang dipicu status pembayaran. Uji klik ganda, timeout, retry otomatis, callback terlambat, dan event tidak berurutan.

Integrasikan QRIS dengan pemahaman yang tepat

QRIS merupakan standar pembayaran QR nasional, sementara layanan merchant diberikan melalui penyelenggara terkait. Bank Indonesia memuat pembaruan implementasi pada PADG Nomor 3 Tahun 2025. Bisnis perlu memeriksa ketentuan, model, limit, dan proses yang berlaku pada penyelenggaranya.

Static QR membutuhkan input nominal atau matching berbeda dari dynamic QR yang membawa detail transaksi. Sistem harus mengikat payment reference ke order, mencegah penggunaan notifikasi transaksi lain, dan menangani expiry.

Jangan menyatakan transaksi sukses hanya karena pelanggan menunjukkan halaman aplikasi. Lakukan verifikasi melalui kanal merchant atau integrasi yang disepakati. Bukti pelanggan membantu investigasi tetapi bukan pengganti ledger provider.

Verifikasi webhook dan inquiry

Endpoint webhook menggunakan TLS, signature verification, timestamp atau nonce bila tersedia, schema validation, rate limit, dan logging aman. Balas acknowledgement setelah event diterima secara andal, lalu proses asynchronous jika desain mengharuskan.

Event dapat dikirim ulang atau datang tidak berurutan. State machine menentukan transisi yang valid. Event invalid masuk exception dan tidak langsung menimpa status final.

Inquiry digunakan saat status ambigu, callback hilang, atau pelanggan melaporkan debit. Batasi frekuensi dan simpan hasil. Manual override hanya dilakukan oleh peran berwenang dengan alasan serta bukti.

Pisahkan payment dan settlement

Payment success berarti pelanggan menyelesaikan pembayaran menurut provider. Settlement adalah dana net yang disalurkan ke merchant sesuai jadwal, setelah fee, adjustment, atau komponen lain. Keduanya terjadi pada waktu berbeda.

Rekonsiliasi tiga arah membandingkan POS payment ledger, laporan provider, dan mutasi bank. Gunakan transaction ID, amount, date, method, serta settlement reference. Perbedaan dikelompokkan menjadi timing, missing, duplicate, fee, refund, reversal, atau unknown.

Checklist rekonsiliasi:

1. total sukses menurut metode;

2. transaksi pending berdasarkan umur;

3. provider transaction yang tidak ada di POS;

4. POS paid tanpa transaksi provider;

5. settlement gross, fee, dan net;

6. refund serta reversal;

7. chargeback atau dispute;

8. transfer bank dan exception terbuka.

Kelola refund dan reversal

Refund selalu merujuk payment awal. Simpan alasan, item, amount, requester, approver, provider reference, status, dan settlement. Partial refund tidak boleh melampaui saldo refundable.

Reversal dapat terjadi otomatis ketika otorisasi atau transaksi dibatalkan sesuai metode. Jangan menyebut setiap reversal sebagai refund; implikasi proses dan waktu bisa berbeda. UI harus menjelaskan status kepada staf tanpa membuat janji waktu yang tidak dikuasai bisnis.

Bulk refund membutuhkan file atau job berversi, dry run, approval, idempotency, progress, error report, dan rekonsiliasi. Jangan menjalankan batch yang sama dua kali karena job tampak timeout.

Cegah fraud dan social engineering

Risiko mencakup bukti bayar palsu, penggantian rekening refund, account takeover, refund tanpa transaksi, kolusi staf, dan credential theft. Terapkan least privilege, MFA untuk peran sensitif, velocity limit, maker-checker, serta alert.

Perubahan rekening merchant atau konfigurasi provider memerlukan verifikasi out-of-band. Support tidak boleh meminta OTP atau secret pelanggan. Data kartu tidak dicatat di notes atau receipt.

Fraud rule menghasilkan sinyal, bukan selalu keputusan final. Review kasus bernilai tinggi dan ukur false positive agar kontrol tidak menolak pelanggan sah secara berlebihan.

Bangun UX kasir untuk status ambigu

Layar pembayaran menampilkan amount, method, attempt, timer, dan status. Tombol retry dinonaktifkan sampai sistem tahu aman. Jika pending, kasir mendapat instruksi inquiry atau eskalasi, bukan pesan generik.

Receipt hanya diterbitkan sebagai paid ketika kriteria terpenuhi. Untuk status pending, berikan reference dan kanal bantuan bila kebijakan memungkinkan. Jangan membuat order baru untuk “mencoba lagi” tanpa menutup hubungan dengan attempt lama.

Supervisor dashboard menunjukkan pending, mismatch, duplicate risk, refund, dan settlement exception. Setiap item memiliki next action serta owner.

Uji kegagalan sebelum go-live

Gunakan sandbox serta nominal uji sesuai ketentuan provider. Simulasikan sukses, ditolak, timeout sebelum dan sesudah provider menerima, webhook berulang, signature salah, callback terlambat, partial refund, reversal, dispute, dan settlement mismatch.

Uji perangkat restart, jaringan berpindah, jam salah, dan closing saat event belum selesai. Pastikan transaksi tidak hilang dan tidak ganda. Dokumentasikan expected state pada POS, provider, inventory, receipt, serta ledger.

Pantau kualitas pembayaran

Metrik yang sehat meliputi authorization success, completion, pending age, inquiry volume, duplicate prevention, webhook lag, refund cycle, dispute, settlement exception, dan manual override. Segmentasikan berdasarkan metode, provider, outlet, perangkat, versi, dan waktu.

Kenaikan failure tidak selalu berasal dari provider; periksa jaringan, konfigurasi, versi aplikasi, atau input pengguna. Sediakan runbook dan escalation matrix.

Runbook insiden harus menetapkan siapa yang menghentikan metode pembayaran, siapa yang menghubungi penyelenggara, bagaimana kasir memberi informasi kepada pelanggan, dan kapan metode dapat diaktifkan kembali. Catat awal gangguan, transaksi terdampak, tindakan, keputusan, serta hasil rekonsiliasi. Setelah insiden, lakukan review akar masalah dan perbarui alert, prosedur, atau desain integrasi agar pola yang sama tidak berulang. Hindari menghapus log sebelum semua transaksi ambigu memperoleh status final.

Gunakan artikel Kasair untuk memperluas kontrol transaksi. Uji alur pembayaran Kasair end-to-end dengan penyelenggara yang digunakan sebelum aktivasi penuh.

FAQ

Apakah bukti transfer pelanggan cukup?

Tidak sebagai satu-satunya bukti. Cocokkan melalui rekening, provider, atau kanal merchant yang sah. Screenshot dapat membantu investigasi tetapi dapat keliru atau dimanipulasi.

Apa yang dilakukan ketika pelanggan terdebit tetapi POS pending?

Simpan reference, lakukan inquiry, jangan retry buta, dan eskalasi sesuai SLA. Setelah status resmi diketahui, alokasikan payment atau proses penyelesaian yang tepat.

Mengapa settlement lebih kecil dari penjualan?

Kemungkinan ada fee, refund, adjustment, timing, atau transaksi belum masuk batch. Gunakan detail provider dan mutasi bank untuk menjelaskan perbedaan.

Apa perbedaan refund dan reversal?

Refund adalah pengembalian dari pembayaran yang telah diproses, sedangkan reversal membatalkan atau membalik transaksi pada tahap tertentu. Definisi teknis mengikuti metode serta provider.

Bagaimana mencegah pembayaran ganda?

Gunakan idempotency key, lock atau state machine, inquiry sebelum retry, deduplication webhook, dan rekonsiliasi. UI juga perlu mencegah klik berulang.

Kapan payment ledger dianggap lengkap?

Ketika semua attempt, perubahan status, provider reference, settlement, refund, dispute, actor, dan timestamp dapat ditelusuri ke order serta sumber eksternal.