Aplikasi top up game biasanya hidup dari transaksi cepat. End User daftar, masuk, pilih nominal, bayar, lalu menunggu item masuk. Kalau layar verifikasi nomor macet, mereka bisa batal. Kalau request OTP dibiarkan bebas, masalahnya pindah ke sisi biaya: bot atau user iseng bisa menekan tombol kirim ulang berkali-kali sampai kredit verifikasi terkuras.
Itu salah satu bentuk OTP pumping. Polanya sederhana: request OTP dibuat berulang, sering kali ke nomor yang sama atau kumpulan nomor yang dikendalikan pelaku. Tujuannya bisa macam-macam, dari menghabiskan saldo pengiriman sampai menguji nomor yang aktif. Untuk aplikasi top up game, efeknya cepat terasa karena margin per transaksi bisa tipis dan traffic registrasi/login biasanya naik turun mengikuti promo.
Kenapa aplikasi top up game rawan kena spam OTP
Ada tiga kondisi yang membuat aplikasi top up game menarik untuk diserang. Pertama, alurnya sering terbuka untuk publik: siapa pun bisa memasukkan nomor dan meminta OTP. Kedua, user berharap prosesnya cepat, jadi tim produk kadang membuat tombol kirim ulang terlalu longgar. Ketiga, aplikasi seperti ini sering mengejar pertumbuhan lewat promo, referral, atau voucher. Semua hal itu membuat endpoint verifikasi menerima banyak percobaan dari traffic yang kualitasnya campur aduk.
Masalahnya bukan hanya "kode tidak sampai". Spam OTP bisa membuat biaya verifikasi naik, membuat log penuh noise, dan mempersulit tim support saat End User sungguhan mengeluh tidak bisa masuk. Kalau guard baru dipikirkan setelah biaya membengkak, tim biasanya harus memperbaiki UI, backend, dan konfigurasi channel sekaligus.
Pola OTP pumping yang perlu diwaspadai
Pola paling mudah dikenali adalah request berulang ke nomor yang sama dalam waktu pendek. Misalnya satu nomor meminta OTP berkali-kali dalam beberapa menit. Ada juga pola yang lebih menyebar: banyak nomor berbeda dipakai dari perangkat, IP, atau session yang sama. Di sisi aplikasi, keduanya bisa terlihat seperti traffic normal kalau hanya melihat jumlah request harian.
Tanda lain: request tinggi, tetapi angka verifikasi rendah. Banyak kode terkirim, sedikit yang dipakai sampai selesai. Ini tidak selalu berarti fraud; bisa juga karena UX buruk, pesan terlambat, atau channel yang kurang cocok untuk segmen End User tertentu. Karena itu, tim sebaiknya tidak langsung memblokir secara membabi buta. Mulai dari pembatasan yang jelas dan mudah dijelaskan ke End User.
Guard minimum sebelum request OTP dikirim
Guard pertama ada di aplikasi Client sendiri. Tombol kirim ulang perlu cooldown. Form nomor perlu validasi dasar. Backend perlu membatasi request berdasarkan nomor, akun, device, session, dan IP jika data itu tersedia. Jangan hanya mengandalkan tombol disable di frontend, karena bot bisa memanggil endpoint backend langsung.
API key juga tidak boleh ditanam di aplikasi mobile atau browser. OTP.ID mendokumentasikan integrasi V3 sebagai panggilan dari backend Client memakai header Authorization: Bearer ***. Aplikasi mobile cukup berbicara ke backend milik Client, lalu backend itulah yang memanggil OTP.ID. Kalau API key ikut terbawa ke client-side app, siapa pun yang membongkar aplikasi bisa mencoba memakainya.
Untuk UX, beri pesan yang jujur. Jika End User baru saja meminta OTP, tampilkan hitung mundur. Jika terlalu sering meminta kode, minta mereka menunggu. Kalimat seperti itu lebih baik daripada pesan error umum yang membuat user menekan tombol berkali-kali.
Guard yang sudah ada di API V3 OTP.ID
OTP.ID menyediakan pagar di sisi API V3. Global limit per API key adalah 20 request per detik untuk endpoint /v3. Untuk endpoint pembuatan OTP, channel standar dibatasi per merchant dan destinasi: 5 OTP per 10 menit dan 10 OTP per jam. Missed Call lebih ketat, yaitu 2 request per 10 menit dan 4 per jam.
Batas ini penting, tetapi sebaiknya diperlakukan sebagai pagar terakhir. Tim Client tetap perlu memasang pembatas sendiri sebelum request masuk ke OTP.ID, terutama untuk flow yang rawan spam seperti register, login, klaim promo, dan reset akses.
Ada satu detail yang sering membantu dari sisi biaya: pengiriman yang gagal tidak didebit. Jika nomor tidak bisa dijangkau lewat channel yang dipilih, request bisa berstatus gagal tanpa memotong kredit. Namun OTP.ID tidak menjalankan fallback otomatis antar channel. Setelah gagal, aplikasi Client yang memutuskan apakah perlu mencoba channel lain, menunggu End User, atau menghentikan proses.
Pilihan channel tetap perlu strategi
OTP.ID mendukung WhatsApp, SMS, Voice, Email, dan Missed Call. Untuk aplikasi top up game, pilihan channel biasanya tidak cukup dijawab dengan "pakai yang paling murah". Ada End User yang lebih mudah menerima WhatsApp. Ada kondisi ketika SMS atau Voice lebih masuk akal sebagai jalur berikutnya. Missed Call bisa berguna untuk skenario tertentu, tetapi alurnya perlu dijelaskan dengan baik di UI.
Karena tidak ada fallback otomatis antar channel, strategi channel berada di tangan Client. Ini memberi kontrol lebih besar: kapan mencoba ulang, channel mana yang dipakai, dan berapa kali End User boleh meminta kode. Kontrol itu juga mencegah biaya berjalan tanpa disadari karena aplikasi bisa menentukan batas sebelum membuat request baru.
Untuk tim kecil, mulai dari aturan sederhana dulu. Misalnya WhatsApp sebagai pilihan awal, lalu channel lain hanya muncul setelah status gagal atau setelah user meminta opsi lain. Jangan menawarkan semua channel sekaligus jika tim belum siap membaca log dan menangani keluhan dari setiap jalur.
Checklist implementasi untuk tim developer
Sebelum flow OTP dipakai di produksi, cek beberapa hal ini:
- API key disimpan di environment backend, bukan di aplikasi mobile atau web frontend.
- Backend Client menyimpan `otp_id` dari response request karena nilai itu dibutuhkan saat verifikasi.
- UI punya cooldown resend, bukan tombol bebas klik.
- Backend punya pembatas tambahan per nomor, akun, device, atau IP sesuai data yang tersedia.
- Aplikasi menangani `verified:false` dengan reason `mismatch` sebagai salah kode, bukan error sistem.
- Response rate limit dan saldo tidak cukup ditangani dengan pesan yang bisa dimengerti tim support.
- `last_balance` dipantau supaya kredit tidak habis diam-diam saat traffic naik.
Jika aplikasi top up game sedang tumbuh, OTP bukan bagian kecil yang bisa dibiarkan seadanya. Flow ini berada di depan pintu transaksi. Semakin cepat tim memasang guard, semakin kecil peluang biaya verifikasi bocor karena request yang tidak perlu.
OTP.ID membantu Client mengelola pengiriman dan verifikasi OTP lewat satu API, dengan channel yang bisa dipilih sesuai kebutuhan aplikasi. Untuk tim yang belum ingin membangun integrasi provider, template, saldo, dan pembatasan dasar sendiri, itu bisa mengurangi banyak pekerjaan awal. Mulai dari flow yang paling sering dipakai, uji dengan nomor tim sendiri, lalu rapikan aturan resend sebelum traffic promo berikutnya datang.