SaaS Recurring Billing in Indonesia: Midtrans and Xendit

Menagih kartu satu kali itu mudah. Menagih pelanggan yang sama secara otomatis tiap bulan, terus-menerus, tanpa ada yang mengklik apa pun, adalah masalah yang berbeda. Itulah inti sebuah langganan, dan di Indonesia hal ini lebih sulit dari yang disiratkan tutorial Stripe.

Kebanyakan pelanggan Indonesia tidak membayar dengan kartu kredit tersimpan. Mereka membayar lewat QRIS, GoPay, OVO, DANA, ShopeePay, atau transfer bank. Rail ini dirancang untuk pembayaran sekali jalan, bukan untuk merchant yang menarik dana secara diam-diam bulan depan. Membangun billing SaaS di sini berarti memahami rail lokal mana yang mendukung tagihan berulang, dan merekayasa solusi untuk yang tidak mendukungnya.

Kenapa Recurring Billing Sulit di Sini

Penetrasi kartu di Indonesia rendah, dan sebagian besar belanja digital mengalir lewat e-wallet dan QRIS ketimbang kartu kredit. Recurring billing mengasumsikan kebalikannya: instrumen tersimpan yang bisa ditagih merchant lagi tanpa kehadiran pelanggan. Ketika metode pembayaran dominan adalah kode QR yang dipindai pengguna setiap kali, model card-on-file yang jadi andalan SaaS Barat sama sekali tidak cocok.

Akibatnya, kamu tidak bisa sekadar menyalin alur langganan Stripe. Kamu butuh gateway yang mendukung merchant-initiated transaction di rail lokal, cara untuk tokenisasi instrumen apa pun yang dimiliki pelanggan, dan rencana cadangan untuk porsi besar pengguna yang metode bayarnya memang hanya bisa sekali pakai.

• Kepemilikan kartu kredit adalah perilaku minoritas, sehingga default card-on-file justru mengecualikan mayoritas calon pelanggan.
• E-wallet seperti GoPay dan OVO mendominasi belanja konsumen, tetapi hanya sebagian yang mendukung tagihan merchant-initiated bertoken.
• QRIS, standar QR nasional, dirancang agar pelanggan memindai dan menyetujui tiap pembayaran, bukan untuk perpanjangan otomatis diam-diam.

Gateway dan Fitur Recurring-nya

Dua gateway lokal menutupi sebagian besar pasar. Midtrans menyediakan Subscription API yang menarik dana otomatis pada interval tertentu; fitur recurring-nya dibangun di atas tokenisasi kartu, di mana alur One Click dan Two Clicks menyimpan detail kartu sebagai token, dan juga mendukung tokenisasi GoPay untuk tagihan berulang berbasis dompet. Secara teknis, Midtrans memperlakukan recurring dan one-click sebagai fitur token tersimpan yang sama, dan satu-satunya perbedaan adalah apa yang memicu penagihan.

Xendit menawarkan produk Subscriptions yang mengelola paket fixed-amount dan usage-based dengan jadwal mingguan, bulanan, atau tahunan. Kamu menentukan nominal, jadwal, dan opsi pemulihan untuk pembayaran gagal, lalu Xendit menangani penarikan dana sambil mengirim webhook seperti event retrying saat percobaan gagal dan event succeeded saat satu siklus berhasil; ia butuh minimal satu payment channel yang mendukung merchant-initiated transaction. QRIS sendiri, yang distandarkan Bank Indonesia, adalah rail merchant-presented sekali bayar, sehingga tidak ada gateway yang bisa menagih ulang scan QRIS secara diam-diam dan ia menjadi titik perpanjangan manual, bukan instrumen recurring sejati.

Mesin Status Langganan

Sebuah langganan adalah mesin status kecil, dan menetapkan status serta transisinya dengan benar adalah sebagian besar pekerjaannya. Modelkan secara eksplisit, bukan menyimpulkan status dari baris pembayaran yang berserakan.

• Active: siklus saat ini sudah dibayar dan pelanggan punya akses, dengan penagihan berikutnya dijadwalkan pada akhir periode.
• Past due: penagihan perpanjangan gagal, sehingga akses bisa berlanjut selama masa tenggang sementara retry dunning berjalan dengan jadwal backoff.
• Canceled: pelanggan atau urutan dunning yang habis mengakhiri langganan, dan akses berhenti di akhir periode berbayar, bukan seketika.
• Proration: ketika paket berubah di tengah siklus, kreditkan porsi paket lama yang belum terpakai dan tagih sisa paket baru secara prorata.

Keandalan: Webhook dan Idempotency

Pembayaran bersifat asinkron. Pelanggan menyetujui di aplikasi dompet atau memindai QR, dan server kamu baru mengetahui hasilnya belakangan lewat webhook, bukan lewat respons API sinkron. Perlakukan webhook sebagai sumber kebenaran apakah satu siklus berhasil, dan jangan pernah menandai langganan aktif hanya karena kamu mengirim permintaan penagihan.

Webhook melakukan retry dan bisa datang lebih dari sekali atau tidak berurutan, jadi setiap handler harus idempoten: lakukan dedupe berdasarkan event atau order id dari gateway dan buat pemrosesan event yang sama dua kali menjadi no-op. Midtrans mendukung idempotency key saat membuat langganan, sehingga permintaan create yang di-retry mengembalikan hasil yang sama alih-alih duplikat. Lakukan rekonsiliasi harian dengan menarik daftar transaksi gateway dan membandingkannya dengan ledger kamu sendiri untuk menangkap webhook yang terlewat.

Jebakan yang Harus Diantisipasi

Mode kegagalan di sini spesifik untuk pasar lokal. Rancang untuk menghadapinya sejak awal, bukan menambal setelah perpanjangan pertama gagal.

• Perpanjangan gagal itu normal, karena saldo e-wallet habis dan kartu kedaluwarsa, jadi urutan dunning dengan retry dan pengingat wajib ada, bukan opsional.
• QRIS dan sebagian besar alur e-wallet bersifat sekali bayar secara desain, jadi untuk pengguna itu kamu tidak bisa menagih ulang diam-diam dan harus mengirim notifikasi perpanjangan dengan tautan pembayaran baru tiap siklus.
• Pajak dan faktur penting: PPN Indonesia dan kewajiban e-faktur berarti kamu harus menerbitkan faktur pajak yang benar per penagihan, jadi tanamkan penomoran faktur dan field pajak ke dalam catatan billing kamu.

Recurring billing SaaS di Indonesia lebih soal kenyataan bahwa kebanyakan pelanggan tidak bisa ditagih ulang secara diam-diam ketimbang soal API pembayaran. Pilih gateway yang menokenisasi instrumen yang benar-benar dimiliki pengguna, modelkan langganan sebagai mesin status yang eksplisit, dan buat setiap webhook idempoten serta terekonsiliasi. Ketika card-on-file mustahil, ubah perpanjangan menjadi alur notifikasi-plus-tautan yang andal.