PayStory — Lagi-Lagi Transaksi Timeout
Sebenarnya, isu mengenai transaksi yang mengalami timeout atau tidak mendapatkan respon telah pernah saya bahas dalam artikel berjudul “PayStory: Tidak Ada Respon / Timeout TIDAK SAMA DENGAN Gagal”
Namun, tampaknya cakupan target pembaca artikel ini perlu diperluas. Artikel ini tidak hanya relevan bagi individu di bidang teknis, tetapi juga penting untuk dimengerti oleh tim operasional, keuangan, bahkan bisnis, karena isu yang dibahas akan mempengaruhi semua pihak tersebut.
Contoh Kasus: Di sebuah penyedia layanan QRIS, ketika tim Keuangan mendapat laporan rekonsiliasi dari Switching, laporan ini mungkin mencakup transaksi dengan kode RC 68. Meskipun tim Teknis telah mengklarifikasi kepada tim Keuangan bahwa kode RC 68 menandakan transaksi yang mengalami timeout, masih ada ketidakjelasan di antara mereka tentang alasan mengapa hal ini bisa terjadi dan mengapa dana masih diteruskan meski status transaksi tidak tercatat sebagai sukses. Pemahaman mereka adalah hanya transaksi yang tercatat dalam laporan mereka yang dapat dianggap sukses dan dana pun akan diterima.
Inilah sebabnya saya selalu menekankan pentingnya informasi yang menyeluruh kepada semua stakeholder terkait saat sebuah fitur diaktifkan. Tujuannya adalah agar semua pihak memahami apa yang sedang terjadi dan dapat menyusun Standar Operasional Prosedur (SOP) yang diperlukan untuk menangani berbagai situasi yang mungkin muncul dari fitur tersebut. Misalnya, situasi seperti yang terjadi dengan kode RC 68 pada transaksi QRIS bisa dihindari jika sejak awal pihak-pihak terkait telah diinformasikan mengenai mekanisme transaksi dan potensi isu yang bisa muncul.
“Tapi saya masih tidak paham apa dan kenapa itu timeout”
Nahhh ini!
Markimak — mari kita simak
Ok, jadi begini bapak-bapak, ibu-ibu semua. Seperti yang telah saya jelaskan dalam artikel sebelumnya dan akan saya ulas kembali di sini, transaksi yang mengalami timeout — yang dalam konteks QRIS ditandai dengan kode 68 — biasanya terjadi saat sebuah permintaan pembayaran (API Payment Request) dikirim dari satu entitas ke entitas lain. Dalam ekosistem QRIS, ini umumnya melibatkan pengiriman dari pihak Issuer menuju pihak Acquirer melalui Switching.
Secara umum, ketika sebuah permintaan pembayaran diajukan, respons dari proses tersebut akan diterima oleh entitas yang mengirimkan permintaan. Entitas tersebut akan menerima informasi berupa status pembayaran, apakah sukses atau gagal. Jika transaksi sukses, maka akan ditampilkan halaman yang mengkonfirmasi keberhasilan transaksi, dan sebaliknya jika transaksi gagal.
Transaksi yang mengalami timeout bisa terjadi karena adanya hambatan, baik saat pengiriman permintaan dari pihak pengirim ke penerima, maupun saat proses pengembalian respon dari pihak penerima ke pengirim — situasi yang bisa berujung pada penerima tidak mendapatkan respon balik. Masalah ini dapat muncul baik sebelum informasi mencapai sistem Switching atau bahkan setelah sudah melewati tahapan di Switching.
Karena tidak ada respon balik, maka status permintaan pembayaran yang telah dikirim — apakah sukses atau gagal — tidak dapat dipastikan.
Sebagai contoh pertama, jika masalah terjadi pada tahap pengiriman permintaan dari pihak pengirim menuju Switching, dampaknya adalah sisi penerima tidak akan mendapatkan permintaan apapun dan oleh karenanya tidak dapat memberikan respon balik. Dalam konteks proses QRIS, jika situasi seperti ini terjadi, maka pihak Issuer akan menandai transaksi tersebut dengan kode 68.
Contoh kedua, masalah bisa muncul saat Switching berusaha meneruskan permintaan dari pihak pengirim ke pihak penerima. Jika terjadi hambatan pada tahapan ini, maka pihak penerima tidak akan menerima permintaan apa pun, sehingga tidak bisa memberikan respon balik. Dalam konteks proses QRIS, jika situasi semacam ini terjadi, pihak Switching akan menandai transaksi terkait dengan kode 68 dan mengirimkan respon dengan kode RC 68 kembali ke pihak pengirim.
Contoh ketiga, permintaan pembayaran telah berhasil mencapai sisi penerima, namun respon dari penerima tidak berhasil diteruskan ke Switching. Karena Switching tidak menerima respon dari penerima, maka Switching akan menandai transaksi tersebut sebagai transaksi yang mengalami timeout. Dalam konteks QRIS, ini akan ditandai dengan kode 68. Akibatnya, Switching akan mengembalikan respon ke pihak pengirim dengan status transaksi sebagai timeout atau menggunakan kode RC 68.
Dalam contoh terakhir, permintaan pembayaran telah berhasil diproses di sisi penerima dan Switching juga telah menerima respon dari pihak penerima. Switching berencana untuk meneruskan respon ini ke pihak pengirim, namun ternyata respon tersebut tidak pernah diterima oleh pihak pengirim. Akibatnya, pihak pengirim akan menandai transaksi ini sebagai transaksi yang mengalami timeout, atau dalam konteks transaksi QRIS, akan ditandai dengan kode RC 68.
Ada berbagai faktor yang dapat menyebabkan terjadinya transaksi timeout, mulai dari masalah jaringan, gangguan pada layanan web, hingga keberadaan bug dalam kode aplikasi. Inilah sebabnya mengapa sulit untuk memiliki Perjanjian Tingkat Layanan (SLA) yang 100% sempurna, karena akan selalu ada ‘faktor X’ yang dapat memicu timbulnya masalah. Dan perlu diingat, masalah ini tidak hanya berpotensi muncul dalam sistem berskala kecil; bahkan pada skala yang lebih besar dan global, isu-isu serupa tetap bisa terjadi.
Fenomena transaksi timeout tidak hanya terbatas pada transaksi QRIS. Metode pembayaran lainnya, seperti Virtual Account, Kartu Debit/Kredit, atau eMoney, juga menghadapi masalah yang serupa.
Lantas, bagaimana cara menangani transaksi yang mengalami timeout?
Memang, tidak semua masalah bisa diselesaikan melalui tindakan teknis, apakah itu karena keterbatasan teknologi atau pertimbangan biaya — misalnya, biaya tambahan yang diperlukan untuk membangun koneksi redundan. Dalam situasi di mana solusi teknis belum bisa ditemukan atau diimplementasikan, Standar Operasional Prosedur (SOP) menjadi instrumen penting untuk menavigasi dan mengelola masalah yang muncul. Inilah fungsi krusial dari SOP rekonsiliasi dalam kasus-kasus seperti ini.
Sebagai contoh dalam transaksi QRIS, setiap hari berikutnya (H+1) Switching akan mengirimkan laporan transaksi, baik sebagai Issuer maupun Acquirer. Biasanya, laporan yang berisi kode RC 68 (yang menandakan timeout) akan ditemukan pada laporan dari sisi Acquirer, mengingat posisi Acquirer sebagai pihak tujuan transaksi. Setelah mendapatkan daftar lengkap transaksi dengan kode RC 68, tim operasional atau keuangan harus melakukan rekonsiliasi antara data dari Switching dan data dari sistem internal mereka. Hasil dari rekonsiliasi ini akan menghasilkan dua jenis informasi:
- Jika data sesuai (match) dengan informasi yang tersimpan dalam sistem internal, status akhir dari transaksi — baik itu sukses atau gagal — dapat ditentukan dengan kepastian. Dalam konteks transaksi QRIS, jika status dari transaksi tersebut ternyata adalah gagal, langkah selanjutnya yang perlu dilakukan adalah mengajukan klaim pengembalian dana (refund) kepada pihak Switching, agar dana dapat dikembalikan kepada pembayar.
- Jika data tidak ditemukan dalam sistem internal, ini menunjukkan bahwa transaksi tersebut tidak pernah diproses oleh sistem internal. Dalam situasi seperti ini, ada beberapa langkah tindak lanjut yang dapat dilakukan. Salah satunya adalah menghubungi merchant untuk menentukan apakah transaksi tersebut ingin disetujui (disukseskan) atau ditolak (digagalkan). Alternatif lainnya adalah menerapkan kebijakan yang menyatakan bahwa jika data transaksi tidak terdokumentasi dalam sistem, maka transaksi tersebut akan secara otomatis dianggap gagal dan dana akan dikembalikan kepada pengguna.
Apakah di QRIS dana bisa dikembalikan? Ya, tentu saja bisa. Untuk memahami prosedurnya dengan lebih detail, anda dapat menghubungi pihak Switching tempat anda terhubung dan meminta penjelasan lebih lanjut mengenai proses pengembalian dana.
Idealnya, semua pihak terkait harus memahami secara mendalam apa yang terjadi dalam suatu proses transaksi, sehingga mereka bisa mengambil tindakan yang tepat dan efisien. Dengan demikian, ketika tim bisnis mendapat pertanyaan dari merchant mengenai transaksi yang mengalami timeout, atau tim keuangan menerima laporan tentang hal yang sama, semua pihak sudah siap dan memahami langkah-langkah yang harus diambil.
Jadi kalau sudah dipahami dan dimengerti mengenai transaksi timeout, harusnya sudah bisa melakukan apa yang harus dilakukan kan ya? Jangan sampai seperti kata John Francis Bongiovi Jr :
I play my part and you play your game
And you give us a bad name
Sandi Fajariadi mempunyai pengalaman di product development khususnya yang berkaitan dengan QRIS, sistem pembayaran, uang elektronik, dan dompet digital. Di waktu senggang membuat aplikasi mobile seperti QRIS wantuno, cek RS dan juga pernah mengeluarkan beberapa lagu di album juga, cekidot channel Youtube-nya di sini.
