Senario yang setiap seller takut
Customer WhatsApp anda: "Saya dah bayar tadi. Dah ada receipt. Tapi tak dapat confirmation."
Anda buka dashboard. Tiada order. Anda check payment gateway — ada transaction. Tapi order tidak wujud dalam sistem.
Anda kini ada dua pilihan yang sama buruknya:
- Proses order secara manual berdasarkan kepercayaan — risiko anda kena tipu jika payment sebenarnya gagal
- Tanya customer untuk bayar semula — mereka rasa kena double charge, trust rosak
Ini bukan masalah teknikal semata-mata. Ini adalah krisis kepercayaan yang berlaku dalam masa beberapa minit.
Kenapa ini berlaku
Ada beberapa sebab, dan setiap satu reflect masalah berbeza dalam cara checkout direka.
1. Race condition antara payment dan order creation
Cara checkout yang naif: (1) customer bayar, (2) payment gateway confirm, (3) sistem cipta order.
Masalah: ada masa di antara langkah 2 dan 3. Kalau sambungan internet pelanggan putus selepas payment diproses tapi sebelum server dapat signal — webhook tidak sampai, order tidak dicipta. Payment ada. Order tidak ada.
Customer nampak bayaran keluar dari bank. Anda tidak nampak order.
2. Double-submit yang cipta kekeliruan
Customer internet slow. Tekan butang checkout. Tunggu. Fikir gagal. Tekan lagi.
Tanpa perlindungan, anda kini ada dua order untuk satu payment. Atau lebih teruk — satu payment, dua order yang diproses, dan stok dikurangkan dua kali.
Bila order kedua dicancel (manual atau auto), customer nampak status "cancelled" dan panik.
3. Browser yang tutup terlalu awal
Untuk payment gateway seperti CHIP, flow adalah: (1) cipta checkout session, (2) redirect customer ke halaman bank/FPX/kad, (3) customer bayar, (4) gateway redirect balik ke storefront dengan confirmation.
Kalau customer tutup browser selepas bayar tapi sebelum redirect selesai — gateway tahu payment berjaya, tapi storefront tidak dapat signal. Order stuck dalam "awaiting payment" selama-lamanya.
4. Stok yang oversell
Ini berbeza sikit. Dua customer order produk yang sama secara serentak. Kedua-duanya berjaya bayar. Stok hanya satu unit. Anda kini kena pilih siapa yang dapat.
Pelanggan yang tidak dapat akan minta refund. Tapi proses refund memakan masa. Dalam jangka masa itu, customer itu rasa kena tipu.
Apa yang patut berlaku (dan apa yang ARAS buat)
Semua masalah di atas boleh diselesaikan — tapi anda perlu sistem checkout yang direka dengan betul dari awal.
Untuk race condition payment-order: Order perlu dicipta dan payment perlu disinkronkan melalui backend webhook — bukan melalui browser redirect semata-mata. Apabila payment gateway confirm bayaran (melalui server-to-server webhook), backend cipta atau kemaskini order secara server-side. Browser hanya paparkan hasil. Kalau webhook gagal sampai, ada retry mechanism.
Untuk double-submit: Setiap checkout request mesti dikenal pasti secara unik. Kalau request yang sama dihantar dua kali, sistem kenal pasti ia sebagai order yang sama — bukan cipta order baharu. Pelanggan tekan dua kali? Satu order sahaja.
Untuk browser yang tutup awal: Order perlu wujud sebelum redirect ke payment gateway — bukan selepas. Order dicipta dengan status "menunggu pembayaran". Bila payment berjaya, backend kemaskini status secara automatik melalui webhook — tanpa perlu browser pelanggan ada. Kalau pelanggan tutup browser, order masih ada dalam sistem dengan status yang betul.
Untuk overselling: Pengesahan order dan pengurangan stok mesti berlaku serentak — dalam satu operasi yang tidak boleh dipecahkan. Sama ada kedua-duanya berjaya, atau kedua-duanya gagal. Tiada celah di antara dua tindakan ini.
Apa yang merchant patut tanya vendor storefront mereka
Empat soalan mudah:
"Bila tepat order dicipta dalam sistem anda?" Kalau jawapan adalah "selepas payment confirmation" — tanya bagaimana mereka handle payment yang confirm tapi redirect yang gagal.
"Ada idempotency protection untuk double-submit?" Kalau mereka tidak faham soalan ini — itu jawapan.
"Stok dikurangkan dalam transaction yang sama dengan order creation?" Kalau tidak — anda terdedah kepada overselling dalam situasi ramai orang order serentak.
"Kalau CHIP/FPX checkout payment berjaya tapi customer tidak redirect balik — order ada dalam sistem?" Kalau tidak — anda akan dapat case "customer dah bayar tapi order tak masuk" setiap kali ada sambungan internet yang lemah.
Bila perkara ini berlaku kepada anda sekarang
Kalau anda dah ada case "customer bayar, order tak masuk" — ini langkah yang practical:
- Verify dengan gateway dulu. Masuk ke dashboard payment gateway, cari transaction ID dari receipt customer. Confirm sama ada payment benar-benar berjaya atau hanya pending/failed yang nampak macam success kat customer.
- Kalau payment confirmed dan tiada order — cipta order manual segera. Jangan tunggu sistem. Customer itu telah bayar. Proses order mereka. Nota dalam order: "created manually — payment confirmed via [gateway] transaction [ID]".
- Notify customer terus selepas resolve. Jangan biar mereka dalam keadaan tidak tahu. Satu mesej pendek: "Order anda dah disahkan. Kami proses sekarang." Cukup.
- Log incident untuk review sistem anda. Kalau ini berlaku lebih dari sekali — bukan bad luck, ini masalah sistem.
Kepercayaan yang sukar dibina semula
Customer yang ada pengalaman "dah bayar tapi tak dapat confirmation" adalah customer yang cenderung tidak akan repeat purchase. Bukan sebab produk tidak bagus. Sebab pengalaman bayar rasa tidak selamat.
Di Malaysia, dengan penetrasi e-dagang yang masih membesar dan ramai first-time online buyer — pengalaman pertama customer dengan checkout anda adalah sangat penting. Kalau ia mulus dan confirm cepat, mereka percaya platform anda. Kalau ia confusion dan ketidakpastian — mereka beralih ke marketplace yang familiar.
Ini bukan feature yang anda boleh lihat dalam screenshot. Tapi ia adalah asas yang menentukan sama ada customer akan beli dari anda lagi.