Anatomi transaksi gagal
Kebanyakan transaksi yang “gagal” sebenarnya tidak gagal. Empat panggilan di balik satu ketukan, mengapa transaksi gagal, referensi yang menjaga satu ketukan tetap satu pembelian, dan arti sebenarnya “pending”.
Diagram menunjukkan praktik yang lazim dari pengalaman saya sendiri, disederhanakan. Bukan proses internal perusahaan mana pun.
Kebanyakan transaksi yang "gagal" sebenarnya tidak gagal
Dalam rantai produk digital, "gagal" hanyalah satu dari beberapa hasil, dan sering bukan yang pertama. Apa yang dilihat pelanggan sebagai galat bisa berupa penolakan, penundaan, atau pembelian yang sebenarnya sudah berhasil.
- Berhasil
Status akhir menyatakan produk terkirim.
- Gagal
Jawaban yang jelas menyatakan ditolak.
- Belum ada jawaban
Yang sulit. Belum gagal, belum berhasil.
Baca bagian lengkap
Pelanggan melihat satu hasil di satu layar. Di belakangnya, platform sedang bercakap singkat dengan tingkat di atasnya, dan percakapan itu bisa berakhir dengan tiga cara: berhasil, gagal, atau belum ada jawaban.
Yang ketiga adalah yang sulit. Sebagian besar keahlian dalam menjalankan platform PPOB ada pada cara menanganinya.
Empat panggilan, bukan satu
Satu pembelian terdiri dari hingga empat panggilan, bukan satu: inquiry, payment, response (callback), dan, ketika ada yang tidak beres di tengah jalan, advice.
Inquiry tidak diperlukan untuk semua produk.
Baca bagian lengkap
*Inquiry* memeriksa rincian sebelum ada uang yang bergerak. Untuk tagihan, ia memastikan jumlah yang harus dibayar. Untuk banyak produk prabayar, ia tidak diperlukan.
*Payment mengirim pesanan. Response*, yang sering datang sebagai callback, membawa status akhir, kadang langsung dan kadang belakangan.
*Advice* dipakai ketika jawaban tidak datang, misalnya setelah timeout. Alih-alih menebak, platform bertanya lagi tentang status transaksi yang sama.
Mengapa transaksi gagal
Penyebab yang lazim adalah timeout, provider yang sedang down, nomor tujuan yang salah, dan saldo yang tidak cukup. Di layar semuanya bisa tampak mirip, tetapi akhirnya tidak sama.
Pilih satu penyebab untuk melihat apa yang dilihat sistem dan apa yang terjadi berikutnya.
- Yang dilihat sistem
- Jawaban yang jelas: tujuan tidak valid.
- Status
- Gagal, langsung
- Uang
- Tidak ada yang bergerak.
- Yang terjadi berikutnya
- Pelanggan memperbaiki nomor lalu mencoba lagi.
Baca bagian lengkap
Sebagian penyebab menghasilkan jawaban yang jelas. Nomor tujuan yang salah atau saldo yang tidak cukup ditolak, dan transaksi langsung gagal. Tidak ada yang perlu diselidiki.
Penyebab lain menghasilkan keheningan. Timeout, atau provider yang tidak menjawab, membuat platform tanpa status akhir. Itu sebabnya "pending" ada, dan mengapa ia tidak sama dengan kegagalan.
Pilih satu penyebab di bawah untuk melihat apa yang dilihat sistem dan apa yang terjadi berikutnya. Ini gambaran sederhana dari praktik yang lazim.
Satu referensi untuk setiap permintaan
Setiap permintaan membawa transaction_id yang unik, dipakai di transaksi digital dan PPOB. Dengan itu sebuah pengulangan dikenali, dan antar tingkat bisa mencocokkan catatannya sesudahnya.
Baca bagian lengkap
Saya menjaganya pada tingkat gagasan. Pelanggan yang mengetuk dua kali, atau platform yang bertanya lagi setelah timeout, mengirim permintaan yang merujuk pada transaksi yang sama. Dengan referensi, ia dikenali sebagai pengulangan, bukan diproses sebagai pembelian kedua.
Referensi yang sama dipakai antar tingkat untuk mencocokkan catatan saat rekonsiliasi.
Pending, mencurigakan, direkonsiliasi
Pending bukan gagal. Setelah sekitar satu jam transaksi pending dianggap mencurigakan, dan antar tingkat merekonsiliasi, secara otomatis dan manual, paling lama dalam sehari.
Baca bagian lengkap
Rekonsiliasi sebagian besar otomatis: antar tingkat membandingkan catatan dan menyelesaikan yang cocok. Yang tidak bisa diselesaikan otomatisasi direkonsiliasi secara manual. Menurut pengalaman saya ini selesai paling lama dalam sehari.
Provider juga memiliki jendela pemeliharaan, dan ini berlaku untuk semua jenis produk. Keterlambatan di dalamnya bisa tampak seperti kegagalan padahal bukan.
Platform dan sisi deposit berjalan 24 jam. Pengecualiannya adalah jam cut-off yang ditetapkan masing-masing provider.
Kesalahan pemain baru
Kesalahan yang paling sering saya lihat lebih tentang kesabaran, disiplin, dan kehadiran daripada tentang teknologi.
- Tidak sabar
- Serakah
- Pemahaman teknologi yang tipis
- Mengabaikan regulasi
- Perang harga sejak hari pertama
- Tanpa komunitas atau kehadiran pasar
Baca bagian lengkap
Pemain baru sering tidak sabar dan serakah. Pemahaman teknologinya tipis, mereka mengabaikan regulasi, memulai perang harga sejak hari pertama, dan tidak membangun komunitas atau kehadiran pasar di wilayahnya sendiri.
Disiplin yang sama berlaku untuk siapa yang boleh masuk ke rantai. Merchant diperiksa secara online dengan eKYC, atau secara manual dengan KYC atau KYB. Upaya penipuan yang paling sering saya lihat adalah pemakaian dokumen orang lain dan rekayasa sosial.
Yang bisa dibawa pulang
Rancang untuk keadaan yang belum diketahui, beri setiap permintaan sebuah referensi, dan rekonsiliasi setiap hari.
Baca bagian lengkap
Kalau Anda membangun produknya, perlakukan "sedang diproses" sebagai status yang nyata dan tampilkan dengan jujur. Pelanggan yang tahu transaksinya masih diproses tidak akan membayar dua kali.
Kalau Anda menjalankan operasional, simpan referensi unik untuk setiap permintaan, perlakukan pending sebagai status kelas satu, dan rekonsiliasi setiap hari.
Sumber dan catatan
Praktik yang lazim dari pengalaman saya, bukan proses internal perusahaan mana pun. Simulator adalah ilustrasi yang disederhanakan.
- Contoh publik yang terkait: dokumentasi API PPOB Snapcart mengklasifikasikan timeout sebagai status sedang berjalan dan memakai callback serta polling.
- Rantai lengkapnya, tingkat demi tingkat, ada di penjelasan mendalam.