Aplikasi QRIS, PPOB, atau top-up game biasanya punya satu titik yang kelihatannya kecil: layar login. End User memasukkan nomor, menunggu kode, lalu masuk. Kalau nomor tidak diverifikasi dengan rapi, masalahnya merembet ke mana-mana. Akun ganda, komplain transaksi sulit dilacak, sampai pemulihan akses yang bergantung pada nomor yang belum tentu benar.
Untuk aplikasi transaksi, OTP bukan hiasan keamanan. Ia adalah cara memastikan nomor yang dipakai End User memang bisa dihubungi saat akun dibuat, login dari perangkat baru, atau butuh verifikasi tambahan.
Kenapa login aplikasi transaksi perlu nomor yang bisa dipercaya
QRIS sendiri diposisikan Bank Indonesia sebagai standar kode QR pembayaran di Indonesia. Dari sisi merchant, satu kode QRIS bisa menerima pembayaran dari berbagai instrumen yang mendukungnya. Di lapangan, banyak aplikasi kecil dan menengah memakai konteks seperti ini untuk menerima pembayaran, menjual produk digital, atau mencatat transaksi End User.
Saat akun berkaitan dengan transaksi, nomor telepon menjadi bagian dari identitas operasional. Nomor itu bisa dipakai untuk login, notifikasi, bantuan support, dan pemulihan akses. UU PDP juga sudah berlaku sejak 17 Oktober 2024, jadi pengelolaan data pribadi tidak bisa diperlakukan seperti catatan bebas di spreadsheet internal.
Artinya, flow login perlu menyeimbangkan dua hal: jangan membuat End User menunggu terlalu lama, tapi jangan juga membiarkan nomor palsu langsung menjadi akun aktif.
Pola sederhana: request OTP dari backend, verifikasi sebelum akun aktif
Pola yang aman untuk aplikasi QRIS atau PPOB cukup jelas. Backend Client meminta OTP, aplikasi menampilkan input kode ke End User, lalu backend Client memverifikasi kode itu sebelum sesi login atau akun dinyatakan valid.
Di OTP.ID, alur publik V3 memakai endpoint POST /v3/request untuk membuat dan mengirim kode, lalu POST /v3/verify untuk mengecek kode yang dimasukkan End User. API key dikirim lewat header Authorization: Bearer ***, sehingga pemanggilan harus dilakukan dari backend Client. Jangan menaruh API key di aplikasi mobile atau browser. Begitu key ikut terkirim ke client app, kontrolnya hilang.
Contoh bentuk request yang aman untuk dokumentasi internal tim:
curl -X POST https://<BASE_URL>/v3/request \
-H "Authorization: Bearer ***" \
-H "Content-Type: application/json" \
-d '{"channel":"whatsapp","destination":"628xxxxxxxxxx","otp_length":6,"brand":"TokoAnda","external_id":"login-0001"}'Simpan otp_id di backend. Setelah End User memasukkan kode, backend memanggil endpoint verify dengan otp_id dan kode OTP. Kode salah pada V3 bisa kembali sebagai verified: false dengan reason mismatch, jadi aplikasi tidak perlu langsung menganggapnya sebagai gangguan sistem.
Pilih channel sesuai friksi dan biaya
OTP.ID mendukung lima kategori channel: WhatsApp, SMS, Voice, Email, dan Missed Call. Untuk aplikasi transaksi lokal, channel awal biasanya dipilih dari kebiasaan End User, biaya per OTP, dan seberapa penting flow itu. Login harian mungkin butuh friksi rendah. Pemulihan akun bisa memakai jalur yang lebih tegas.
Yang perlu diingat: OTP.ID tidak menjanjikan fallback otomatis antar channel. Channel dipilih eksplisit oleh Client. Kalau pengiriman gagal, transaksi berstatus gagal dan tidak didebit; keputusan mencoba channel lain tetap ada di aplikasi Client. Ini penting untuk desain produk, karena tombol "kirim ulang lewat SMS" atau "coba Voice OTP" sebaiknya memang dirancang di UI, bukan diasumsikan terjadi sendiri.
Dari sisi biaya, katalog publik OTP.ID mencantumkan beberapa harga per OTP, mulai dari Email OTP Rp20 sampai SMS OTP Rp670. Harga ini berguna untuk estimasi awal, tetapi struktur paket dan diskon volume masih keputusan bisnis terpisah. Untuk tim kecil, yang lebih penting biasanya bukan mencari angka paling rendah, melainkan tahu biaya per verifikasi dan kapan saldo perlu diisi ulang.
Hal kecil yang sering bikin OTP login berantakan
Masalah OTP jarang muncul dari satu baris kode saja. Lebih sering, masalahnya ada di aturan sekitar flow.
Pertama, tombol kirim ulang dibiarkan bebas. Server V3 memang punya rate limit per API key dan per destinasi, tetapi itu pagar terakhir. UI tetap perlu cooldown supaya End User tidak memicu banyak request karena panik atau karena jaringan sedang lambat.
Kedua, aplikasi menyamakan semua kegagalan. Kode salah, saldo habis, channel gagal kirim, dan rate limit butuh respons UI yang berbeda. Kalau semuanya hanya menjadi "terjadi kesalahan", tim support akan menerima tiket yang sebenarnya bisa dicegah dengan pesan yang lebih jelas.
Ketiga, saldo tidak dipantau. OTP.ID memakai model prepaid; request sukses didebit, dan response API memuat price serta last_balance. Aplikasi yang volume transaksinya mulai naik sebaiknya punya kebiasaan memantau saldo sebelum habis, bukan baru bereaksi saat login End User sudah terganggu.
Kapan OTP.ID relevan untuk tim kecil
OTP.ID paling masuk akal saat tim ingin fokus ke produk transaksi, bukan membangun lapisan pengiriman OTP dari nol. Client tetap mengatur logika bisnisnya sendiri: kapan OTP diminta, channel mana yang dipakai, bagaimana UI resend bekerja, dan kapan akun dianggap valid. OTP.ID menangani pengiriman serta verifikasi kode lewat satu API.
Untuk aplikasi QRIS, PPOB, voucher, atau top-up game, pendekatannya bisa dimulai sederhana: verifikasi nomor saat registrasi, tambah verifikasi saat login dari perangkat baru, lalu rapikan pesan error dan cooldown. Setelah volume tumbuh, tim bisa meninjau channel dan biaya berdasarkan pola pemakaian nyata.
Langkah awalnya tidak perlu rumit. Pastikan API dipanggil dari backend, nomor dinormalisasi ke format 628xxxxxxxxxx, flow resend punya jeda, dan setiap error penting punya tindakan lanjutan yang jelas untuk End User.