Cara Integrasi API OTP ke Website Reseller

Website reseller OTP yang stabil bukan hanya soal bisa membuat order. Sistem harus bisa menampilkan katalog, menghitung harga, membuat order, menunggu OTP, menangani cancel, memproses refund, dan menjaga API key tetap aman. Jika salah desain, masalah yang muncul bisa berupa double charge, order nyangkut, harga tidak sinkron, atau user bingung karena status tidak jelas.

Artikel ini membahas pola integrasi API OTP untuk reseller secara praktis. Fokusnya bukan pada satu bahasa pemrograman, tetapi pada flow yang benar agar website kamu lebih aman dan mudah dirawat.

Komponen utama website reseller

• Halaman katalog layanan dan negara.
• Mesin markup harga.
• Endpoint create order di backend reseller.
• Worker atau cron untuk polling status OTP.
• Flow cancel dan refund.
• Riwayat order untuk user.
• Log audit untuk debugging.

Jangan panggil API OTP langsung dari browser user. API key harus disimpan di server reseller, bukan di JavaScript frontend.

Flow katalog dan harga

Ambil daftar layanan dari API atau simpan cache berkala di database reseller. Cache membantu halaman tetap cepat dan mengurangi request berulang. Untuk harga, simpan harga publik yang sudah termasuk markup kamu. Jangan tampilkan detail internal yang tidak perlu diketahui user.

Jika API mendukung pilihan operator atau server, tampilkan sebagai opsi tambahan, tetapi sediakan default yang aman. Pengguna lama yang tidak memilih operator tetap harus bisa order dengan pilihan otomatis jika flow mendukungnya.

Flow create order

Saat user klik beli, backend reseller harus melakukan beberapa langkah: cek saldo user, validasi service/country/server, buat idempotency key, panggil API create order, simpan order lokal, lalu kurangi saldo sesuai harga reseller. Jangan mengurangi saldo dua kali jika user refresh atau request retry.

Gunakan idempotency key untuk setiap niat order. Jika request timeout, backend bisa mengecek hasil request lama tanpa membuat order baru secara tidak sengaja.

Polling OTP dan status

Setelah order dibuat, jangan memaksa user refresh manual. Gunakan polling backend atau worker. Status umum yang perlu ditangani adalah pending, OTP received, success, cancelled, expired, dan failed. Tampilkan status dengan bahasa sederhana agar user tahu harus menunggu atau mengambil tindakan.

Cancel dan refund

Cancel harus idempotent. Jika user klik cancel dua kali, sistem tidak boleh refund dua kali. Simpan guard key atau status lokal untuk memastikan satu order hanya punya satu settlement refund. Setelah cancel berhasil, update order lokal dan balance log user.

Keamanan API key

• Simpan API key di environment variable atau secret manager.
• Jangan kirim API key ke frontend.
• Batasi akses admin yang bisa melihat atau mengganti key.
• Rotasi key jika ada indikasi bocor.
• Log request tanpa menampilkan key penuh.

Kesalahan umum reseller

Kesalahan umum adalah membuat order langsung dari frontend, tidak menyimpan idempotency key, tidak punya worker polling, menganggap semua cancel pasti refund penuh, dan tidak punya audit log. Kesalahan lain adalah menghapus order lokal saat gagal, padahal data itu penting untuk debugging dan komplain user.

Checklist production

• Saldo user tidak bisa negatif tanpa alasan bisnis.
• Order retry tidak membuat double charge.
• Cancel dua kali tidak membuat double refund.
• API key tidak pernah muncul di HTML, JS, atau response publik.
• Semua perubahan saldo punya balance log.
• Worker bisa dilanjutkan setelah server restart.

FAQ

Apakah reseller harus punya database lokal?

Sangat disarankan. Tanpa database lokal, kamu sulit melacak order, saldo, refund, dan komplain user.

Polling atau webhook?

Webhook bagus jika tersedia dan stabil. Polling tetap berguna sebagai fallback agar status tidak bergantung pada satu mekanisme.

Apakah operator wajib dipilih?

Tergantung flow API. Jika operator opsional, desain UI harus mendukung user yang memilih operator dan user yang memakai default otomatis.

Dengan OTPZap API, reseller bisa membangun flow pembelian OTP yang lebih rapi: katalog, order, status, cancel, dan refund bisa dikelola dari backend sendiri tanpa membuka detail internal ke user akhir.