PayStory: Tidak Ada Respon / Timeout TIDAK SAMA DENGAN Gagal
Holaaa, sudah lama tidak menulis artikel terkait Payment, sudah banyak hal yang baru dan berubah. Contohnya seperti QRIS, sudah ada beberapa inisiatif baru seperti Cross Border dan Tarik Setor. Tapi kali ini saya ingin membahas tentang penanganan proses API di system Payment yang hanya saja kadang dari implementasinya masih salah penerapannya secara baik dan benar.
Bahasannya adalah mengenai penanganan proses timeout atau tidak mendapatkan respon dari suatu proses API. Mungkin dari tim dev lebih paham mengenai masalah ini, tapi saya coba membahasnya karena seringkali berdiskusi mengenai hal ini ketika akan mendesain suatu proses di produk. Proses API disini lebih ke proses insert atau update. Untuk proses get data pembahasan di bawah tidak terlalu relevan karena kalaupun get data gagal, ya tinggal get ulang lagi aja.
Proses API disini lebih ke proses insert atau update, untuk proses get data pembahasan di bawah tidak terlalu relevan karena kalaupun get data gagal, ya tinggal get ulang lagi aja.
Begini penjelasannya amigos, kita coba lihat sebuah skenario sederhana dari suatu API request.
Dari proses sederhana ini, ketika kita mengirimkan request kita akan mendapatkan response dari tujuan yang biasanya menginformasikan bahwa pesan sukses diproses.
Nahh, yang jadi masalah adalah ketika di sumber tidak mendapatkan respon apapun dari tujuan (timeout). Yang dimaksud tidak mendapat respon disini adalah secara koneksi berhasil, pengiriman data request juga sudah dilakukan tetapi tidak ada respon balasan dari tujuan.
Kesalahan umum yang sering dilakukan untuk menangani masalah ini biasanya dengan mengasumsikan bahwa tidak mendapat respon itu adalah sama dengan gagal proses.
Kesalahan umum yang sering dilakukan adalah mengasumsikan bahwa tidak mendapat respon itu adalah sama dengan gagal proses
Untuk suatu proses dimana ada 1 ID unik yang sama akan ditolak jika dikirim lagi atau proses dimana redundan data tidak dipermasalahkan, mungkin hal ini tidak menjadi masalah besar. Tetapi jika kita menggunakan system yang setiap menerima request dianggap suatu proses baru atau ada kaitan dengan proses apapun yang berhubungan dengan finansial, hal ini akan menjadi masalah besar.
Kenapa hal ini menjadi issue? Karena kita tidak tahu apakah data yang kita kirimkan itu sudah diproses di tujuan atau belum. Lihat di diagram berikut.
Dari 2 diagram di atas, keduanya tidak akan memberikan respon dari proses. Tapi perbedaannya, di gambar 1 di tujuan berhasil memproses data, sedangkan di gambar 2 untuk data dari sumber bahkan tidak sampai ke tujuan.
Artinya kita sebenarnya tidak tahu dari proses yang tidak memberikan respon apakah sebenarnya data berhasil diproses di tujuan, dan jikapun berhasil diproses, kita tidak tahu apakah hasilnya sukses atau gagal.
Apa saja yang mungkin terjadi kalau tidak ada response (timeout) disamakan dengan kegagalan?
- Jika prosesnya adalah proses pembayaran, yang kemungkinan bisa terjadi adalah ada dobel pembayaran karena user mendapat info transaksi pertama gagal.
- Jika prosesnya adalah transfer uang, yang kemungkinan bisa terjadi adalah ada dobel transfer karena user mendapat info transfer pertama gagal.
- Jika prosesnya adalah proses membuat data, maka kemungkinan yang terjadi adalah terjadi dobel data karena user mendapat informasi pembuatan data pertama gagal.
- Jika prosesnya dianggap gagal dan ada dana yang dikembalikan padahal sebenarnya sukses, yang terjadi user menerima item pembelian tapi uang kembali.
Intinya akan ada kemungkinan dobel data jika kita menggunakan asumsi timeout adalah gagal apalagi jika proses gagal itu diinformasikan langsung ke end user.
Terus bagaimana dong cara penanganan yang benar?
Banyak jalan menuju Bakso Lobster dan banyak cara untuk menangani proses timeout. Ada yang menggunakan proses cek status ketika tidak mendapatkan respon, ada yang mengirimkan request reversal ketika tidak mendapatkan respon, ada juga yang menggunakan ID unik untuk setiap request dan memastikan jika ID yang sama dikirimkan lagi maka proses akan ditolak, dan masih banyak lagi cara yang bisa digunakan.
Ok, that’s all folks, hanya sedikit pembahasan untuk masalah timeout ini, yang penting bisa mengetahui bahwa jika mendapatkan timeout atau tidak ada respon ketika mengirimkan request API, jangan mengasumsikan bahwa proses itu gagal. Bahkan berasumsi di suatu proses kritikal bisa berbahaya, bisa dibaca di artikel ini yang sudah saya posting sebelumnya. Tidak di respon juga berbahaya. Tidak di respon itu artinya di ghosting, bikin kesel! #eh
Jika ada komentar atau pendapat, bisa di share di comment di bawah. Jika tidak ada komentar, saya asumsikan artikel ini gagal untuk diproses…
Originally published at My Linkedin.
