Aplikasi Kasir Android untuk Pembayaran Mobile Wallet

Mobile wallet membuat pelanggan dapat membayar tanpa uang tunai, tetapi pengalaman cepat di layar menyembunyikan alur teknis yang kompleks. Aplikasi Kasir Android harus menghubungkan order, payment request, provider reference, status, notifikasi, settlement, refund, dan bukti transaksi. Tanpa itu, timeout mudah berubah menjadi charge ganda atau order tanpa pembayaran.

Kasir tidak boleh menebak keberhasilan dari animasi pelanggan. Sumber keputusan adalah status resmi merchant melalui integrasi, aplikasi merchant yang sah, atau kanal verifikasi yang ditetapkan penyedia.

Pengguna mengakses antarmuka transaksi digital pada smartphone yang terhubung dengan aplikasi kasir Android untuk pembayaran mobile wallet

Jawaban singkat

Buat payment intent unik untuk setiap upaya, tampilkan merchant serta nominal yang benar, lalu tunggu status authoritative: created, pending, paid, failed, expired, cancelled, refunded, atau disputed. Proses callback secara idempotent dan lakukan lookup jika respons tidak pasti.

Jangan mengulang charge sebelum memeriksa reference lama. Rekonsiliasi POS dengan laporan penyedia dan bank setiap hari. Pisahkan keberhasilan pembayaran, penyelesaian order, dan settlement dana karena ketiganya dapat terjadi pada waktu berbeda.

Pahami aktor dan aliran dana

Pelanggan menggunakan wallet atau sumber dana, merchant memakai aplikasi/POS, penyedia jasa pembayaran memproses, dan bank menyelesaikan dana sesuai skema. Sistem menyimpan hubungan tiap reference.

Jangan memakai satu kolom “paid” untuk semua. Model status yang jelas memudahkan recovery dan audit.

Gunakan QR dan kanal resmi

Bank Indonesia menjelaskan QRIS sebagai standardisasi pembayaran menggunakan QR Code. Merchant perlu bekerja melalui penyedia yang sesuai, menampilkan identitas merchant, dan mengikuti ketentuan terbaru.

Dynamic QR lebih mudah mengikat nominal serta order daripada pelanggan mengetik nilai pada static QR. Jika static QR digunakan, verifikasi amount, merchant, waktu, dan reference melalui kanal merchant.

Jangan meminta pelanggan mengirim credential, OTP, atau PIN. Screenshot dapat membantu komunikasi tetapi bukan sumber final keberhasilan.

Buat payment intent secara idempotent

Saat checkout, POS membuat intent dengan order ID, amount, currency, expiry, location, device, dan idempotency key. Retry karena jaringan tidak boleh membuat charge baru untuk tindakan yang sama.

Alur normal:

1. Kunci total order dan rule version.

2. Buat payment intent unik.

3. Tampilkan QR atau deeplink resmi.

4. Terima callback dan verifikasi signature.

5. Lakukan lookup bila status belum pasti.

6. Tandai order paid tepat satu kali.

7. Terbitkan receipt setelah hasil valid.

Simpan request dan response secara aman dengan masking. Secret dan token tidak masuk log biasa.

Tangani pending dan timeout

Timeout berarti POS belum memperoleh jawaban, bukan otomatis gagal. Tampilkan “sedang diperiksa”, reference, serta tindakan kasir. Cegah tombol bayar ulang tanpa lookup.

Jika pelanggan melihat debit tetapi merchant masih pending, buat case dan verifikasi provider. Jangan menahan pelanggan tanpa penjelasan; berikan receipt pending atau reference serta jalur follow-up sesuai prosedur.

Late callback dapat datang setelah kasir membatalkan order. Sistem harus menentukan apakah menghidupkan kembali order, membuat refund, atau menaruhnya pada exception queue—bukan mengabaikannya.

Bedakan payment dan order state

Order dapat cancelled dengan payment paid, atau completed dengan payment kemudian disputed. State machine mengatur kombinasi dan tindakan.

Paid callback tidak boleh memposting order dua kali. Gunakan unique constraint pada provider reference serta idempotent consumer. Jika nominal berbeda, tahan pada exception.

Receipt menampilkan metode, waktu, amount, dan reference yang aman. Jangan menampilkan token atau data wallet penuh.

Rancang refund yang dapat ditelusuri

Refund mengacu ke payment asli, nilai, item atau alasan, approver, channel, dan provider refund reference. Partial refund harus didukung hanya bila provider serta policy memungkinkan.

Status requested tidak sama dengan settled. Berikan estimasi realistis kepada pelanggan dan cara mengecek. Reconcile refund dengan provider dan bank.

Void sebelum settlement dan refund setelah settlement dapat berbeda. UI perlu memakai istilah yang benar tanpa membebani kasir dengan detail teknis yang tidak diperlukan.

Siapkan offline dan gangguan jaringan

Pembayaran wallet umumnya membutuhkan komunikasi dengan penyedia. Jangan menampilkan seolah transaksi berhasil saat tidak dapat diverifikasi. Sediakan metode alternatif yang sah atau tahan order sesuai kebijakan.

Perangkat menyimpan queue terbatas untuk event non-secret dan melakukan lookup setelah koneksi pulih. POS tidak membuat QR dinamis baru berkali-kali tanpa membatalkan atau menandai intent lama.

Runbook memuat cek koneksi, status provider, lookup reference, pergantian kanal, komunikasi pelanggan, dan escalation. Latih saat toko tidak ramai.

Catat waktu mulai serta berakhirnya gangguan per lokasi. Setelah pulih, tinjau semua intent yang masih pending, cocokkan callback terlambat, dan hubungi pelanggan hanya melalui prosedur resmi bila tindakan lanjutan memang diperlukan.

Amankan perangkat Android

Gunakan perangkat terkelola, OS serta aplikasi didukung, screen lock, encryption, app pinning bila sesuai, least privilege, dan remote revocation. Jangan memasang APK dari sumber tidak terverifikasi.

API key disimpan melalui mekanisme aman, bukan hard-coded atau terlihat pada layar. Certificate validation, signed update, callback verification, dan environment separation perlu ditinjau teknis.

Rooted device, debugging, overlay berbahaya, atau accessibility abuse membutuhkan kebijakan risiko. Lost device memicu revocation token serta review log.

Batasi akses dan lindungi pelanggan

Kasir dapat memulai payment dan melihat status, tetapi refund atau konfigurasi provider memerlukan role lebih tinggi. Admin memakai autentikasi kuat serta audit.

Bank Indonesia menjelaskan cakupan pelindungan konsumen sistem pembayaran. Merchant tetap perlu menyediakan informasi, penanganan complaint, dan jalur penyelesaian sesuai peran serta ketentuan yang berlaku.

Jangan meminta screenshot yang menampilkan saldo atau data lain jika reference cukup. Evidence case mempunyai retensi dan akses terbatas.

Rekonsiliasi harian

Rekonsiliasi membandingkan order POS, provider transaction, settlement batch, bank credit, fee, tax, refund, chargeback, dan adjustment. Expected net dihitung dari transaksi settled sesuai skema.

Exception utama:

• POS paid tetapi provider tidak menemukan transaksi;

• provider paid tetapi order belum completed;

• amount atau merchant berbeda;

• duplicate reference;

• refund belum settled melewati tenggat;

• settlement kurang atau lebih;

• fee tidak sesuai konfigurasi.

Setiap exception mempunyai owner, aging, evidence, dan outcome. Jangan menutup selisih dengan jurnal umum tanpa diagnosis.

Optimalkan pengalaman checkout

Tampilkan nominal besar, merchant, expiry, dan status. Setelah pelanggan scan, status berubah tanpa meminta refresh berulang. Audio atau visual cue harus dapat diakses dan tidak membocorkan nilai berlebihan.

Sediakan jalur bantuan bagi pelanggan yang tidak dapat atau tidak ingin memakai wallet. Jangan menghalangi metode lain yang tersedia.

Gunakan artikel Kasair untuk skenario pembayaran dan evaluasi Kasair pada perangkat, provider, refund, offline, serta rekonsiliasi yang Anda perlukan.

KPI dan monitoring

Pantau initiation success, payment success per provider, pending rate, confirmation latency percentile, duplicate prevention, amount mismatch, late callback, refund aging, settlement difference, uptime, support case, dan recovery time.

Success rate tinggi tidak cukup bila confirmation lambat atau rekonsiliasi buruk. Segmentasikan per versi aplikasi, perangkat, lokasi, jaringan, provider, dan jam.

Alert harus actionable: siapa owner, transaksi terdampak, serta langkah aman. Hindari retry storm ketika provider bermasalah.

Implementasi bertahap

Mulai dari satu provider dan beberapa perangkat. Petakan state machine, contract API, secret, role, receipt, refund, closing, serta incident runbook. Gunakan sandbox lalu pilot nilai terbatas.

Uji callback ganda, response hilang, late success, nominal salah, QR expired, order cancelled, partial refund, settlement selisih, device hilang, dan koneksi putus. Perluas setelah finance dapat merekonsiliasi end-to-end tanpa manipulasi manual.

FAQ

Apakah screenshot cukup membuktikan pembayaran?

Tidak. Verifikasi melalui status resmi merchant atau penyedia menggunakan reference, amount, merchant, dan waktu.

Apa arti status pending?

Permintaan sudah ada tetapi hasil final belum dipastikan. Lakukan lookup; jangan langsung meminta pembayaran ulang.

Mengapa payment ID berbeda dari order ID?

Satu order dapat memiliki beberapa upaya pembayaran. ID terpisah menjaga jejak setiap intent dan provider transaction.

Apakah mobile wallet dapat dipakai saat offline?

Kemampuan bergantung skema dan penyedia. Merchant tidak boleh menganggap berhasil tanpa mekanisme verifikasi yang sah.

Bagaimana menangani refund?

Buat request yang merujuk transaksi asli, simpan approval dan reference, lalu pantau sampai settled serta direkonsiliasi.

KPI paling penting apa?

Gabungkan success, confirmation latency, pending, duplicate, refund aging, settlement difference, uptime, dan complaint.