😀 Saat mengisi ulang pengguna dan mencatat masuknya dana, yang paling berbahaya bukan karena tidak ada catatan (memo), melainkan karena menjadikan memo sebagai KTP/ID.
Di panduan pemindaian top up Moonlight milik @Dusk , saya menyoroti dua kalimat yang hampir berdekatan.
Dokumen mengembalikan memo dalam format heksadesimal, lalu mengelompokkannya sebagai “data rute yang tidak tepercaya” yang perlu diverifikasi terlebih dahulu.
Peringatan berikutnya lebih tegas: jangan pernah menganggap memo sebagai kunci idempoten. Yang benar-benar unik adalah Dusk transaction ID.
Perbedaan inilah yang menentukan sistem pencatatan menganggap apa sebagai fakta. Memo hanya memberi petunjuk pada sistem “mungkin harus diberikan kepada siapa”; transaction ID-lah yang bisa menjawab “apakah uang ini sudah diproses.”
Jika platform mencampuradukkan keduanya, penanda di sisi depan (front-end) yang praktis bisa disalahartikan sebagai pembukuan backend.
Skenario buruknya adalah dua kali top up yang membawa memo yang sama, hilang, atau formatnya tidak valid. Jika sistem melakukan deduplikasi berdasarkan memo, bisa jadi satu transaksi terlewat. Jika langsung menelusurinya berdasarkan memo, bisa jadi permintaan yang tidak normal malah didorong ke akun yang salah. Pengguna hanya akan melihat top up yang lama tak kunjung masuk, sementara tim operasional harus bolak-balik rekonsiliasi dana, log, dan pelanggan.
Ini bukan karena desain memo milik $DUSK bermasalah, melainkan apakah pihak integrator mau mengakui bahwa informasi rute memang secara alami perlu diverifikasi. Dokumen milik @Dusk sudah memberikan arah: metadata yang tidak diketahui atau tidak valid harus masuk ke peninjauan manual, bukan dibuang diam-diam. Yang benar-benar patut diuji adalah apakah pihak yang terhubung akan memasukkan aturan ini ke dalam produk, sehingga pengguna bisa melihat bahwa mereka sedang dalam proses peninjauan manual.#dusk
Di panduan pemindaian top up Moonlight milik @Dusk , saya menyoroti dua kalimat yang hampir berdekatan.
Dokumen mengembalikan memo dalam format heksadesimal, lalu mengelompokkannya sebagai “data rute yang tidak tepercaya” yang perlu diverifikasi terlebih dahulu.
Peringatan berikutnya lebih tegas: jangan pernah menganggap memo sebagai kunci idempoten. Yang benar-benar unik adalah Dusk transaction ID.
Perbedaan inilah yang menentukan sistem pencatatan menganggap apa sebagai fakta. Memo hanya memberi petunjuk pada sistem “mungkin harus diberikan kepada siapa”; transaction ID-lah yang bisa menjawab “apakah uang ini sudah diproses.”
Jika platform mencampuradukkan keduanya, penanda di sisi depan (front-end) yang praktis bisa disalahartikan sebagai pembukuan backend.
Skenario buruknya adalah dua kali top up yang membawa memo yang sama, hilang, atau formatnya tidak valid. Jika sistem melakukan deduplikasi berdasarkan memo, bisa jadi satu transaksi terlewat. Jika langsung menelusurinya berdasarkan memo, bisa jadi permintaan yang tidak normal malah didorong ke akun yang salah. Pengguna hanya akan melihat top up yang lama tak kunjung masuk, sementara tim operasional harus bolak-balik rekonsiliasi dana, log, dan pelanggan.
Ini bukan karena desain memo milik $DUSK bermasalah, melainkan apakah pihak integrator mau mengakui bahwa informasi rute memang secara alami perlu diverifikasi. Dokumen milik @Dusk sudah memberikan arah: metadata yang tidak diketahui atau tidak valid harus masuk ke peninjauan manual, bukan dibuang diam-diam. Yang benar-benar patut diuji adalah apakah pihak yang terhubung akan memasukkan aturan ini ke dalam produk, sehingga pengguna bisa melihat bahwa mereka sedang dalam proses peninjauan manual.#dusk
