Menetapkan harga setelah biaya transaksi: menghitung bruto dari target bersih

Sebuah barang dipasang seharga Rp 100.000 dan yang masuk ke saldo Rp 99.050. Selisihnya biaya transaksi, dan sampai di situ tidak ada yang mengejutkan. Yang mengejutkan datang pada langkah berikutnya, ketika penjual memutuskan menaikkan harga agar tetap menerima Rp 100.000 penuh, lalu memasang Rp 100.950 dan mendapati yang masuk Rp 99.993. Masih kurang. Menambahkan lagi selisihnya akan kurang lagi, dengan angka yang semakin kecil tetapi tidak pernah nol.

Penyebabnya bukan kesalahan hitung melainkan kesalahan operasi. Menaikkan harga untuk menutup biaya adalah pembagian, bukan penjumlahan, karena biayanya dihitung dari harga yang baru, bukan dari harga yang lama. Artikel ini tentang rumus yang benar, angkanya pada tarif yang berlaku, dan keputusan yang harus diambil sebelum rumusnya dipakai.

Dua mode, dan arti nominal yang ikut berubah

Sebelum menghitung apa pun, ada satu pilihan yang menentukan segalanya: siapa yang menanggung biaya. Kasera Pay menyediakan keduanya, dan yang berubah di antara keduanya bukan hanya siapa yang membayar, melainkan arti dari nominal yang diketik.

• Penjual menanggung biaya. Ini perilaku bawaan. Nominal yang diketik adalah bruto, yaitu yang dibayar pembeli, dan biaya dipotong darinya. Pembeli melihat angka bulat, penjual menerima sisanya.
• Pembeli menanggung biaya. Di dashboard ini adalah kotak centang Terima utuh; lewat API ini adalah fee_bearer bernilai customer. Nominal yang diketik berubah arti menjadi bersih, yaitu yang diterima penjual, dan biayanya dinaikkan ke atas nominal yang dilihat pembeli.

Perubahan arti itu yang paling sering terlewat saat berpindah mode. Nominal 100.000 yang sama menghasilkan dua permintaan pembayaran yang berbeda, dan yang membedakannya hanya satu kolom pada permintaan create. Apa pun modenya, satu identitas selalu berlaku: bruto sama dengan biaya ditambah bersih.

Rumusnya, dan kenapa penjumlahan selalu kurang

Tarif Kasera Pay berbentuk persentase ditambah nominal tetap. Untuk QRIS pada tarif yang berlaku saat artikel ini ditulis, itu berarti MDR 0,7 persen yang diteruskan apa adanya ditambah Rp 250 per pembayaran berhasil. Menghitung bruto dari target bersih berarti menyelesaikan persamaan, bukan menjumlahkan:

bruto = (bersih + tetap) / (1 - persen)

Untuk target bersih Rp 100.000 pada QRIS, itu adalah (100.000 + 250) dibagi 0,993, yaitu Rp 100.957 setelah dibulatkan ke atas. Biayanya menjadi Rp 957, bukan Rp 950, karena 0,7 persen dihitung dari Rp 100.957 dan bukan dari Rp 100.000. Selisih tujuh rupiah itu terlihat sepele pada satu transaksi, tetapi bentuk kesalahannya tumbuh mengikuti nominal dan mengikuti besar persentasenya: pada target bersih Rp 1.000.000 penjumlahan naif menghasilkan Rp 1.007.250 yang menyisakan Rp 999.949, kurang Rp 51, sementara jawaban yang benar Rp 1.007.302.

Metode dengan tarif murni tetap tidak mengalami hal ini sama sekali. Virtual Account ditagih Rp 5.000 tanpa komponen persen, jadi menaikkan harga untuk menutupnya memang cukup dengan menambahkan Rp 5.000. Pembagian hanya diperlukan ketika ada komponen persentase, dan semakin besar persentasenya semakin jauh jarak antara penjumlahan dan jawaban yang benar. Pada kartu, yang tarifnya 2,8 persen ditambah Rp 2.500, target bersih Rp 500.000 membutuhkan bruto Rp 516.976.

Angkanya, dua arah sekaligus

Tabel berikut memakai tarif QRIS default. Kolom kiri adalah mode bawaan, tempat nominal yang diketik adalah yang dibayar pembeli. Kolom kanan adalah mode Terima utuh, tempat nominal yang diketik adalah yang diterima penjual.

Tarif itu tarif default, dan tarif sebuah akun bisa berbeda bila sudah dinegosiasikan. Karena itu, sistem yang menghitung harga sendiri sebaiknya membaca GET /v1/payment_methods, yang mengembalikan percent_bps dan flat per metode, alih-alih menyalin angka dari artikel mana pun. Rinciannya ada di dokumentasi metode pembayaran. Cara membaca bentuk tarif QRIS yang persentase melawan Virtual Account yang tetap, termasuk titik impasnya, dibahas terpisah di panduan memilih QRIS atau Virtual Account.

Hanya satu sisi yang bisa berupa angka bulat

Di sinilah keputusan harga sesungguhnya terjadi, dan tidak ada pengaturan yang bisa menghindarinya. Biaya transaksi tidak pernah berupa angka bulat, jadi bruto dan bersih tidak mungkin keduanya bulat. Pilihannya tiga, dan masing-masing punya harga.

1. Bruto bulat, bersih tidak. Pasang Rp 100.000, terima Rp 99.050. Ini pilihan yang tepat untuk penjualan ke konsumen, karena harga yang tampil di etalase dan di iklan tetap angka yang biasa dibaca orang.
2. Bersih bulat, bruto tidak. Nyalakan Terima utuh, terima Rp 100.000 tepat, dan pembeli melihat Rp 100.957. Ini masuk akal untuk tagihan yang nominalnya memang sudah ditentukan sebelumnya, misalnya invoice pekerjaan lepas atau termin proyek, karena angka yang harus cocok adalah angka di kontrak.
3. Bruto dibulatkan ke atas, bersih menyusul. Jalan tengah yang paling jarang dipakai padahal paling sering tepat. Alih-alih memasang Rp 100.957, pasang Rp 101.000: biayanya tetap Rp 957 dan yang diterima menjadi Rp 100.043, sudah di atas target, dengan harga yang masih terbaca sebagai angka wajar.

Untuk penjualan bernominal kecil, satu pertimbangan tambahan berlaku. Komponen tetap Rp 250 memakan porsi yang jauh lebih besar pada nominal kecil daripada pada nominal besar: pada penjualan Rp 15.000 biayanya Rp 355, yaitu 2,4 persen, sementara pada Rp 500.000 biayanya 0,75 persen. Menaikkan nilai transaksi rata-rata dengan paket atau minimum pembelian menekan porsi itu jauh lebih efektif daripada mengutak-atik harga satuan.

Pembulatan selalu ke atas, dan besarnya paling banyak satu rupiah

Rupiah tidak punya satuan pecahan yang beredar, jadi biaya yang jatuh pada angka berkoma harus dibulatkan. Arahnya selalu ke atas. Pada mode bawaan, pembulatan ke atas berarti biaya bertambah paling banyak satu rupiah, dan yang menanggungnya penjual. Pada mode Terima utuh, yang dibulatkan ke atas adalah brutonya, sehingga penjual menerima persis nominal yang diminta dan rupiah pembulatannya jatuh ke pembeli.

Satu hal yang perlu diketahui pembuat integrasi: pada mode Terima utuh biayanya adalah hasil pengurangan bruto dikurangi bersih, bukan persentase yang dihitung ulang secara terpisah. Menghitungnya kembali dari persentase akan menghasilkan angka yang meleset satu rupiah pada nominal yang tidak habis dibagi, dan angka itu tidak akan cocok dengan yang tercatat.

Batas nominal diperiksa pada bruto

Satu jebakan yang hanya muncul pada mode Terima utuh, dan hampir selalu ditemukan pada transaksi terbesar. Batas nominal per pembayaran adalah minimum Rp 10.000 dan maksimum Rp 10.000.000, dan yang diperiksa terhadap batas itu adalah bruto, karena bruto yang benar-benar berpindah. Permintaan menerima bersih Rp 10.000.000 karena itu ditolak dengan amount_too_large: brutonya Rp 10.070.746, sudah melewati plafon. Batas lengkapnya ada di dokumentasi batas.

Hal yang sama berlaku dari arah bawah pada nominal sangat kecil, meskipun lebih jarang menggigit. Yang perlu diingat sederhana: pada mode Terima utuh, angka yang diketik bukan angka yang diuji.

Satu hal yang bukan urusan tarif

Membebankan biaya ke pembeli adalah pengaturan yang tersedia, dan keputusan memakainya bukan keputusan teknis melainkan keputusan dagang. Aturan praktis yang membedakannya: bila pembeli sudah melihat sebuah harga sebelum sampai ke pembayaran, biaya yang muncul belakangan mengubah harga itu, dan yang dipertaruhkan bukan Rp 957 melainkan keseluruhan transaksi. Bila nominalnya justru baru ditentukan pada saat penagihan, misalnya invoice atau termin proyek, biaya yang tampil terpisah malah lebih jujur daripada harga yang diam-diam sudah dinaikkan.

Kebiasaan yang menutup pembahasan ini: biaya pencairan Rp 3.000 per pencairan bukan bagian dari harga jual dan tidak perlu dimasukkan ke dalamnya, karena besarnya tidak bergantung pada jumlah transaksi melainkan pada seberapa sering saldo ditarik. Mencairkan setiap ada penjualan masuk berarti membayar biaya itu berulang kali untuk uang yang sama, dan cara memilih jadwalnya dibahas di panduan pencairan dana.