PayStory: Ingat! Respon Tidak Sesuai Bukan Berarti Gagal Juga (Artikel Lanjutan)

Betul sekali, ini artikel lanjutan. Lanjutan dari artikel timeout/tidak ada respon, bisa dicek di link berikut : Tidak Ada Respon / Timeout TIDAK SAMA DENGAN Gagal.

Kenapa kita masih perlu melanjutkan sih? Karena ada beberapa kasus yang harus dipahami di proses finansial, khususnya di proses seperti pembayaran. Respon yang didapatkan akan menentukan tindakan berikutnya apakah suatu transaksi bisa dianggap sukses atau gagal atau tidak diketahui. Jangan sampai kita mengambil tindakan yang salah yang bisa mengakibatkan kerugian baik di pihak kita atau tujuan kita.

Jangan sampai kita mengambil tindakan yang salah yang bisa mengakibatkan kerugian baik di pihak kita atau tujuan kita

Sekilas dari artikel sebelumnya, jika kita tidak mendapatkan respon dari suatu proses API maka jangan diasumsikan proses itu gagal (apalagi sukses), karena pada dasarnya kita tidak tahu apakah request API tersebut sampai atau tidak di tujuan.

Nah, sekarang kita bahas skenario yang berbeda lagi. Apa yang harus dilakukan jika sumber mendapatkan respon, tetapi respon tersebut tidak terdefinisi atau tidak sesuai dengan ekspektasi respon dari tujuan?

Contoh: misal sudah disepakati sesuai dokumentasi, bahwa jika dalam data respon di parameter CODE berisi 00 maka artinya sukses. Jika CODE berisi 01 maka artinya gagal. Tapi dalam proses nyatanya, ternyata respon yang didapat berupa HTTP error atau respon berisi karakter yg tidak terdefinisi (misal XX) atau bahkan respon yang didapat berisi karakter aneh (misalnya K$$JGD#*%RSF*!##). Apa yang harus dilakukan?

Pilihan pertama, jika memang tercantum di dalam dokumentasi atau sudah ada penjelasan terkait skenario yang mungkin terjadi maka lakukan hal sesuai penjelasan yang sudah diberikan. Artinya skenario di atas sudah dipikirkan kemungkinannya oleh pihak tujuan dan sudah dikonfirmasikan tindakan yang harus dilakukan sesuai respon yang diberikan.

Tapi jika hal hal tersebut belum pernah diinformasikan atau dijelaskan dalam dokumentasi, maka tindakan yang disarankan adalah jangan mengambil keputusan bahwa proses yang dilakukan gagal. Begini alasannya: ketika respon diberikan artinya aplikasi sudah memberikan jawaban atas permintaan tersebut. Bahkan dalam kasus HTTP 500, problem ini dikarenakan ada data balikan yang tidak bisa dibaca oleh web service sehingga memunculkan error HTTP 500 (lain hal jika mendapat HTTP 3xx atau 4xx). Artinya request tersebut sudah diterima dan dikembalikan oleh aplikasi. Kita tidak bisa tahu ada hal apa di sistem tujuan yang menyebabkan balikan data tidak dikenal dan apakah data tersebut telah terproses di sistem tujuan. Ini yang menjadi alasan kenapa kita tidak bisa mengambil keputusan bahwa respon tersebut berarti gagal.

Kita tidak bisa tahu ada hal apa di sistem tujuan yang menyebabkan balikan data tidak dikenal dan apakah data tersebut telah terproses di sistem tujuan

Contoh kasus misal pembayaran menggunakan Virtual Account. Customer membayar transaksi menggunakan Virtual Account. Datang ke ATM dan memasukkan kode VA nya. Ketika informasi pembayaran VA dikirimkan ke sistem toko online terdapat logic aplikasi yang bermasalah saat mengembalikan respon tetapi masalah tersebut muncul setelah proses transaksi sudah dinyatakan sukses. Respon yang dikembalikan tidak bisa dibaca oleh Web Service maka akan muncul HTTP 500. Respon dibaca oleh sumber dan dinyatakan gagal maka dana akan dikembalikan, padahal transaksi sudah dinyatakan sukses. Ini akan mengakibatkan kerugian di pihak toko karena proses transaksi dianggap sudah sukses dan selesai tapi tidak ada dana yang diberikan.

Makanya di beberapa bank dibuat aturan bahwa transaksi hanya dinyatakan gagal jika bank mendapatkan kode respon yang sudah didefinisikan. Selain dari kode respon tersebut maka transaksi dianggap sukses. Hal ini untuk mencegah terjadinya kerugian di sisi pengguna layanan Virtual Account dari bank.

Intinya, untuk proses di sistem finansial dimana ada uang terdebet atau terkredit, pastikan bahwa proses yang dilakukan memang benar berhasil atau gagal. Karena jika tindakan yang dilakukan salah, ada kerugian finansial yang terjadi. Apalagi jika proses tersebut bisa dilakukan kapan saja oleh user sehingga tidak bisa cepat terdeteksi mengakibatkan kerugian finansial yang besar.

Intinya, untuk proses di sistem finansial dimana ada uang terdebet atau terkredit, pastikan bahwa proses yang dilakukan memang benar berhasil atau gagal

Okeh, sampai ketemu lagi di artikel berikutnya. Buat yang suntuk dan lesu, pengen jadi semangat dan beradrenalin tinggi, mungkin bisa dengerin musik ini The Vader — Where Are You . Konon bisa bikin hati bergetar dan jadi bersemangat. Seperti terprovokasi dan kayak pengen ngelempar barang. Jadi ingat Giant pas lagi nyanyi.

Originally published at https://www.linkedin.com.

Sandi Fajariadi mempunyai pengalaman di product development terutama terkait payment, emoney dan ewallet. Di waktu senggang membuat aplikasi mobile seperti cek RS dan dengan temannya iseng membuat beberapa lagu di The Vader