Puluhan tagihan aktif sekaligus: daftar transaksi yang secara bawaan menyembunyikan tiga status dari lima, kolom pencarian yang hanya menyentuh dua kolom, dan label pesanan yang boleh kembar tanpa satu pun baris keliru

Menagih satu pembeli mudah. Menagih empat puluh pembeli sekaligus, dengan sebagian sudah membayar, sebagian belum, dan sebagian tautannya sudah lewat jam, adalah pekerjaan yang berbeda jenis. Yang menyulitkan bukan jumlah barisnya, melainkan tiga hal yang jarang disebutkan sampai terlanjur membingungkan: daftar transaksi menyembunyikan sebagian status secara bawaan, kolom pencarian hanya menyentuh dua kolom, dan dua kolom label pesanan tidak pernah dimaksudkan sebagai penjamin keunikan. Ketiganya bisa diselesaikan hari ini, dan dua di antaranya diselesaikan sebelum tagihan berikutnya dibuat.

Bawaannya bukan seluruh daftar, dan di situlah tagihan terbaca hilang

Sebuah permintaan pembayaran punya lima status: pending, succeeded, expired, canceled, dan failed. Daftar transaksi di dasbor secara bawaan hanya memuat dua yang pertama, yang di layar berlabel Menunggu dan Dibayar. Tiga sisanya tidak ikut ditampilkan sampai diminta.

Pilihan itu benar untuk pekerjaan harian, karena tagihan kedaluwarsa dan yang dibatalkan adalah derau saat yang dicari adalah uang yang masuk dan yang sedang menuju masuk. Tetapi akibatnya satu: tagihan yang tautannya lewat jam menghilang dari layar tanpa pernah dicari ke mana. Karena itu di atas daftar ada keterangan tetap yang menyebutkan bahwa tampilan sedang menyaring, beserta dua tautan pendek untuk menampilkan semua status dan untuk mengembalikan seluruh filter ke bawaannya. Keterangan itu sengaja tidak disembunyikan: daftar tersaring yang terlihat seperti daftar utuh adalah cara tercepat menyimpulkan sebuah pembayaran lenyap.

Chip status bersifat pilih-banyak, bukan pilih-satu, dan melepas centang seluruhnya berarti semua status, bukan daftar kosong. Jadi tidak ada kombinasi chip yang bisa menghasilkan layar kosong palsu.

Kolom pencarian menyentuh dua kolom, dan bukan yang biasanya diketik orang

Kolom pencarian di atas daftar mencocokkan potongan teks pada dua tempat saja: deskripsi tagihan, dan nomor pesanan milik penjual sendiri. Di luar itu tidak ada. Mengetik id payreq_ tidak menemukan apa pun. Mengetik nama pembeli tidak menemukan apa pun. Mengetik nominal tidak menemukan apa pun.

Konsekuensinya tajam dan sering terlambat disadari: pada akun dengan puluhan tagihan aktif, apa yang ditulis di deskripsi saat tagihan dibuat menentukan apakah baris itu bisa ditemukan kembali nanti. Deskripsi berbunyi “Pembayaran” atau “Pesanan” akan cocok dengan empat puluh baris sekaligus, yang sama saja dengan tidak cocok dengan apa pun.

Deskripsi adalah satu-satunya kolom pencarian yang isinya ditentukan sendiri

Kebiasaan yang menyelamatkan pencocokan sederhana: masukkan ke deskripsi satu penanda yang nanti benar-benar diketik saat mencari. Tiga yang terbukti berguna bersamaan, dipisah tanda baca apa pun, dengan batas 255 karakter yang sangat longgar untuk itu:

• Penanda kelompok, misalnya IURAN-SEP atau PO-BATCH3, sehingga seluruh tagihan satu gelombang bisa dipanggil sekaligus dengan satu kata.
• Nama pembeli atau nama unit, karena kolom pencarian tidak menyentuh data pembeli dan deskripsi adalah satu-satunya tempat nama itu bisa dijadikan bahan pencarian.
• Nomor urut internal, yang membuat satu baris bisa dipanggil persis tanpa menyaring apa pun.

Deskripsi ikut terbaca pembeli di halaman pembayaran, jadi penanda internalnya sebaiknya singkat dan tidak memalukan untuk dibaca orang lain. Susunan seperti Iuran September - Blok C7 - IURAN-SEP memenuhi keduanya sekaligus.

Dua label pesanan boleh bernilai sama, dan itu bukan kesalahan daftar

Integrasi lewat API punya dua kolom label: external_id untuk nomor pesanan sendiri, dan merchant_ref untuk referensi sendiri sepanjang maksimal 64 karakter. Keduanya disimpan, dikembalikan di setiap respons, dan bisa dipakai sebagai filter cocok-persis di endpoint daftar. Yang tidak dilakukan keduanya adalah mencegah duplikat: dua create dengan merchant_ref yang sama menghasilkan dua permintaan pembayaran, bukan satu.

Jadi saat daftar menampilkan dua baris dengan label yang identik, daftarnya benar dan memang ada dua tagihan hidup. Satu-satunya hal yang membuat dua percobaan dihitung sebagai satu pembayaran adalah header Idempotency-Key, yang dibahas tersendiri di dokumentasi idempotency. Pada akun dengan banyak tagihan aktif, label kembar tanpa kunci idempotensi adalah penyebab paling sering dua tagihan sah yang menagih hal yang sama, dan penanganannya dibahas di artikel tentang pembayaran yang masuk dua kali.

Karena pencarian di layar hanya berupa potongan teks atas dua kolom, pertanyaan “mana baris dengan referensi persis ini” dijawab dari API, bukan dari kolom pencarian:

curl "https://pay.kasera.id/v1/transactions?merchant_ref=INV-2026-0413" \
  -H "Authorization: Bearer kp_live_..."

Bentuk lengkap parameter penyaringnya ada di dokumentasi endpoint daftar transaksi.

Setiap tampilan tersaring adalah sebuah tautan

Seluruh pilihan filter menempel di alamat halaman, jadi tampilan hasil penyaringan bisa disimpan sebagai bookmark dan dikirim ke rekan tanpa perlu dijelaskan cara membuatnya. Alamat /transactions polos berarti tampilan bawaan, dan status ditulis sebagai daftar berkoma. Detail satu tagihan pun menempel sebagai parameter tersendiri, sehingga satu baris bisa dibuka langsung dari tautan.

Tombol ekspor CSV di atas daftar membawa filter yang sama persis dengan yang sedang tampak di layar, termasuk rentang tanggal dan mode Live atau Sandbox yang sedang aktif. Berkasnya berisi baris yang sama dengan yang terlihat, bukan seluruh akun, yang membuat penutupan gelombang penagihan bisa dikerjakan di lembar sebar tanpa menyaring ulang di sana.

Sumbu kedua yang hanya berlaku pada baris yang sudah dibayar

Di samping status ada penyaring settlement, yang membedakan uang yang sudah diserahkan bank dari yang belum. Penyaring ini sengaja hanya bekerja pada baris yang sudah dibayar, karena tagihan yang belum dibayar atau sudah kedaluwarsa tetap membawa kata itu tanpa artinya berarti apa-apa. Menggabungkannya dengan status expired karena itu tidak menjawab pertanyaan siapa pun.

Satu pembeli, satu daftar

Untuk pembeli yang tersimpan sebagai pelanggan, halamannya sendiri memuat pembayaran yang pernah dilakukannya, dengan satu tautan untuk membukanya sebagai daftar transaksi yang sudah tersaring ke pembeli tersebut. Arahnya satu jalur: penyaring pelanggan datang dari halaman pelanggan, bukan dari pemilih di dalam daftar. Saat sedang aktif, penyaring itu tampil sebagai chip bernama yang bisa dilepas dengan satu ketukan, jadi tidak ada keadaan tersaring yang tidak terbaca di layar. Riwayat itu hanya utuh kalau satu pembeli memang tercatat sebagai satu pelanggan, dan kebiasaan yang menjaganya ada di tulisan tentang menyimpan pembeli sebagai pelanggan.

Kebiasaan penutupan harian yang membuat daftarnya tetap terbaca

Tagihan yang tidak jadi dibayar punya dua cara berakhir, dan pada akun yang belum selesai verifikasi keduanya tidak setara. Jatah sebelum verifikasi ada dua macam dan dihitung seumur akun, bukan harian: sepuluh permintaan pembayaran, dan Rp 1.000.000 nominal.

Bacaan praktisnya untuk akun yang belum terverifikasi: membatalkan tagihan yang sudah pasti batal lebih baik daripada membiarkannya lewat jam, karena hanya pembatalan yang mengembalikan jatah jumlahnya, dan jatah itu tidak pernah reset. Pada akun yang sudah terverifikasi tidak ada jatah yang perlu dihemat, dan pilihannya kembali menjadi soal kerapian daftar saja. Mekanisme pembatalannya dibahas di artikel tentang membatalkan tagihan yang terlanjur dibuat.

Satu hal lagi yang menentukan seberapa cepat daftar menumpuk: masa berlaku bawaan sebuah tautan adalah 60 menit. Untuk penagihan bergelombang yang jawabannya baru datang keesokan hari, angka bawaan itu berarti puluhan baris kedaluwarsa setiap hari, dan pertimbangan memilih angkanya ada di artikel tentang masa berlaku tagihan.

Ringkasnya

• Daftar bawaan memuat pending dan succeeded saja. Tagihan yang dicari dan tidak ketemu hampir selalu ada di tiga status yang sedang tidak ditampilkan.
• Pencarian di layar menyentuh deskripsi dan nomor pesanan. Id pembayaran, nama pembeli, dan nominal tidak ikut dicocokkan.
• Deskripsi ditentukan penjual sendiri, jadi penanda kelompok dan nama pembeli yang diselipkan di sana adalah investasi pencocokan termurah yang ada.
• Label pesanan boleh kembar. Hanya Idempotency-Key yang membuat dua percobaan menjadi satu pembayaran.
• Tampilan tersaring, detail satu tagihan, dan berkas CSV-nya semuanya mengikuti filter yang sedang aktif, jadi keduanya bisa dikirim apa adanya.

Kalau daftarnya sudah terlalu panjang untuk dikerjakan di layar, langkah berikutnya adalah membaca keadaan tagihan dari sistem sendiri, dan bentuk tabel yang cukup untuk itu dibahas di artikel tentang menyimpan data pembayaran di sistem sendiri.