Sebuah pesan WhatsApp singkat pernah masuk ke inbox tim pengembang: «Bisa bikin payment gateway seperti Xendit atau Midtrans?» Tanpa model bisnis, tanpa diagram alur dana, tanpa penjelasan siapa yang memegang rekening merchant. Bagi kami, kalimat itu menggemakan keinginan membuat payment gateway sendiri setara penyedia besar—padahal label «payment gateway» di poster startup tidak otomatis sama dengan izin Penyedia Jasa Pembayaran (PJP) dari Bank Indonesia (BI).
Reaksi pertama bukan «tidak bisa coding». Justru «ini bukan brief plugin checkout». Pertanyaan itu terdengar teknis. Nyatanya, ia menyentuh industri sistem pembayaran yang diatur BI. Artikel ini menjelaskan mengapa brief semacam itu sering salah paham. Kami memisahkan fakta regulasi (rujukan sumber primer BI), ilustrasi hipotetis, dan opini editorial—bukan nasihat hukum perizinan.
Membuat Payment Gateway Sendiri Bukan Sekadar Form Checkout
Di percakapan sehari-hari, «payment gateway» kerap merujuk tombol bayar di checkout WooCommerce. Redirect ke halaman Midtrans/Xendit, webhook notifikasi, lalu status «paid». Jadi, itu pekerjaan integrasi merchant terhadap penyedia yang sudah berizin. Bukan seluruh tumpukan operasi penyelenggara jasa pembayaran.
Penyelenggara skala besar menjalankan orkestrasi lebih dalam. Routing ke berbagai metode bayar, rekonsiliasi, settlement ke merchant, refund, dispute, antifraud, SLA uptime, pelaporan ke regulator, hubungan dengan bank. Satu entitas tidak selalu melakukan semua lapisan; struktur industri SP memecah peran. Namun bila brief Anda «buat Xendit baru», ruang lingkup melampaui plugin WordPress.
Bisa Membuat Kodenya? Bisa. Boleh Mengoperasikan Bisnisnya? Itu Pertanyaan Lain
Membangun prototipe aplikasi atau modul integrasi untuk perusahaan yang sudah punya kerangka hukum berbeda jauh dari mendirikan PJP yang menampung dana publik. Developer menulis API, dashboard, worker webhook. Kemudian, entitas legal, izin, kepatuhan, dan perjanjian dengan peserta sistem pembayaran menentukan apakah produk boleh dijual sebagai «gateway» ke pihak luar.
Bank Indonesia dalam Peraturan Bank Indonesia Nomor 10 Tahun 2025 tentang Pengaturan Industri Sistem Pembayaran (PBI PISP) mendefinisikan Penyelenggara Jasa Sistem Pembayaran (PSP). PSP adalah Bank Umum atau LSBU yang menyelenggarakan jasa dan/atau infrastruktur sistem pembayaran. Penyedia Jasa Pembayaran (PJP) memfasilitasi transaksi pembayaran kepada pengguna jasa. Jadi, label di landing page tidak menggantikan klasifikasi kegiatan riil.
Kalau Ingin Seperti Xendit, Siapkan Perusahaan dan Urusan Regulasi
Halaman resmi BI untuk PBI PISP menyatakan pihak yang bertindak sebagai PJP harus memperoleh izin dari Bank Indonesia. Pemohon berupa Bank Umum atau LSBU. Bentuk badan hukum dan paket aktivitas (bundling) diatur lebih lanjut. Selanjutnya, peraturan pelaksana Peraturan Anggota Dewan Gubernur Nomor 32 Tahun 2025 (PADG PISP) menjadi rujukan perizinan, perencanaan bisnis, pengawasan, dan aspek operasional.
BI mengumumkan PBI dan PADG pada 24 Desember 2025. Petunjuk teknis implementasi menyebut ketentuan mulai berlaku 31 Maret 2026. Ada ketentuan transisi bagi PJP/PIP yang sudah ada sebelumnya. Sebelum mengutip pasal atau persyaratan modal, baca teks terbaru di portal BI atau JDIH BI. Jangan andalkan artikel vendor payment sebagai satu-satunya sumber hukum.
Menurut kami, membandingkan diri dengan merek penyedia populer tanpa memetakan aktivitas PJP mengecilkan biaya non-teknis: legal, compliance, audit, risiko operasional, hubungan dengan bank.
Mengapa BI Mengatur Modal untuk Payment Gateway?
Industri sistem pembayaran menyangkut kepercayaan publik terhadap aliran dana. BI menetapkan modal minimum dan persyaratan keuangan berkelanjutan. Rincian angka dan paket aktivitas ada di PADG PISP serta lampiran yang berlaku. Agar pelaku mampu menyerap kerugian, BI juga menuntut kontinuitas layanan dan pengelolaan risiko—not «biaya cloud server» semata.
Lantaran itu, pisahkan empat kantong yang sering tercampur dalam obrolan WhatsApp. (1) Biaya membangun perangkat lunak dan tim engineering. (2) Modal disetor dan modal berkelanjutan untuk entitas berizin. (3) Dana merchant/pelanggan yang harus tetap terpisah. (4) Dana operasional marketing atau sales. Brief yang hanya menanyakan «berapa quote PHP/Laravel» tanpa kantong (2)–(3) belum layak dibandingkan Xendit atau Midtrans sebagai benchmark bisnis.
Pertanyaan Sebelum Membuat Payment Gateway Sendiri
Sebelum minta estimasi biaya, pemilik proyek idealnya menjelaskan—meski belum teknis:
- Model bisnis: merchant aggregator, white-label UMKM, internal treasury, atau lain?
- Siapa pemilik dana di setiap titik: pembeli, merchant, escrow, rekening operasional?
- Peran Anda versus bank, PJP existing, atau merchant langsung.
- Aktivitas sistem pembayaran yang akan diselenggarakan versus diserahkan ke mitra berizin.
- Produk: QRIS, kartu, virtual account, e-wallet redirect, split settlement?
- Mekanisme settlement, cut-off, refund ke pengguna jasa.
- Target pasar dan risiko fraud yang diterima.
- Kesiapan badan hukum, pendanaan non-code, mitra legal/compliance.
Daftar ini bukan tes untuk mempermalukan klien. Ini standar discovery. Jadi, developer tidak perlu mengerjakan scope yang sebenarnya butuh konsorsium fintech.
Developer Bukan Pengganti Konsultan Regulasi dan Bank Indonesia
Tim engineering layak menilai feasibility stack setelah status legal dan diagram alur dana jelas. Setelah itu, monolith vs microservice, idempotency webhook, antrian retry, observability—semua itu masuk akal bila brief sudah jelas.
Penilaian «apakah aktivitas ini memerlukan izin PJP» wajib melibatkan ahli hukum atau perizinan serta regulator. Namun developer sebaiknya menolak brief «sekalian urus izin» tanpa peran profesional yang berwenang.
Sementara kebutuhan riil Anda hanya donasi atau jualan di WordPress, integrasi ke PJP yang sudah ada jauh lebih realistis. Panduan membuat website donasi WordPress hingga payment gateway menunjukkan jalur merchant: plugin, API key, webhook—bukan mendirikan penyelenggara baru. Untuk memilih stack custom versus CMS, lihat WordPress vs Laravel bila Anda masih memetakan portal integrasi internal atau toko online biasa.
Kesimpulan — Jangan Mulai dari «Bisa Bikin?», Mulailah dari «Bisnis Apa yang Akan Dijalankan?»
Meminta sistem setara penyedia pembayaran besar tanpa model bisnis, alur dana, dan rencana perizinan bukan brief proyek. Itu wishlist satu kalimat. Anda boleh mulai dari ide. Walau terdengar sederhana, langkah produktif pertama bukan «carikan developer murah». Tanyakan: «apakah kami merchant, mitra teknologi, atau calon PJP?» Lalu cocokkan dengan PBI PISP dan PADG PISP yang berlaku.
Setelah cakupan bisnis dan legalitas terpeta, barulah konsultasi software integrasi pembayaran—checkout, dashboard internal, middleware—tanpa janji menggantikan peran BI. CodeF sejak 2009 lebih sering membantu pemilik bisnis membangun website dan toko online terhubung ke penyedia berizin. Kami tidak mempromosikan proyek «gateway sendiri» tanpa fondasi regulasi. Brief sudah jelas? Hubungi tim untuk diskusi teknis. Belum? Baca ulang portal BI—hemat waktu Anda dan developer.
