Cara membuat website top up game yang benar-benar bisa jual diamond, UC, atau voucher resmi selalu dimulai dari supplier atau distributor dengan API. Tema WordPress dan form checkout saja tidak cukup. Anda memang bisa membangun frontend dan backend, namun entitlement game hanya valid bila publisher atau partner resmi menerbitkannya.
Brief «langsung tarik dari Moonton/Garena» kerap muncul di chat developer. Masalah utamanya bukan framework, melainkan hak distribusi, saldo produk, dokumentasi API, alur pembayaran, dan legalitas usaha. Jadi urutan penjelasan di bawah menempatkan rantai bisnis dulu, lalu arsitektur teknis, regulasi Indonesia, serta batas tanggung jawab tim pengembang.
- Toko top-up menjual produk digital melalui supplier; website tidak «mencetak» diamond atau PIN publisher.
- Merchant kecil umumnya masuk lewat aggregator/distributor API; akses publisher langsung bergantung kontrak B2B, bukan selesainya coding.
- Dua integrasi terpisah: payment gateway (uang masuk) dan supplier game (produk keluar).
- Sebelum development: akun reseller, SKU, webhook, kebijakan gagal/pending, NIB/KBLI, dan PSE Lingkup Privat bila kriteria terpenuhi.
- Fulfillment hanya setelah webhook pembayaran terverifikasi server-side; idempotency wajib di kedua sisi.
Bisnis Website Top Up Bukan Masalah Template Dulu
Toko Anda menjual entitlement digital, bukan file HTML: diamond, UC, kredit in-game, PIN voucher, item, atau akses premium. Konsumen membayar di website Anda. Kemudian sistem merchant memanggil API supplier; pihak berwenang mengirim produk ke akun game atau memberikan kode redeem.
Pembeli kerap mencampurkan dua model fulfillment. Direct top-up meminta User ID (plus server/zone bila perlu) lalu supplier mengisi akun pemain. Voucher code mengembalikan PIN/serial yang pemain redeem sendiri di client game. Keduanya butuh stok dan otorisasi dari rantai distribusi resmi, bukan fungsi random string di PHP.
Apakah Website Bisa Generate Voucher Publisher?
Jawaban singkat: tidak, bila yang dimaksud voucher resmi milik publisher. Kode seperti output bin2hex(random_bytes(8)) tidak otomatis bernilai di Mobile Legends, Free Fire, atau title lain. Backend publisher tidak mengenalinya kecuali publisher menerbitkannya lewat jalur resmi.
Website boleh menjual voucher internal (poin loyalty, kupon diskon toko Anda), tetapi itu produk berbeda dari SKU publisher. Jangan samakan katalog WooCommerce dengan hak distribusi game.
Publisher, Distributor, dan Jalur Realistis Merchant Kecil
Secara bisnis, hubungan langsung dengan publisher memungkinkan bila publisher membuka program B2B dan menyetujui Anda. Tidak ada mekanisme publik yang membuat setiap penjual perseorangan otomatis mendapat API publisher besar.
Untuk usaha kecil, rantai publisher → distributor/aggregator → website merchant → konsumen jauh lebih umum.
Platform seperti Codashop menyatakan memiliki hubungan langsung dengan publisher di katalog mereka—itu posisi perusahaan skala platform, bukan default setiap reseller. Syarat penjualan webstore resmi mereka juga menegaskan bahwa produk digital berasal dari jalur resmi, bukan dari merchant acak yang «generate kode» sendiri (syarat penjualan Webstore Codashop).
Struktur kontraktual bisa berbeda per game; jangan generalisasi «semua publisher menolak reseller kecil» atau sebaliknya. Yang konsisten: tanpa kontrak, API resmi tidak akan muncul di brief developer.
Checklist Supplier Sebelum Membuat Website Top Up Game
Tim development seharusnya menerima brief setelah calon pemilik usaha bisa menjawab daftar singkat berikut: siapa supplier/distributor, status akun reseller, mekanisme deposit/saldo, daftar SKU, dan dokumentasi API.
Lengkapi juga format callback/webhook, penanganan pending/gagal/refund, kebutuhan IP whitelist, serta margin per produk. Tanpa itu, yang terbangun hanyalah «software kosong» tanpa sumber stok.
Contoh dokumentasi buyer API aggregator seperti Digiflazz API Buyer – Topup menunjukkan pola umum: username, SKU, nomor pelanggan/User ID, ref_id, signature, lalu status sukses/pending/gagal. Meski demikian, Digiflazz bukan satu-satunya pemain di pasar; gunakan sebagai referensi bentuk request, bukan rekomendasi vendor tunggal.
ref_id harus unik dan idempotent—dua kali submit dengan referensi sama tidak boleh memicu dua potong saldo. Aturan ini sama pentingnya dengan desain database order Anda.
Arsitektur Website Top Up Game Otomatis
Alur sehat memisahkan status pembayaran dan status fulfillment. Konsumen checkout lalu order berstatus WAITING_PAYMENT. Setelah redirect/VA/e-wallet, payment provider mengirim webhook; server memverifikasi lalu menandai PAID.
Worker memanggil supplier API hingga status PENDING, SUCCESS, atau FAILED. Akhirnya sistem mengirim notifikasi ke pembeli dan log admin.
Komponen minimum meliputi katalog game/SKU, pricing (sinkron harga supplier), checkout, modul payment, processor order, antrian/worker, retry terbatas, log webhook, rekonsiliasi saldo supplier, dashboard admin, dan monitoring. Skema data inti umumnya memuat products, supplier_products, orders, payments, supplier_transactions, webhook_logs, serta history harga/saldo.
Tutorial integrasi payment gateway pada website donasi WordPress menjelaskan pola merchant: API key, callback, verifikasi status di server. Top-up game menambah lapisan kedua—panggilan supplier setelah uang benar-benar masuk.
Payment Gateway Bukan Supplier Voucher
Payment gateway atau Penyedia Jasa Pembayaran (PJP) mengurus kanal bayar konsumen ke merchant. Supplier game mengurus pengiriman produk digital. Website Anda hampir selalu butuh keduanya, dengan kontrak, kredensial, dan webhook terpisah.
Menjadi merchant yang memakai Midtrans, Xendit, atau sejenisnya tidak sama dengan mendirikan PJP sendiri. Artikel membuat payment gateway seperti Xendit atau Midtrans memisahkan integrasi checkout dari izin Bank Indonesia. Hal itu relevan bila brief client mengacaukan «gateway bayar» dengan «sumber diamond».
Peraturan Bank Indonesia Nomor 10 Tahun 2025 mewajibkan pihak yang bertindak sebagai PJP memiliki izin BI. Toko top-up yang hanya menerima pembayaran lewat PJP berizin umumnya berposisi sebagai merchant retail, bukan otomatis menjadi PJP. Walau demikian, klasifikasi final bergantung aktivitas riil; konsultasikan ahli bila model bisnis Anda memindahkan dana sendiri.
NIB, KBLI, PSE, dan Data Pribadi
NIB lewat OSS menjadi fondasi legalitas usaha. KBLI 2025 60390 (Aktivitas Situs Jejaring Sosial dan Distribusi Konten Lainnya) mencantumkan intermediasi penjualan voucher, kredit, item dalam gim, dan akses premium melalui platform distribusi/marketplace.
Lihat uraian resmi di OSS KBLI 60390. Retailer reseller kecil belum tentu identik dengan platform; pilih KBLI sesuai kegiatan aktual, bukan copy-paste angka dari artikel.
Komdigi menempatkan portal/situs yang menawarkan atau memperdagangkan barang/jasa dalam kriteria PSE Lingkup Privat. Pemilik layanan wajib mendaftarkan PSE dengan NIB, izin terkait, dan data operasional (URL, model bisnis, pemrosesan data). FAQ resmi ada di portal PSE Komdigi.
Website memproses nama, email, WhatsApp, User ID game, log IP, dan metadata transaksi—termasuk dalam ruang lingkup UU No. 27 Tahun 2022. Hindari menyimpan data kartu sendiri; gunakan hosted checkout/tokenisasi dari payment provider.
Keamanan Teknis yang Sering Terlewat
Secret API dan signature supplier hanya di server. Verifikasi webhook payment dan supplier; jangan fulfillment hanya karena halaman browser menampilkan «pembayaran berhasil».
Terapkan idempotency key, rate limiting, CSRF pada form admin, prepared statement/ORM, audit log, dan rekonsiliasi harian saldo supplier versus log transaksi.
Transaksi pending butuh state machine jelas: kapan retry, kapan eskalasi ke CS, kapan refund ke pembeli sesuai kontrak supplier. Duplikat order dari double-click atau webhook ganda adalah skenario normal, bukan edge case.
Pisahkan endpoint callback payment gateway dan callback supplier—keduanya bisa datang out-of-order. Urutan aman: tandai bayar hanya setelah signature PJP valid, enqueue job fulfillment, lalu update status order dari respons supplier async. Simpan raw payload webhook untuk audit sengketa.
Callback Pembayaran vs Callback Supplier
Payment gateway mengirim notifikasi saat VA terbayar atau e-wallet sukses; supplier mengirim update terpisah saat diamond terkirim atau gagal. Jangan satukan handler satu fungsi tanpa branching—tim CS akan sulit membaca log saat pelanggan protes «uang sudah keluar, diamond belum masuk».
UI customer sebaiknya menampilkan tiga lapisan status: menunggu pembayaran, pembayaran diterima, produk sedang kami proses atau sudah terkirim. Spinner tanpa teks membuat pengguna refresh berulang; refresh itulah yang memicu duplicate request bila idempotency lemah.
Lapisan edge seperti konfigurasi Cloudflare WAF membantu melindungi endpoint publik. Namun sesuaikan rule dengan traffic API dan webhook—jangan copy-paste rule situs company profile statis.
Modal Kerja dan Ilustrasi Margin
Saldo supplier (deposit prabayar) terpisah dari saldo di payment gateway. Supplier memotong deposit saat fulfillment sukses, sementara settlement dari PJP ke rekening merchant bisa T+1 atau lebih. Artinya Anda butuh modal kerja meski omzet harian terlihat tinggi.
Berikut contoh ilustrasi, bukan harga pasar: deposit supplier Rp10.000.000, cost SKU Rp19.500, harga jual Rp22.000, fee bayar Rp500. Margin kotor sekitar Rp2.000 per transaksi—sebelum CS, infra, chargeback, dan SKU gagal.
WordPress, Laravel, atau Stack Custom?
Toko sederhana dengan plugin WooCommerce plus custom plugin API supplier bisa jadi MVP. Order volume tinggi, multi-supplier, antrian, dan dashboard rekonsiliasi berat cenderung butuh backend dedicated (Laravel, CodeIgniter, Node, dll.). Kompleksitas workflow order menentukan stack, bukan seberapa populer game di katalog.
Bila tim Anda masih memetakan fondasi hosting, domain, dan CMS sebelum memutuskan custom app, roadmap belajar membuat website dari nol membantu memisahkan fase «situs bisa online» dengan fase «sistem order + API supplier siap produksi».
Informasi Konsumen dan Kebijakan Transaksi
Halaman produk wajib menampilkan denominasi, harga final, estimasi proses bila ada, dan konsekuensi salah User ID. Terms of Service dan Privacy Policy tidak boleh copy-paste template toko fashion—sebutkan data game ID yang Anda simpan, retention log, serta channel CS.
Top-up sukses ke akun yang dimasukkan pembeli kerap tidak bisa supplier batalkan. Kebijakan refund harus mengikuti kontrak API dan UU Perlindungan Konsumen. Jelaskan kebijakan itu sebelum bayar; jangan menjanjikan «refund instan» tanpa melihat status fulfillment di log supplier.
Brief yang Harus Dibawa Klien ke Developer
Minimum sebelum estimasi waktu/cost: identitas pemilik usaha, model bisnis (retailer vs platform), nama supplier, status akun, link dokumentasi API, daftar SKU aktif, price list, metode deposit, payment gateway pilihan, SOP pending/gagal, dan kontak eskalasi supplier. Tanpa dokumen API, developer hanya bisa membuat mock endpoint.
Permintaan «buat dulu, supplier nyusul» layak ditolak atau dibatasi ke fase desain UI tanpa go-live fulfillment. Bukti kontrak reseller, sandbox credential, atau email onboarding resmi lebih meyakinkan daripada screenshot katalog competitor.
Batas Tanggung Jawab Web Developer
Developer dapat membangun frontend, backend, integrasi payment, integrasi supplier, dashboard, otomasi, dan hardening keamanan. Developer tidak dapat menerbitkan diamond publisher, membuat PIN resmi, menjamin diterima sebagai partner publisher, mengganti izin usaha, atau «menyalakan» API yang supplier tidak pernah berikan kepada klien.
API bukan fitur yang muncul otomatis setelah deploy. API adalah hak akses dari pemilik layanan kepada pihak yang sudah terkontrak. Brief «buat web dulu, supplier nanti» berisiko: client mengira go-live berarti stok ready.
FAQ Singkat seputar Top Up Game
Apakah bisa membuat website top up sendiri?
Bisa, untuk software dan integrasi. Produk game tetap harus dari distributor/aggregator/publisher yang sah.
Apakah harus pakai payment gateway?
Tidak mutlak secara teknis, tetapi otomatisasi bayar online hampir selalu lewat PJP berizin agar Anda tidak membangun infrastruktur sistem pembayaran sendiri.
KBLI apa untuk bisnis voucher game?
60390 relevan untuk platform distribusi/marketplace digital game; retailer murni mungkin berbeda—sesuaikan di OSS dengan kegiatan riil.
Verifikasi Go-Live Website Top Up Game
Sebelum membuka toko, uji end-to-end di sandbox supplier bila ada: order dummy, webhook payment palsu (negative test), webhook ganda, SKU tidak tersedia, User ID salah, dan saldo supplier habis. Pastikan Terms, Privacy Policy, identitas usaha, kebijakan refund, serta kanal CS terbaca sebelum transaksi berbayar.
Setelah supplier, API resmi, payment flow, dan dokumen legal siap, tim pengembang baru bisa memperkirakan scope integrasi dengan realistis. CodeF sejak 2009 rutin membantu pemilik bisnis membangun website dan sistem order custom—including integrasi API—setelah sumber produk dan dokumentasi supplier jelas; kerja sama dengan publisher atau distributor tetap di tangan pemilik usaha.
