Meningkatkan Keamanan Transaksi dengan REFID

Sebagai pengelola server pulsa terutama yang banyak mengandalkan pesan instan (Instant Message) seperti Yahoo! Messenger atau XMPP, koneksi internet yang tidak stabil atau lambat dapat menimbulkan kerugian. Kerugian muncul karena “kejadian tidak terduga” akibat pesan yang diterima dengan lambat/tertunda.

Gambar dibawah ini mengilustrasikan kasus yang mungkin terjadi akibat pesan instan yang lambat/tertunda.

Pengertian Client pada gambar adalah (software) server pulsa yang mengambil stok ke server lain. Sedangkan Supplier adalah server si penyedia stoknya.

Pada t3, karena status transaksi masih menunggu (pending) atau belum ada balasan dari Supplier, maka operator (atau software secara otomatis) melakukan “kirim ulang” berharap mendapatkan balasan dari Supplier. Dan di saat yang sangat berdekatan (t4), ternyata proses di Supplier menyatakan bahwa transaksi tersebut berstatus gagal, dan balasan gagal pun dikirim ke Client. Pada t3, Client belum menerima balasan gagal dari Supplier, dan Supplier belum menerima pesan “kirim ulang” dari Client.

Pada t6, Client baru menerima balasan gagal dari Supplier sehingga software akan mengubah status transaksi dari menunggu (pending) menjadi gagal, dan status gagal tersebut pun diinformasikan ke anggota (reseller) yang melakukan transaksi. Di saat itu, transaksi sudah dianggap selesai, dengan demikian tidak ada lagi perubahan status.

Pada t5, Supplier baru menerima perintah “kirim ulang” dari Client. Jika transaksi sebelumnya berstatus gagal sukses, biasanya Supplier akan memblok perintah tersebut. Namun karena transaksi sebelumnya berstatus gagal, maka Supplier akan menganggap perintah tersebut sebagai transaksi baru dan akan memprosesnya.

Tentu ini akan menjadi masalah karena Client sudah menganggap bahwa transaksi tersebut sudah selesai dengan status gagal. Apalagi informasi dari Supplier tersebut menandakan juga bahwa saldo Client terpotong akibat diterimanya transaksi tersebut.

Solusi dengan REFID

Pada t5, Supplier akan mencari data transaksi sebelumnya dengan Refid 326. Apapun status transaksi sebelumnya, Supplier tidak akan memproses ulang transaksi tersebut, melainkan hanya menginformasikan kembali status dari transaksi Refid 326.

Penerapan

REFID baru bisa diterapkan pada Software Pulsa OtomaX versi 3.3 atau lebih baru.

Ada beberapa tahapan yang perlu dilakukan agar REFID dapat digunakan pada Software Pulsa OtomaX:

1. Di Supplier, menyediakan format transaksi yang menggunakan parameter [refid]. Contoh format request: [kodeproduk] [tujuan] [pin] R#[refid] (update 07/11/2014)

   

2. Di Supplier, menambahkan informasi [refid] di setiap balasan status transaksi. Contoh format balasan: R#[refid] [namaproduk] [kodeproduk].[tujuan] GAGAL. [keterangan].

   

3. Di Client, menyisipkan parameter [trxid] pada parsing. Parameter [trxid] ini yang akan dikenali Supplier sebagai [refid]. Parameter [counter] sudah tidak diperlukan lagi karena sudah terakomodir oleh parameter [trxid]/[refid]. Contoh parsing: T[nominal] [tujuan] [pin] R#[trxid]
4. Di Client, menangkap parameter [refid] yang dikirim oleh Suplier sebagai parameter [trxid] di sisi Client. Untuk menangkap [refid] dari Supplier, bisa menggunakan regex: R#(?<trxid>\d+)\D*. Kita tidak harus menangkap parameter nomor dan nominal lagi karena sudah terwakili oleh TRXID.

   

Kesimpulan

• Penerapan REFID bisa menghindarkan kerugian akibat lambatnya atau tidak stabilnya koneksi internet.
• Dengan menggunakan TRXID sebagai REFID dan menangkap kembali REFID sebagai TRXID, dapat meningkatkan akurasi penangkapan jawaban dari Supplier sehingga masalah “salah kamar” bisa dihindari.
• Penerapan REFID bisa dilakukan pada Software Pulsa OtomaX versi 3.3 atau lebih baru.