Proses Pesanan Online dengan Aplikasi Kasir

Pesanan online melewati lebih banyak status daripada transaksi di meja kasir. Pelanggan melihat katalog, membuat keranjang, memilih alamat atau pickup, membayar, menunggu konfirmasi, menerima barang, lalu mungkin mengajukan pembatalan atau retur. Sistem Kasir perlu mempertahankan satu identitas order sepanjang alur tersebut agar uang, stok, dan fulfillment dapat direkonsiliasi.

Integrasi yang hanya menyalin total penjualan ke POS kehilangan item, diskon, pajak, biaya, sumber, dan status. Sebaliknya, sinkronisasi tanpa desain idempotensi dapat menggandakan order ketika jaringan timeout. Model data dan ownership harus disepakati sebelum kanal online dibuka.

Jawaban singkat

Tentukan sumber kebenaran untuk produk, harga, stok, order, pembayaran, shipment, dan pelanggan. Gunakan order ID serta idempotency key yang unik, simpan status sebagai event, lalu proses retry secara aman.

Pisahkan order placed, payment authorized, paid, allocated, picked, shipped, completed, canceled, returned, dan refunded. Setiap perubahan menyimpan waktu, actor, channel, reason, serta nilai sebelum-sesudah.

Sinkronkan katalog tanpa kehilangan konteks

Produk online membutuhkan nama, deskripsi, gambar, kategori, varian, SKU, harga, pajak, berat, dimensi, dan availability. POS atau product information system dapat menjadi sumber, tetapi aturan publish perlu jelas.

Jangan menghubungkan produk hanya dari nama. Gunakan SKU atau mapping ID yang stabil. Ketika varian dinonaktifkan, tentukan apakah order lama tetap dapat dibaca dan diretur. Harga mempunyai tanggal efektif serta kanal bila berbeda.

Kelola stok dan reservasi

Saldo on hand bukan selalu available-to-sell. Kurangi stok rusak, karantina, reserved, safety stock, dan alokasi kanal sesuai kebijakan. Tetapkan kapan reservasi dibuat: saat add-to-cart, checkout, payment pending, atau paid.

Reservasi memiliki masa berlaku. Jika pembayaran gagal atau timeout, stok dilepas berdasarkan aturan. Untuk transfer antar lokasi atau ship-from-store, sistem harus melihat kapasitas picking dan cutoff selain jumlah barang.

Uji dua pelanggan membeli unit terakhir, pembayaran masuk terlambat, order dibatalkan setelah picking, serta stok fisik ternyata kurang. Exception perlu antrean dan pemilik, bukan diselesaikan diam-diam.

Jadikan checkout kontrak data

Checkout mengumpulkan item, kuantitas, price snapshot, diskon, pajak, ongkir, alamat, metode fulfillment, kontak, dan consent. Setelah order dibuat, simpan snapshot agar perubahan katalog tidak mengubah histori.

Validasi sisi server terhadap harga, stok, promo, batas pembelian, dan area layanan. Jangan mempercayai nilai yang dikirim browser. Pesan error harus membantu pelanggan memperbaiki input tanpa membuka detail keamanan.

Data minimum yang dibutuhkan:

1. order ID dan channel;
2. line item serta snapshot harga;
3. diskon dan promotion ID;
4. pajak dan biaya;
5. fulfillment method serta alamat yang perlu;
6. contact serta consent;
7. payment attempt reference;
8. timestamp dan status history.

Cegah duplikasi dengan idempotensi

Timeout membuat aplikasi tidak tahu apakah permintaan berhasil. Jika tombol bayar ditekan lagi atau webhook dikirim ulang, sistem harus mengenali request yang sama. Idempotency key mengizinkan pengulangan tanpa membuat efek ganda.

Transaction ID juga penting untuk analitik. Dokumentasi Google Analytics tentang transaction ID menjelaskan penggunaannya untuk mengurangi duplikasi event purchase pada web stream dan memproses refund. ID analitik harus berasal dari order yang valid, bukan nomor acak baru setiap page refresh.

Deduplication diterapkan pada order, payment, inventory movement, loyalty earning, coupon redemption, dan notification bila perlu. Simpan payload hash, response, serta masa retensi key sesuai risiko.

Orkestrasi pembayaran dan webhook

Pisahkan payment intent, authorization, capture, settlement, refund, reversal, dan dispute. Status order tidak boleh dianggap paid hanya karena pelanggan kembali ke halaman sukses; gunakan konfirmasi server atau mekanisme provider yang disepakati.

Webhook diverifikasi tanda tangannya, diproses idempotent, dan boleh datang tidak berurutan. Simpan event mentah secara aman, hasil proses, error, retry, serta correlation ID. Manual review dibutuhkan ketika nilai atau mata uang tidak cocok.

Rekonsiliasi membandingkan order, payment ledger, provider transaction, fee, settlement, refund, dan transfer bank. Selisih memiliki kategori serta owner.

Atur fulfillment berdasarkan kapasitas

Setelah paid atau syarat lain terpenuhi, order dialokasikan ke lokasi. Picking memakai daftar, barcode bila tersedia, dan quantity confirmation. Packing mencatat paket, berat, dokumen, serta kondisi. Shipment menyimpan carrier dan tracking.

Pickup order memerlukan ready notification, identitas atau kode pengambilan, waktu, serta bukti serah. Delivery internal membutuhkan assignment, status, proof, dan exception. Jangan menandai completed sebelum kriteria penyerahan dipenuhi.

Metrik operasi meliputi:

• order-to-confirm time;
• payment pending age;
• allocation success;
• pick and pack duration;
• on-time handoff;
• delivery exception;
• cancellation by reason;
• return and refund cycle time;
• inventory mismatch;
• manual intervention rate.

Tangani pembatalan, retur, dan refund

Kebijakan bergantung pada tahap. Sebelum alokasi, order mungkin mudah dibatalkan. Setelah dikirim, proses berubah menjadi retur. Setelah layanan atau produk custom diproses, aturan dapat berbeda dan harus diinformasikan sebelum checkout.

Retur merujuk order dan line item asli. Catat alasan, kondisi, quantity, bukti, hasil inspeksi, disposition, serta resolution. Barang tidak otomatis kembali tersedia sebelum lolos inspeksi.

Refund memakai payment reference dan nilai yang dapat direkonsiliasi. Partial refund menyebut item serta biaya. Jangan mengubah transaksi awal tanpa dokumen pembalik dan audit trail.

Lindungi pelanggan dan kanal

Terapkan autentikasi, rate limiting, validasi input, secret management, akses berbasis peran, logging, backup, dan respons insiden. Pisahkan akun pelanggan dari hak administratif. Batasi data alamat serta kontak pada pihak yang memerlukan fulfillment.

Fraud control menilai sinyal seperti velocity, mismatch, penggunaan promo, alamat, perangkat, atau pola pembayaran secara proporsional. Hasil otomatis sebaiknya dapat ditinjau pada kasus yang berdampak besar. Jangan menolak pelanggan hanya karena satu indikator lemah.

Perjelas harga, ketersediaan, metode pengiriman, estimasi, kebijakan pembatalan, retur, serta privasi. Catat versi syarat yang diterima pelanggan.

Bangun observabilitas dan rekonsiliasi

Dashboard teknis memantau API error, latency, webhook queue, retry, conflict, dan integration lag. Dashboard bisnis memantau order funnel, pembayaran, fulfillment, refund, stok, serta settlement. Keduanya terhubung melalui correlation ID.

Rekonsiliasi harian mencakup:

1. order di kanal dan POS;
2. nilai item, diskon, pajak, serta ongkir;
3. payment success, failed, pending, dan refunded;
4. inventory reservation serta movement;
5. shipment dan completion;
6. coupon serta loyalty entry;
7. settlement dan fee;
8. exception yang belum selesai.

Rilis kanal secara bertahap

Mulai dari katalog, wilayah, metode bayar, dan fulfillment yang terbatas. Tetapkan volume maksimum serta petugas yang memantau exception. Jalankan smoke test setelah setiap perubahan konfigurasi dan hentikan ekspansi bila rekonsiliasi belum stabil.

Sebelum memperluas, ukur error checkout, payment pending, overselling, keterlambatan, refund, dan beban intervensi manual. Review komentar pelanggan bersama data operasional karena keluhan “pesanan lambat” dapat berasal dari stok, picking, carrier, atau komunikasi status. Perluas hanya setelah akar masalah dipahami dan kapasitas tim mencukupi.

Gunakan pusat artikel Kasair untuk memperluas SOP omnichannel. Uji integrasi Kasair menggunakan sandbox dan order end-to-end sebelum membuka kanal untuk seluruh pelanggan.

FAQ

Apa perbedaan order ID dan payment ID?

Order ID mewakili pesanan, sedangkan payment ID mewakili satu upaya atau transaksi pembayaran. Satu order dapat memiliki beberapa payment attempt, tetapi hubungan semuanya harus jelas.

Kapan stok sebaiknya direservasi?

Tergantung kelangkaan, durasi pembayaran, dan risiko overselling. Pilih event yang jelas, tetapkan expiry, lalu uji pembayaran terlambat serta pembatalan.

Mengapa webhook dapat datang dua kali?

Provider biasanya melakukan retry ketika tidak menerima acknowledgment. Sistem penerima harus idempotent sehingga event ulang tidak menggandakan pembayaran atau status.

Apakah halaman sukses membuktikan pembayaran berhasil?

Tidak selalu. Status harus diverifikasi melalui konfirmasi server atau inquiry provider sesuai protokol. Browser pelanggan dapat ditutup, diubah, atau gagal kembali.

Bagaimana memproses partial refund?

Hubungkan refund ke payment dan line item, tentukan komponen yang dikembalikan, buat dokumen koreksi, perbarui stok sesuai inspeksi, lalu rekonsiliasi settlement.

Apa tanda integrasi order bermasalah?

Tandanya order ganda, status melompat, pembayaran tidak teralokasi, stok negatif, shipment tanpa order, refund tanpa transaksi asal, atau banyak koreksi manual tanpa alasan.