Menagih langganan bulanan tanpa autodebet: alur per periode yang bisa dijalankan

Kasera Pay tidak menyimpan instruksi debet berulang. Tidak ada kartu tersimpan dan tidak ada penarikan yang berjalan sendiri saat jatuh tempo tiba. Setiap periode dimulai dari pelanggan yang membuka tautan lalu membayar sendiri. Panduan ini tentang cara menagih langganan bulanan di dalam batas itu tanpa kehilangan yang sebenarnya dibutuhkan penagih: tahu siapa yang sudah membayar untuk periode mana, dan kapan harus menutup akses.

Ada dua jalur, dan batasan di atas berlaku pada keduanya. Jalur manual, tersedia untuk semua akun, adalah isi panduan ini: terbitkan satu pembayaran biasa per periode dan simpan jadwal serta status aksesnya di sistem sendiri. Jalur kedua adalah API Langganan, yang terbuka untuk semua akun: objek Customer, Plan, Subscription dan Invoice beserta event siklus hidupnya. Mode test bisa dipakai siapa saja, sedangkan langganan live butuh akun yang sudah terverifikasi. Rinciannya ada di dokumentasi API Langganan. Jalur manual di bawah ini tetap berguna bagi yang ingin menyimpan jadwal di sistem sendiri. Kapan masing-masing jalur lebih tepat, termasuk biayanya per nominal, dibahas di perbandingan menu Langganan dan tagihan manual tiap bulan. Lewat API Langganan, pelanggan langganan yang sudah ada juga bisa dipindahkan sekaligus, dari file CSV atau baris yang ditempel dari spreadsheet, dengan tanggal tagihan yang tetap sama; caranya ada di bagian impor pelanggan pada dokumentasi API Langganan.

Yang menggantikan autodebet bukan satu fitur, melainkan tiga hal di sisi penagih: jadwal penerbitan tautan, tangga pengingat, dan catatan periode di basis data sendiri. Ketiganya bisa diotomatiskan penuh. Yang tidak bisa diotomatiskan hanyalah tindakan membayarnya.

Putuskan panjang periodenya sebelum apa pun dibuat

Satu aturan menentukan bentuk seluruh penagihan, dan lebih murah diketahui sekarang daripada setelah pelanggan pertama membayar. Kebijakan penggunaan terlarang menempatkan pre-order dan pembayaran di muka untuk barang fisik yang baru diserahkan lebih dari 30 hari ke depan pada daftar yang membutuhkan persetujuan tertulis lebih dulu, bersama tiket, perjalanan, dan donasi, lalu menyatakan bahwa langganan layanan atau software yang diserahkan terus-menerus tidak termasuk, berapa pun periode penagihannya. Daftar lengkapnya ada di kebijakan penggunaan terlarang.

Konsekuensinya bergantung pada apa yang diserahkan. Langganan layanan, seperti akses aplikasi, keanggotaan, atau jasa yang berjalan setiap hari, boleh ditagih bulanan, triwulanan, maupun tahunan tanpa langkah tambahan. Langganan yang isinya kiriman barang fisik, misalnya paket bulanan yang dikirim ke rumah, lain ceritanya: dibayar setahun di muka berarti sebagian besar barangnya diserahkan lebih dari 30 hari kemudian, dan itu harus dikabarkan lalu menunggu persetujuan sebelum tautan pertamanya dibuat. Kalau ragu termasuk yang mana, tanyakan ke halo@kasera.id lebih dulu.

Batas kedua adalah nominal: satu pembayaran dibatasi Rp 10.000 sampai Rp 10.000.000, sehingga paket tahunan di atas plafon itu harus dipecah, sementara paket bulanan hampir tidak pernah menyentuhnya.

Kenapa tautan tidak bisa diterbitkan jauh di muka

Godaan pertama saat menyusun penagihan berulang adalah membuat dua belas tautan sekaligus di awal tahun lalu menjadwalkan pengirimannya. Cara itu tidak tersedia, dan alasannya ada pada masa berlaku, bukan pada aturan langganan. Nilai expires_in_minutes divalidasi pada rentang 1 sampai 10080 menit, yaitu tujuh hari, dan di luar itu ditolak sebagai validation_failed. Di bawahnya masih ada plafon akun yang lebih ketat, bawaannya 24 jam, dengan kode expiry_too_long. Keduanya terdokumentasi di daftar kode error.

Artinya tautan periode berikutnya diterbitkan pada awal periode berikutnya, dan itu bukan keterbatasan yang perlu disiasati: tautan yang hidup berbulan-bulan menumpuk sebagai kewajiban yang bisa dibayar kapan saja, termasuk oleh pelanggan yang sudah berhenti berlangganan tiga bulan lalu. Cara memilih angkanya dibahas di artikel masa berlaku tagihan.

Alur satu periode, lima langkah

Ditulis untuk penagih yang punya sistem sendiri. Tanpa sistem sendiri, langkah satu sampai tiga dikerjakan dari dashboard dan sisanya tetap berlaku apa adanya.

1. Tugas terjadwal berjalan tiap hari, bukan sebulan sekali. Pelanggan berlangganan pada tanggal berbeda-beda, jadi tugas harian mengambil siapa saja yang jatuh tempo hari itu. Tugas bulanan memaksa semua orang ditagih pada tanggal yang sama dan menumpuk seluruh beban pengingat pada satu hari.
2. Terbitkan pembayaran untuk periode itu. Lewat endpoint create, dengan description yang menyebut paket dan periodenya, misalnya “Paket Pro, September 2026”. Teks itu tampil di halaman pembayaran dan terbawa ke ekspor CSV, jadi menulis periode di situ adalah selisih antara rekap yang terbaca dan rekap yang harus ditebak.
3. Kirim tautannya dengan tiga angka di dalam pesan: nominal, periode yang ditagih, dan jam berakhirnya masa berlaku tautan. Tanpa yang ketiga, tautan yang mati dalam 24 jam terbaca sebagai sistem yang rusak.
4. Tandai lunas dari webhook, bukan dari halaman balik. Perpanjangan dicatat saat webhook payment.paid bertanda tangan Kasera-Signature-V1 diterima dan diverifikasi, karena pelanggan yang menutup tab setelah membayar tetap harus mendapat perpanjangannya. Kenapa tanda tangan yang sah belum membuktikan nominalnya benar dibahas di artikel keamanan webhook.
5. Perpanjang dari tanggal jatuh tempo lama, bukan dari tanggal pembayaran. Pelanggan yang membayar tagihan September pada tanggal 5 September tetap berhak sampai akhir September. Menghitung dari tanggal pembayaran diam-diam memberi hadiah kepada yang telat membayar dan menggeser tanggal tagih setiap bulan.

Satu kunci idempotensi per pelanggan per periode

Tugas terjadwal adalah tempat tagihan ganda lahir. Tugas yang gagal di tengah lalu diulang otomatis, atau dijalankan ulang manual karena hasilnya diragukan, akan menerbitkan pembayaran kedua untuk periode yang sama. Yang mencegahnya hanya header Idempotency-Key pada permintaan create, diisi nilai yang berasal dari identitas pelanggan dan periodenya, misalnya sub-8241-2026-09.

Nilai itu harus deterministik. Kunci acak pada setiap percobaan tidak melindungi apa pun, karena percobaan kedua membawa kunci baru dan diperlakukan sebagai tagihan baru. Dan external_id maupun merchant_ref bukan penggantinya: keduanya label yang disimpan, dikembalikan, dan bisa disaring, tetapi tidak pernah menjadi pernyataan bahwa dua permintaan adalah satu pembayaran. Uraian lengkapnya ada di artikel Idempotency-Key.

Webhook kedaluwarsa memicu, tanggal jatuh tempo menjadwalkan

Kasera Pay mengirim tiga event pembayaran lewat webhook bertanda tangan: payment.paid saat pembeli sudah membayar, payment.expired saat permintaan lewat batas waktu tanpa dibayar, dan payment.failed saat rail menolak permintaannya. Yang terakhir bukan percobaan yang gagal: pembeli yang scan-nya gagal sekali masih bisa scan lagi, dan permintaannya tetap terbuka. Endpoint baru menerima ketiganya secara bawaan. Endpoint yang dibuat sebelum pilihan event tersedia hanya menerima payment.paid sampai dua event lainnya dicentang di dashboard.

Event kedaluwarsa adalah pemicu, bukan keputusan akhir. Pengirimannya at-least-once dan urutannya tidak dijamin, jadi setiap event disaring berdasarkan id-nya (juga ada di header Kasera-Event-Id), lalu status terbaru diambil ulang lewat GET /v1/transactions/{id} sebelum pengingat berikutnya dikirim. Kalau uang pembeli sudah diterima sebelum timer kedaluwarsa berjalan, uang yang menang: payment.paid menyusul payment.expired, dan pengingat yang terlanjur terjadwal dibatalkan. Simpan juga expires_at sebagai cadangan, misalnya untuk rekonsiliasi harian yang mencari pembayaran pending yang sudah lewat waktunya. Rincian tiap event ada di dokumentasi event webhook.

Satu pembedaan tetap berlaku: permintaan pembayaran yang kedaluwarsa bukan tagihan langganan yang menunggak. Satu periode bisa melewati beberapa tautan yang kedaluwarsa sebelum akhirnya dibayar, jadi status periode dicatat di sisi penagih, dan tangga pengingatnya dihitung dari tanggal jatuh tempo periode.

Tangga yang masuk akal untuk langganan bulanan, dihitung dari tanggal jatuh tempo periode, bukan dari kapan tautan dibuat:

Setiap pengingat menerbitkan tautan baru alih-alih mengirim ulang yang lama, karena yang lama hampir pasti sudah kedaluwarsa pada plafon 24 jam. Itu tidak menambah biaya: biaya hanya muncul pada pembayaran yang berhasil, jadi tautan yang tidak dibayar berbiaya nol.

Bulanan atau tahunan, dihitung dengan angka

Argumen finansial untuk paket tahunan biasanya diperkirakan terlalu besar. Pada tarif yang berlaku saat panduan ini ditulis, QRIS ditagih tarif QRIS 0,7 persen ditambah Rp 250 per pembayaran berhasil, tanpa biaya pendaftaran dan tanpa biaya bulanan. Untuk langganan Rp 99.000 per bulan:

Selisihnya Rp 2.750 setahun, dan angka itu bukan kebetulan: komponen persentasenya identik karena totalnya identik, sehingga yang hemat hanya sebelas komponen tetap Rp 250 yang tidak jadi ditagih. Itulah seluruh keuntungan biaya dari menagih tahunan. Melawannya berdiri kewajiban mengembalikan sisa bulan bila layanan berhenti di tengah jalan, dan untuk kiriman barang fisik, persetujuan tertulis yang harus diurus lebih dulu.

Pilihan channel berpengaruh jauh lebih besar daripada pilihan periode. Virtual Account ditagih tetap Rp 5.000 per transaksi tanpa komponen persen, sehingga langganan bulanan Rp 99.000 lewat Virtual Account berbiaya Rp 60.000 setahun, lebih dari lima kali lipat QRIS. Pada pembayaran tahunan Rp 1.188.000 posisinya berbalik. Titik impas kedua bentuk tarif itu dibahas di panduan memilih QRIS atau Virtual Account. Untuk langganan bulanan bernominal di bawah ratusan ribu, QRIS hampir selalu jawabannya.

Yang tetap harus dicatat di sisi penagih

Pada jalur manual, Kasera Pay mencatat pembayaran, bukan langganan. Empat hal berikut harus disimpan sendiri, karena tanpanya penagihan berulang berubah menjadi pekerjaan manual dalam dua atau tiga bulan. Akun yang memakai API Langganan menyimpan keempatnya di Kasera Pay, lewat Subscription dan Invoice beserta paid_through.

• Tanggal jatuh tempo berikutnya per pelanggan. Ini sumber kebenaran tugas harian, dan satu-satunya kolom yang benar-benar wajib.
• Status langganan yang terpisah dari status pembayaran. Aktif, dalam masa tenggang, dan berhenti adalah keadaan langganan. Pembayaran mengenal lima nilai lain, yaitu pending, succeeded, expired, canceled, dan failed, dan tidak tahu apa pun tentang akses.
• Riwayat periode yang sudah lunas. Dibutuhkan saat pelanggan bertanya bulan mana yang belum terbayar, dan saat pengembalian dana dihitung.
• Permintaan berhenti berlangganan. Karena tidak ada instruksi debet yang bisa dibatalkan, berhenti berlangganan berarti tugas harian berhenti menerbitkan tautan untuk pelanggan itu. Tanpa kolom ini, permintaan berhenti tidak punya tempat dicatat dan tagihan tetap terbit.

Bila penagihannya bernominal sama dan tidak mengatur akses, misalnya iuran kelas atau iuran warga, bentuk yang jauh lebih ringan biasanya lebih tepat: satu halaman pembayaran permanen yang dipakai ulang tiap bulan, tanpa penerbitan tautan per orang sama sekali. Bentuk itu diuraikan di panduan iuran komunitas. Sebaliknya, bila yang ditagih justru mengatur akses ke materi, misalnya kelas berbatas waktu atau keanggotaan berisi kursus, penyerahan aksesnya punya persoalan sendiri dan diuraikan di panduan menjual kelas dan kursus online. Bila yang ditagih adalah sewa hunian, tanggal jatuh temponya mengikuti tanggal masuk tiap penyewa sehingga tidak ada satu hari tagih pun dalam sebulan, dan akibatnya pada susunan penagihan diuraikan di tulisan tentang menagih sewa kos dan kontrakan bulanan.

Pertanyaan yang sering muncul