Batas harian 100 permintaan dan Rp 50.000.000: apa yang dihitung dan kapan angkanya kembali nol

Permintaan pembayaran yang ditolak dengan 429 dan kode daily_count_cap berarti jatah hari itu sudah habis, bukan permintaannya terlalu cepat. Angkanya sendiri sudah diterbitkan di halaman referensi batas: 100 permintaan per hari dan total Rp 50.000.000 per hari sebagai nilai bawaan, dihitung dalam zona waktu Asia/Jakarta.

Yang tidak dijawab angka itu ada tiga, dan justru ketiganya yang menentukan tindakan: pembayaran mana yang ikut dihitung, kapan hitungannya kembali nol, dan jalur mana yang menghabiskan jatah tanpa memunculkan pesan galat ke penjual sama sekali.

Dua penolakan 429 yang artinya berlawanan

Status HTTP-nya sama, tindakannya berkebalikan, dan yang membedakan hanya kode di dalam badan respons.

• rate_limited adalah batas laju: 300 permintaan per menit per API key. Penyebabnya kecepatan, dan menunggu beberapa detik memang menyelesaikannya.
• daily_count_cap dan daily_amount_cap adalah jatah satu hari kalender. Penyebabnya volume, bukan kecepatan, dan mencoba ulang setelah beberapa detik, beberapa menit, atau satu jam sama saja hasilnya.

Konsekuensinya untuk kode yang memanggil API: aturan “coba ulang setiap kali menerima 429” tidak cukup. Backoff yang tidak membaca kode akan berputar sampai tengah malam melawan penolakan yang tidak akan pernah berubah, dan setiap putarannya menambah beban tanpa menghasilkan satu pembayaran pun. Yang benar adalah bercabang pada kodenya: rate_limited diulang, dua kode jatah harian dihentikan dan dilaporkan ke manusia.

Yang dihitung adalah permintaan yang dibuat, bukan yang dibayar

Hitungan hari berjalan pada permintaan pembayaran yang berhasil dibuat, apa pun yang terjadi sesudahnya. Tautan yang tidak pernah dibuka pembeli menempati satu slot yang persis sama dengan tautan yang dibayar lunas.

Batas nominal bekerja dengan cara yang sama: yang dijumlahkan adalah nominal dari permintaan yang dibuat pada hari itu, bukan uang yang benar-benar masuk. Sepuluh tautan bernilai Rp 5.000.000 yang diterbitkan pada pagi hari sudah memenuhi jatah Rp 50.000.000 hari itu meskipun tidak satu pun dibayar.

Yang dijumlahkan juga bruto, yaitu angka yang dilihat pembeli, bukan yang diterima penjual. Pada mode pembeli menanggung biaya, nominal yang diketik adalah bersih dan bruto-nya berada di atasnya, jadi angka yang masuk ke hitungan harian selalu sedikit lebih besar daripada yang tertulis di sistem penjual. Selisihnya kecil per transaksi dan baru terasa di dekat batas; hitungannya ada di cara menetapkan harga setelah biaya transaksi.

Dari sini muncul kebiasaan yang paling sering menghabiskan hari tanpa penjualan: menerbitkan tautan secara spekulatif. Membuat tautan untuk setiap calon pesanan, menerbitkan ulang tautan baru setiap kali pembeli bertanya, atau menyiapkan tautan sebulan di muka, semuanya membayar dengan slot yang sama seperti pesanan sungguhan.

Yang tidak dihitung

Dua hal berada di luar hitungan, dan keduanya penting untuk diketahui sebelum panik.

• Pembuatan di mode tes. Pembayaran yang dibuat dengan kunci mode tes tidak mengurangi jatah live dan tidak pernah ditolak olehnya. Gladi bersih sebanyak apa pun tidak memakan jatah hari peluncuran.
• Percobaan ulang dengan Idempotency-Key yang sama. Kiriman ulang dijawab dari pembayaran yang sudah ada tanpa jatah harian pernah ikut diperiksa. Lima puluh percobaan atas satu pembayaran tetap satu pembayaran dan satu slot.

Bagian kedua punya sisi tajam yang sering terlewat: yang menyatukannya hanya header itu. Kunci acak baru pada setiap percobaan menjadikan setiap percobaan pembayaran baru yang dihitung terpisah, sekaligus melewati perlindungan tagihan ganda tanpa satu pun pesan galat. Bentuk kegagalannya dibahas terpisah di idempotency untuk pembayaran.

Kapan hitungan kembali nol

Pada pukul 00.00 Asia/Jakarta. Yang dipakai adalah hari kalender WIB, bukan jendela 24 jam yang bergulir dari permintaan pertama, dan bedanya nyata di dua tempat.

Pertama, jam kejadiannya menentukan berapa lama tertahan. Ledakan pesanan yang memenuhi jatah pada pukul 22.00 mendapat jatah penuh dua jam kemudian. Ledakan yang sama pada pukul 09.00 menutup sisa hari kerja itu seluruhnya. Untuk penjualan tiket atau peluncuran produk, jam mulai penjualan adalah keputusan operasional, bukan hanya soal ramai atau tidak.

Kedua, server yang berjalan dalam UTC. Pekerjaan terjadwal yang disetel pada pukul 00.30 UTC berjalan pada pukul 07.30 WIB, yaitu pagi hari yang sama dengan seluruh penjualan hari itu, dan bukan pada awal hari yang baru. Penagihan massal yang disusun dengan asumsi “tengah malam di server” berbagi jatah dengan penjualan sepanjang hari tersebut.

Satu hal yang tidak tersedia: tidak ada cara mengembalikan slot sebelum tengah malam. Tautan yang tidak dibayar tetap terhitung sampai hari itu berakhir, termasuk setelah masa berlakunya habis. Jatah hari ini hanya bergerak ke satu arah.

Jalur yang menghabiskan jatah tanpa terlihat

Halaman pembayaran permanen memakai jatah yang sama. Setiap pembayar yang mengisi nominal di halaman itu membuat satu permintaan pembayaran atas nama penjual, jadi seratus orang yang membayar iuran dalam satu malam adalah seratus slot, dan pembayar yang salah ketik lalu mengulang memakai dua.

Yang membuatnya sulit terdeteksi adalah pesan yang muncul di sisi pembayar. Ketika jatah hari itu habis, halaman menjawab bahwa halaman sedang sibuk dan meminta mencoba lagi nanti. Pesan itu memang sengaja tidak menyebut sebab sebenarnya, karena urusan jatah adalah urusan penjual dan bukan urusan orang yang sedang membayar. Akibatnya penjual mengetahuinya dari pembeli yang mengeluh, bukan dari catatan galat di sistemnya sendiri.

Untuk pengumpulan iuran, donasi, dan tiket, angka 100 sebaiknya dibaca sebagai jumlah orang yang bisa membayar dalam satu hari, bukan sebagai batas teknis yang jauh. Cara menyusun pengumpulannya ada di panduan menarik iuran komunitas.

Kalau batasnya tersentuh hari ini

Kode penolakannya sudah memisahkan dua persoalan yang berbeda, dan perbaikannya berbeda pula.

• daily_amount_cap dengan jumlah permintaan yang masih sedikit berarti transaksinya besar-besar. Nominal di atas Rp 10.000.000 sudah ditolak terpisah sebagai amount_too_large, jadi tagihan besar memang sudah dipecah menjadi termin; yang perlu diubah adalah menyebar termin itu ke beberapa hari alih-alih menerbitkan semuanya dalam satu pagi.
• daily_count_cap dengan total nominal yang masih jauh dari batas berarti transaksinya banyak dan kecil. Yang perlu ditinjau adalah tautan yang dibuat tanpa pesanan sungguhan di belakangnya, karena hanya itu yang bisa dikurangi hari itu juga.

Menaikkan batasnya

Batas harian bukan sakelar di halaman pengaturan. Tidak ada kotak centang di dashboard yang mengubahnya, jadi mencarinya di sana hanya membuang waktu pada hari yang sudah sibuk. Nilainya ditetapkan di sisi Kasera Pay, dan menaikkannya adalah permintaan yang diajukan lewat kanal dukungan yang tercantum di halaman depan, yaitu surel dan WhatsApp, dengan waktu balasan yang dinyatakan satu hari kerja.

Karena balasannya dihitung dalam hari kerja, permintaan yang diajukan pada hari peluncuran datang terlambat. Yang membuat permintaan mudah dijawab adalah angka, bukan kata “lebih banyak”: perkiraan jumlah pembayaran pada hari puncak, rata-rata nominal per pembayaran, tanggal acara atau peluncurannya, dan metode pembayaran yang dipakai. Empat angka itu cukup untuk menilai permintaannya sekali jalan.

Satu kebiasaan yang menutup masalah ini di sisi kode: jangan menuliskan angka 100 di dalam program. Nilai bawaan dapat berbeda per akun, dan yang menyatakan kebenaran hari itu adalah kode penolakan yang diterima, bukan angka yang disalin dari dokumentasi setahun lalu.

Batas harian adalah satu dari beberapa hal yang sebaiknya diperiksa sebelum pembeli pertama membayar, bukan sesudahnya. Urutan lengkapnya ada di checklist sebelum menerima pembayaran sungguhan yang pertama.