14 Kesulitan Membangun Sistem Pembayaran Sendiri

 (arnon.dk)
1 poin oleh GN⁺ 2024-02-27 | 1 komentar | Bagikan ke WhatsApp
  • Sistem pembayaran dan pendapatan memang wajib untuk monetisasi, tetapi karena merupakan sistem inti yang kompleks yang melibatkan keuangan, produk, dukungan pelanggan, legal, kepatuhan, hingga penjualan, gangguan kecil pun dapat berkembang menjadi masalah operasional besar
  • Perusahaan tahap awal atau tim produk baru mudah melihat pembayaran sebagai sekadar masalah engineering lalu membangunnya sendiri, tetapi pilihan sebenarnya terbagi menjadi membangun sendiri, pihak ketiga, atau hybrid
  • Sistem pembayaran nyata harus menangani idempotensi, pengelolaan tanggal, pengukuran penggunaan, pajak, pengembalian dana, hierarki pelanggan, kontrak kustom, perubahan harga, dan pengakuan pendapatan sekaligus
  • Sebagian masalah stabil setelah diselesaikan sekali, tetapi aturan pajak, kesalahan pelanggan, koreksi manual, dan persyaratan invoice per negara akan terus membesar seiring pertumbuhan dan ekspansi global
  • Lebih aman berfokus pada update penggunaan yang khas produk dan event siklus hidup pelanggan, sementara langganan, penagihan, akuntansi, dan pengakuan pendapatan sebisa mungkin diserahkan ke sistem pembayaran siap pakai dan ERP

Mengapa pembayaran bukan sekadar fitur sederhana

  • Sistem pembayaran dan pendapatan wajib ada agar bisnis dapat menghasilkan uang
  • Saat berjalan normal, sistem ini tidak terlalu terlihat, tetapi sebenarnya merupakan sistem seperti gurita yang menyentuh banyak organisasi dan fungsi sekaligus
    • Keuangan
    • Produk
    • Pengalaman pengguna
    • Dukungan pelanggan
    • Pelanggan
    • Legal
    • Kepatuhan
    • Penjualan
  • Jika satu bagian rusak, masalah dapat cepat meluas ke area yang terhubung, dan dalam praktiknya hal ini sering terjadi
  • Jika pendapatan tidak dapat ditagih secara legal dan akurat, masalah yang harus ditanggung operator bisnis akan meningkat besar

Tiga pola pembangunan

  • Biasanya ada tiga pendekatan untuk sistem pembayaran
    • Membangun sendiri
    • Sistem pihak ketiga sepenuhnya
    • Hybrid yang mencampur sistem buatan sendiri dan pihak ketiga
  • Perusahaan tahap awal atau tim yang memulai produk baru cenderung ingin membangunnya sendiri karena memiliki engineer dan ingin menjaganya tetap sederhana
  • Jika pembayaran dilihat seperti “masalah memasukkan file tagihan ke S3 lalu diambil oleh job CRON untuk melakukan pembayaran”, pembayaran akan disalahpahami hanya sebagai masalah engineering
  • Sama seperti kita tidak mengimplementasikan keamanan atau pengelolaan tanggal sendiri, sebaiknya pembayaran juga tidak dibangun seluruhnya sendiri sejak awal
  • Sistem pembayaran terbaik adalah sistem yang tidak perlu seluruhnya dibangun sendiri

14 kesulitan sistem pembayaran buatan sendiri

  • Idempotensi

    • Semua permintaan penagihan dan pengumpulan pembayaran harus unik dan idempoten
    • Masalah ini muncul saat melakukan retry karena batasan API atau saat menambah instance sistem pembayaran
    • Jika tidak ditangani dengan benar, muncul risiko penagihan ganda

  • Pengelolaan tanggal

    • Harus ditentukan apakah penagihan dilakukan setiap 30 hari atau setiap bulan berdasarkan tanggal pendaftaran
    • Kondisi seperti hari kabisat dan zona waktu juga harus ditangani bersama

  • Prorata dan sisa saldo

    • Harus ditentukan apakah prorata hanya diterapkan saat upgrade atau juga saat downgrade
    • Pilihannya mencakup refund, kredit, diabaikan, atau memblokir upgrade/downgrade

  • Pengukuran penggunaan

    • Cara menghitung penggunaan bisa berjumlah puluhan jenis
    • Bisa berbeda menurut tipe pelanggan atau sering berubah

  • Format invoice

    • Saat beroperasi hanya di satu negara, ini bisa terlihat mudah
    • Saat berekspansi, selain sales tax, harus menangani VAT, GST, dan pungutan tambahan per negara
    • Template terpisah per pasar mungkin dibutuhkan

Kompleksitas yang membesar dalam B2B dan ekspansi global

  • Hierarki pelanggan yang kompleks

    • Khususnya pelanggan B2B mungkin memiliki anak perusahaan dan partner serta ingin mengelola relasi penagihan
    • Dibutuhkan cara untuk menggabungkan penggunaan ke pihak yang sebenarnya membayar
    • Kebutuhan seperti ini sering baru muncul setelah pertumbuhan dan ekspansi
    • Jika badan hukum pelanggan atau lokasi penggunaan berbeda, pajaknya dapat berbeda
    • Secara hukum, mungkin perlu memisahkan tagihan dan invoice
    • Aturan terkait dapat berubah setiap beberapa bulan

  • Pengumpulan pembayaran dan pencegahan churn

    • Harus ditentukan kapan menyerah melakukan retry pembayaran
    • Jika terjadi chargeback, harus diputuskan apakah akun akan dihentikan, ditangguhkan, atau diberi refund

  • Pause dan resume

    • Saat pelanggan menjeda langganan, harus ditentukan tingkat akses apa yang diizinkan

  • Kredit dan refund

    • Jika hanya memberi refund penuh, relatif sederhana
    • Jika terjadi kesalahan sebagian, mungkin perlu memilih refund sebagian atau store credit
    • Apakah kredit memiliki masa kedaluwarsa juga harus diputuskan terpisah

Pajak, kontrak, dan kesalahan manusia

  • Penanganan pajak

    • Kompleksitas sudah muncul hanya dari penerapan tarif pajak yang berbeda pada item yang berbeda
    • Pada skala global, tarif dan aturan pajak sering berubah

  • Kontrak kustom

    • Jika hanya menjalankan PLG, ini mungkin bukan masalah
    • Begitu mulai menandatangani kontrak, pengecualian dan syarat khusus yang tidak mudah disetel dengan asumsi lama akan cepat muncul

  • Kesalahan manusia

    • Pelanggan melakukan kesalahan, dan koreksi atasnya diperlukan
    • Di dalam perusahaan sendiri pun konfigurasi pelanggan dapat salah disetel sehingga harus diperbaiki kemudian
    • Penerbitan kredit dan penerbitan ulang invoice adalah pekerjaan yang memakan banyak waktu
    • Perubahan informasi legal pelanggan juga harus ditangani
      • Alamat
      • VAT ID, dll.

  • Perubahan harga selektif

    • Perubahan harga sering kali tidak diterapkan ke semua pelanggan
    • Jika hanya berlaku untuk pelanggan baru, versi harga yang berbeda harus dipertahankan demi menghormati kontrak yang sudah ada

  • Pengakuan pendapatan dan pendapatan akrual

    • Aturan pengakuan pendapatan IFRS-15 memiliki spesifikasi PDF 64 halaman
    • Jika sampai membangun integrasi ERP kustom sendiri, kompleksitasnya makin besar

Masalah yang selesai sekali dan masalah yang terus membesar

  • Sebagian masalah berubah jauh lebih sering dari perkiraan, sementara sebagian lain hampir tidak perlu disentuh lagi setelah ditangani sekali
  • Idempotensi adalah contoh masalah engineering yang jarang perlu disentuh lagi setelah diselesaikan sekali
  • Aturan pajak sering berubah di seluruh dunia
    • Makin banyak negara yang dimasuki, makin banyak pula hukum pajak yang harus dilacak
  • Kesalahan pelanggan terjadi relatif konsisten
    • Seiring pertumbuhan, skalanya membesar
    • Dibutuhkan lebih banyak dukungan pelanggan dan koreksi manual
  • Pembayaran pada awalnya tampak seperti masalah engineering, tetapi sebenarnya berakar pada ruang masalah yang kompleks yang sulit dipahami bahkan oleh orang berpengalaman di industrinya

Area yang tidak perlu dibangun sendiri

  • Sebaiknya serahkan sebanyak mungkin masalah pembayaran ke sistem eksternal
  • Pendekatan yang disarankan adalah membeli sebanyak mungkin solusi siap pakai
  • Sebagian besar area langganan dan penagihan dapat ditangani oleh sistem pembayaran
  • Pengakuan pendapatan dan akuntansi sebaiknya diserahkan ke fitur bawaan ERP atau sistem lain yang sudah digunakan
  • Tim produk seharusnya hanya berfokus pada bagian yang unik untuk produk, seperti update penggunaan dan event dasar siklus hidup pelanggan

Bacaan terkait

1 komentar

 
GN⁺ 2024-02-27
Komentar Hacker News

  • Ini tulisan yang bagus untuk orang yang harus mengambil keputusan soal penagihan tetapi belum punya banyak pengalaman, dan juga berguna sebagai referensi bagi yang sudah berpengalaman.
    Namun kalimat “bukankah cukup menaruh file yang akan ditagihkan ke S3 lalu membiarkan job CRON memungut pembayaran?” benar-benar membuat saya tertawa. Dari sudut pandang engineer, itu bukan ide yang bagus dalam situasi apa pun.
    Keputusan arsitektur penagihan yang saya sukai adalah memisahkan penagihan dan hak akses sejauh mungkin di dalam sistem. Untuk langganan prabayar, menurut saya bagus jika hak akses itu sendiri hanya menyimpan tanggal kedaluwarsa dan detail hak yang diberikan selama periode aktif, sementara sistem penagihan menyimpan langganan lalu menyinkronkannya ke sisi hak akses saat diperlukan. Dengan cara ini, penagihan manual oleh manusia, debugging dan patching masalah sementara, atau menambahkan integrasi Stripe menjadi lebih mudah.
    Tentu saja kita harus tetap membuka ruang untuk ekspansi di masa depan, tetapi keputusan ini sendiri biasanya tidak terlalu membatasi sistem. Ini bukan ide orisinal saya, tetapi setelah mencoba pendekatan lain yang kurang berhasil, saya jadi sangat menyukainya.

    • Berdasarkan pengalaman, engineer biasanya terbagi menjadi mereka yang pernah menangani sistem penagihan dan yang belum.
      Banyak masalah muncul dari perbedaan antara pembayaran dan penagihan https://www.wingback.com/blog/saas-payment-vs-saas-billing. Saat pertama menerima pelanggan, Anda hanya perlu menerima beberapa pembayaran berulang, jadi mudah memulai dengan Stripe atau invoice manual.
      Namun seiring waktu, pelanggan enterprise yang membutuhkan hak akses yang lebih kompleks, banyak paket harga, perlindungan untuk pelanggan lama, serta siklus, syarat, dan pemberian hak akses penagihan yang disesuaikan akan semakin banyak masuk. Penagihan sering kali tidak menjadi fokus teknis, sehingga hack kecil dan fitur tambahan menumpuk, dan akhirnya berubah menjadi kekacauan yang menyedot sumber daya pengembangan produk, memperlambat penjualan, atau membatasi produk yang bisa dijual.
      Kompleksitas penagihan memiliki banyak jebakan dan pengecualian tersembunyi, dan belakangan ini menjadi makin rumit karena sebagian besar paket harga mencakup berbagai batas dan elemen berbasis penggunaan, sementara SaaS dijual ke seluruh dunia. Di perusahaan tahap lanjut, bahkan ada tim yang terdiri dari 15+ engineer khusus untuk penagihan. Saya setuju bahwa jika penagihan bukan inti produk, jangan membangun sistem penagihan sendiri. Sebagai catatan, saya adalah CTO Wingback, platform penagihan SaaS.
    • Jika model engineer yang diasumsikan oleh slogan “jangan buat sendiri” adalah seperti itu, tulisan ini justru memberi efek sebaliknya.
      Sekarang saya jadi ingin membuat sistem seperti itu, dan merasa jauh lebih memenuhi syarat daripada yang saya kira.
    • Arnon juga menulis artikel bagus yang membahas pemisahan penagihan dan hak akses itu.
      https://arnon.dk/why-you-should-separate-your-billing-from-e...
    • Selama beberapa tahun terakhir bekerja dengan perusahaan-perusahaan SaaS yang memakai Warrant sebagai solusi hak akses pelanggan, kami juga sampai pada pendekatan yang sama.
      Pelanggan menyimpan hak akses di sistem kami dan memeriksanya saat diperlukan, lalu ketika langganan diperbarui atau dihapus di pihak penyedia pembayaran, aturan dan hak akses ditambahkan. Ini memudahkan bekerja dengan satu atau beberapa penyedia pembayaran sekaligus membuat separation of concerns menjadi jelas. Saya juga membagikan artikel terkait karena lebih cocok dengan konteks ini: https://warrant.dev/use-cases/pricing-tiers-and-entitlements..., https://arnon.dk/why-you-should-separate-your-billing-from-e...
      Sistem hak akses yang ideal harus dinamis, artinya aturan disimpan di database, bisa menangani skenario sekali pakai seperti pelanggan enterprise, dan memiliki lapisan kebijakan di atasnya. Misalnya, hampir semua skenario harus bisa didukung, seperti paket Pro maksimal 5 seat, atau paket Growth mengizinkan fitur tertentu hingga N kali per hari.
      UI yang memungkinkan staf nonteknis melakukan perubahan per pelanggan tanpa keterlibatan engineering juga merupakan keunggulan besar. Dalam peran engineering saya sebelumnya, hal seperti ini selalu menghambat tim pengembangan.
    • Pendekatan yang kami capai juga mirip. Penagihan hanyalah mekanisme untuk menghitung invoice, lalu invoice yang dikirim, pembayaran yang diterima, dan penyesuaian dicatat secara akumulatif di ledger untuk mengelola piutang.
      Ada juga kumpulan hak akses, tetapi di antaranya ada mekanisme kebijakan yang menentukan kapan hak akses diterapkan atau tidak diterapkan. Intinya, hak akses bukan hanya masalah penagihan. Mekanisme kebijakan adalah perekat yang menghubungkan hak akses dengan semua hal lain, sehingga Anda bisa memberikan hak akses kepada eksekutif dari pelanggan terbesar tanpa mengaitkannya dengan penagihan.

  • Dulu saya pernah membuat sistem penagihan dan piutang untuk jaringan apotek kecil, dan perusahaan asuransi kadang mengirim cek bernilai cukup besar tanpa pemberitahuan apa pun.
    Padahal kami tidak menagih apa pun, cek 150 ribu dolar datang lewat pos, lalu beberapa bulan kemudian mereka baru menyadari kesalahannya dan meminta uang itu dikembalikan. Ada akun khusus bernama magic money untuk menaruh uang seperti ini. Dunia penagihan benar-benar lingkungan yang gila.

    • Itu bisa dianggap sebagai akun suspense, khususnya dalam kasus ini akun yang terikat pada pengirim dana. Statusnya adalah “kami menerima uang dari entitas ini, tetapi belum tahu alasannya.”
    • Saya penasaran apakah ada titik ketika “magic money” ini secara hukum menjadi milik perusahaan setelah jangka waktu tertentu berlalu.
    • Saya bertanya-tanya apakah mungkin jumlah yang ditagihkan ke entitas lain, misalnya individu, mengalir sampai ke perusahaan asuransi, tetapi tidak ada yang menelusurinya kembali, sehingga utang tetap tercatat di akun orang-orang tersebut.
      Jangan-jangan hanya disebut magic money sementara utang di akun individu tetap dibiarkan.
    • Saya penasaran kenapa cek itu diuangkan atau disetorkan.

  • Saya rasa kurang tepat mendekati topik ini hanya dari sisi penderitaan membuat sistem penagihan sendiri. Kalau banyak perusahaan ingin mengambil jalan itu, biarkan saja
    Saya mengakui bahwa sistem penagihan memang sangat kompleks. Namun jika Chargebee, Solvimon, Stripe, Recurly, Orb, Metronome, Lago, Togai, dan lainnya memiliki pengetahuan semacam itu, pengetahuan tersebut juga bisa dikumpulkan di satu tempat
    Jawabannya pada akhirnya adalah pendekatan yang cocok untuk masing-masing. Jika ini SaaS berbasis langganan, ada solusi yang sesuai untuk itu; jika ini API berbasis penggunaan, ada solusi penagihan yang sesuai pula
    Alih-alih mencegah praktik tersebut, kita bisa mengumpulkan pengetahuan, pendekatan, paradigma, pola pemrograman, praktik yang baik, dan praktik terbaik di satu tempat. Ada juga pengecualian, misalnya perusahaan di luar AS atau Eropa yang tidak bisa memakai solusi penagihan seperti Stripe. Misalnya jika Anda adalah perusahaan Venezuela dan tidak bisa membuat akun Stripe, pada akhirnya Anda harus membuat solusi penagihan sendiri dan menghubungkannya ke SOAP-XML API milik payment gateway lokal yang sulit dipahami
    Secara terpisah, “membuat sistem penagihan sendiri” terasa mirip dengan “membuat SIEM sendiri” memakai konfigurasi Elastic + Grafana. Saya tidak merekomendasikannya, tetapi saya paham mengapa departemen keamanan IT begitu sering memilih jalan itu

    • Tulisan ini membahas sistem penagihan dengan cara yang menarik. Sebagian topik yang disajikan sebagai masalah tampaknya lebih cocok diserahkan kepada akuntan atau pakar lain yang mungkin sudah dipekerjakan
      Sistem penagihan tidak serumit hal-hal yang biasa ditangani developer. Tulisan ini menggambarkan persyaratan hukum yang sulit sebagai kendala, tetapi dalam praktiknya itu juga berarti spesifikasinya mudah ditemukan dan terdokumentasi dengan baik. Ada bagian yang sering berubah, tetapi bagian seperti itu pun diberi label dan penjelasan dengan baik
      Saya setuju bahwa SaaS berbasis langganan dan API berbasis penggunaan masing-masing punya cara penagihan yang cocok. Namun kuncinya adalah apakah Anda akan membiarkan pelanggan mengalihkan beban tanggung jawab, apakah pendapatan itu cukup penting untuk diverifikasi, serta apakah Anda sanggup menanggung biaya atau kerugiannya

  • Salah satu hal yang tidak dibahas tulisan ini adalah penjualan afiliasi, yang bisa menjadi cukup banyak pekerjaan tergantung seberapa dalam implementasinya
    Ini adalah sistem yang memungkinkan orang lain menerima pembayaran berbasis komisi atas penjualan di dalam platform
    Anda harus melacak kode afiliasi hingga penjualan dan pengguna, mengirim pembayaran ke penyedia pembayaran yang ditetapkan afiliasi, dan jika ingin melakukannya dengan benar, juga menyediakan UI untuk melihat metrik pengunjung, tingkat konversi, dan riwayat pembayaran
    Untungnya, sebagian besar bisa dibuat secara bertahap. Cukup hubungkan kode unik ke pengguna, lalu hubungkan kode itu ke penjualan dengan tarif komisi tertentu; sisanya bisa diproses manual atau diabaikan. Misalnya, saya membayar afiliasi sebulan sekali lewat Zelle atau PayPal dan itu tidak sampai 10 menit. Tidak ada frontend pelacakan konversi, dan belum ada orang yang menolak ikut afiliasi karena itu

  • Yang benar-benar mengesankan adalah kebutuhan agar seluruh mesin Rube Goldberg ini bisa dijalankan secara terbalik
    “Pesanan” ingin dibuat sestatis mungkin, sementara “invoice” bahkan memiliki kewajiban hukum
    Misalnya seseorang membeli 5 unit dan mendapat diskon, tetapi kemudian hanya menginginkan 3 unit, dan ada salah ketik pada nama serta alamatnya. Tidak masalah: invoice dibatalkan, dibuat invoice baru dengan jumlah yang sama tetapi nama dan alamat diperbaiki, lalu menunggu barang retur tiba dan diperiksa, kemudian diproses sebagai kredit lagi dan dibuat invoice baru lagi
    Pengiriman retur berada dalam status ambigu untuk sementara, pelanggan memesan 5 unit lagi, satu unit tiba dalam keadaan pecah, dan ia menginginkan pengembalian dana, bukan pengganti. Tanggal pengiriman terbagi menjadi 2, sehingga sistem tidak menerapkan diskon untuk 5 unit atau lebih. Sesuatu yang awalnya terlihat seperti 2 pesanan sederhana dengan cepat berubah menjadi banyak transaksi dan dokumen. Pelanggan juga lupa kata sandinya dan membuat akun baru dengan email lain. Setahun kemudian, saat melihat log, sulit memahami mengapa ia mendapat diskon padahal hanya membeli 3 unit

  • Saya kurang yakin dengan saran ini. Separuh fitur yang disebutkan dalam tulisan mungkin tidak diperlukan, dan seiring bisnis membesar, semuanya bisa dibuat cukup bertahap
    Konsep seperti invoice, kredit, periode pajak, dan perubahan perhitungan prorata memang perlu dipahami. Namun pengetahuan itu bukan alasan bahwa semuanya harus di-outsource atau dibeli, melainkan bahan untuk menilai membangun vs membeli dengan lebih baik
    API eksternal yang dibutuhkan SaaS hanya satu pemroses kartu kredit, atau mungkin dua kalau ingin lebih rapi. Tentu setelah tahun pertama akan ada banyak pekerjaan manual, akuntan akan menunjukkan kesalahan-kesalahan bodoh, dan kita juga akan banyak belajar soal akuntansi
    Meski begitu, kalau hari ini saya memulai bisnis baru, saya akan membandingkan beberapa solusi, tetapi saya tetap yakin bahwa membuat sendiri tidak semenakutkan itu

    • Dari posisi pernah membuat dan mengintegrasikan sistem billing, ini terdengar seperti ucapan yang lahir dari ketidaktahuan yang membahagiakan
      Membangun sistem selalu terlihat mudah, dan pada hari pertama memang benar-benar mudah. Namun tak lama kemudian Anda akan menghabiskan banyak waktu menjelaskan kepada penanggung jawab keuangan mengapa laporannya benar-benar berantakan, dan kepada tim dukungan mengapa invoice gagal, mengapa harga langganan ditagihkan secara salah, serta berbagai kasus pengecualian yang bahkan tidak Anda ketahui keberadaannya
      Setelah itu, Anda harus menyesuaikan diri dengan regulasi yang berubah, atau gateway yang Anda pilih mungkin tidak mendukung wilayah tempat Anda sedang tumbuh
      Sebelum berkata “tinggal dibuat lebih baik saja”, ingat bahwa itu juga memakan waktu. Waktu yang tidak dipakai untuk produk, waktu yang tidak dipakai untuk memperbaiki model harga, dan waktu yang dihabiskan untuk jalan di tempat alih-alih melakukan hal-hal yang menumbuhkan bisnis
    • Apa pun jalan yang dipilih, bicaralah dulu dengan akuntan untuk memastikan informasi apa saja yang secara hukum wajib melekat pada pembayaran
      Hal lain mungkin bisa diabaikan, tetapi kalau nanti tidak bisa menghitung pajak atau melanggar aturan Know Your Customer/KYC, itu akan benar-benar menyulitkan
      Selain itu, hanya karena sebuah sistem lebih mahal dari perkiraan dan dipakai banyak perusahaan yang tampak pintar, bukan berarti sistem itu cocok untuk tujuan Anda. Apalagi tidak ada jaminan bahwa sistem itu cocok untuk tujuan spesifik yang Anda inginkan. Membeli bukan berarti Anda boleh tidak melakukan riset
    • Inti B2B SaaS adalah uang datang dari penjualan bernilai tinggi yang banyak membutuhkan sentuhan manusia, dan penjualan itulah yang menciptakan kebutuhan
      Tujuan orang yang menangani billing seperti ini sederhana. Mereka harus menyediakan opsi yang tepat agar tim sales bisa menutup kontrak. Mereka harus bekerja sama dengan tim sales untuk menemukan area yang “mudah diimplementasikan dan cukup untuk menutup kontrak”
      Poin ini tidak bisa cukup ditekankan. Tim sales benar-benar menghasilkan pendapatan. Jangan merengek hanya karena sistem billing-nya tidak sempurna. Mungkin terdengar mengejutkan, tetapi untuk masalah yang menyangkut hubungan bisnis, kadang kita harus menyingsingkan lengan baju dan menanganinya secara manual
      Lakukan sesederhana mungkin, tetapi sistemnya harus bisa dibaca dan dipahami tim lain di perusahaan, serta mudah disesuaikan secara manual meskipun otomasi berjalan. Inilah 80% alasan mengapa Stripe terasa enak dipakai. Penyesuaian manual adalah bagian dari kehidupan, dan dalam bisnis tertentu, meski jarang, pada akhirnya tetap diperlukan
    • Saat berekspansi ke banyak negara dan mata uang, Anda meremehkan betapa sulitnya mengelola harga paket langganan saja
      Perhitungan prorata, jadwal billing yang berbeda, trial, pengujian harga baru, harga per wilayah, pajak per wilayah, menampilkan paket produk dalam berbagai mata uang, dan peluncuran harga baru tiba-tiba menjadi kombinasi 6 mata uang × X wilayah × Y produk × Z jadwal billing × L bahasa
      Di atas itu, Anda harus menambahkan langganan baru, menggabungkan paket langganan, menghentikan paket lama sambil memindahkan pelanggan dengan mulus ke paket alternatif baru, dan berkomunikasi dengan baik kepada pelanggan. Kalau ini SaaS, hampir semuanya harus terotomasi, self-service, dan teruji dengan baik; kalau tidak, Anda akan tenggelam dalam dukungan pelanggan dan churn
    • Ini mengasumsikan bahwa ada waktu untuk membuatnya sendiri. Kami punya 35 karyawan dan 300 ribu pelanggan B2C SaaS berharga rendah, tetapi kami begitu sibuk membangun produk dan memperbaiki bug sehingga waktu untuk memperluas sistem billing atau mengimplementasikan kontrak khusus praktis 0 menit
      Peluncuran perubahan harga bisa memakan waktu dari 3 hari hingga 2 bulan, dan menangani jejak kontrak khusus di masa awal adalah mimpi buruk. Kalau tidak bisa diotomasi dengan mudah, berarti tidak bisa dilakukan. Terlalu banyak memakan waktu
      Kalau billing kami sejak awal berbasis pada produk seperti yang disebutkan di sini, kemungkinan kami bisa jauh lebih baik dalam menangani kontrak khusus per segmen pelanggan dan peluncuran perubahan harga

  • Ada 2 masalah yang tidak dibahas di sini, tetapi pernah saya tangani sendiri
    Yang pertama adalah closing akhir bulan/kuartal. Tulisan ini membahas ledger akun, tetapi begitu mulai berurusan dengan perusahaan publik yang harus melaporkan angka, ada titik closing yang ketat dan semuanya harus berjalan mulus
    Yang kedua adalah akuntansi kas dalam perjalanan. Tulisan ini mengasumsikan pemroses pembayaran 100% akurat dan tidak pernah bermasalah. Setelah cukup besar, Anda harus bisa mencocokkan semua uang yang masuk ke rekening bank dengan invoice atau item tagihan tertentu. Anda juga harus menemukan invoice yang tidak punya baris mutasi bank yang sesuai, dan sebaliknya menangani uang masuk yang tidak terhubung ke item invoice. Kemampuan menangani kredit rekening bank yang tidak terkait dengan invoice tagihan juga penting
    Semua ini bisa saja disebut masalah departemen akuntansi, tetapi karena sangat erat terikat dengan sistem, kedua tim harus bekerja bersama agar tidak ada ketidaksesuaian antar-pembukuan

    • Siapa pun yang pernah sedikit saja berurusan dengan akuntansi di sekitar perusahaan publik besar pasti akan langsung tegang hanya mendengar istilah closing akhir bulan/kuartal
      Akuntan sungguhan harus berulang kali tinggal sampai tengah malam karena closing, sementara orang dari sisi teknologi/bisnis mengalami situasi ketika mereka membutuhkan sesuatu dari tim akuntansi tetapi selama periode closing tim akuntansi seolah menghilang dari muka bumi. Sebagai anggota keluarga pun rasanya sama
    • Jika sejak awal tidak mencocokkan setoran bank dengan item tagihan, tidak ada harapan untuk menyelaraskan pajak dengan benar
      Akuntansi internal dan rekening bank perlahan-lahan akan melenceng, dan akuntan tidak akan tahu harus mulai mencari masalah dari mana

  • Saya penasaran semua orang memakai apa untuk manajemen hak akses. Apakah memakai sistem feature flag, SaaS terpisah seperti Stigg, atau punya sistem internal sendiri?
    Saya datang ke HN pagi ini juga karena menulis artikel tentang memakai feature flag untuk manajemen hak akses: https://prefab.cloud/blog/modeling-product-entitlements-with.... Saya juga terinspirasi oleh tulisan Arnon tentang format SKU
    Feature flag tidak tampak seperti tempat yang sempurna untuk manajemen hak akses, tetapi dari pengalaman, saat menangani tugas seperti ini, sering kali itu adalah opsi terbaik di antara alat yang ada. Saya ingin mendengar pendapat lain

    • Kami memakai kombinasi batas numerik, misalnya jumlah panggilan API per hari, dan flag produk dalam bentuk array tag
      Batas dan flag ini ditempelkan ke “paket harga”, dan paket harga bisa ditempelkan ke akun. Jika beberapa paket harga digabungkan, nilai numerik mengambil nilai yang lebih besar, dan tag digabung sebagai union. Selain itu, nilai bisa ditimpa atau ditambahkan per akun, jadi jika pelanggan membutuhkan PlanX tetapi perlu kuota API khusus, cukup timpa satu nilai itu langsung di akun
      Silakan sebut ini kuno, tetapi saya tidak paham kenapa hal seperti ini harus dialihdayakan ke pihak ketiga
    • Saat ini saya sedang membuat solusi untuk fungsi yang mirip dengan hak akses paket harga
      Solusi dasar bisa dilakukan dengan feature flag, tetapi hak akses yang terkait billing dan harga—misalnya pengorganisasian dan perubahan paket harga serta edisi—menjadi kompleks seiring waktu karena banyak kebutuhan di sekitarnya. Bayangkan berbagai kombinasi fitur, seat, strategi berbasis penggunaan/terukur, langganan tim, migrasi paket harga, paket enterprise sekali pakai, pelanggan dengan beberapa langganan, periode promosi dan langganan bertingkat, agregasi penggunaan, upsell otomatis, dan sebagainya
      Seperti terlihat di artikel, batas bisa direpresentasikan sebagai flag dengan nilai numerik, tetapi infrastruktur pelacakan penggunaan tetap harus diimplementasikan sendiri oleh bisnis. Sebagai gantinya, bayangkan penggunaan itu diekspor ke layanan hak akses, lalu hak akses berbasis penggunaan diperbarui secara real time bahkan antar-tim. Hak akses lain yang bergantung pada hak akses tersebut juga dapat ikut diperbarui. Saat mendekati atau melewati batas, Anda bisa memilih soft limit yang tetap membiarkan penggunaan berlanjut tetapi memberi tahu tim sales, atau hard limit yang menampilkan ajakan upgrade
      Sejalan dengan maksud artikel asli, kami bekerja bersama solusi billing yang sudah ada, bukan membangun ulang billing. Kami sedang bootstrap dari exit sukses sebelumnya dan bekerja dengan pelanggan awal, jadi siapa pun yang hanya ingin mengobrol tentang topik ini boleh menghubungi trent at planship.io
    • Feature flag adalah salah satu sistem indah yang ekspresivitasnya pas cukup sehingga membuat kita ingin memaksakannya ke segala hal
      Rilis beta, autentikasi berbasis peran, hak akses billing, sampai permintaan pelanggan sekali pakai semuanya bisa dibuat dengan feature flag. Feature flag terbaik juga bisa secara opsional diberi nilai, jadi batas paket API pun bisa menjadi feature flag
      Kalau ditanya apakah ini yang terbaik, untuk tiap use case mungkin tidak. Namun begitu sudah dibuat, godaan untuk memakainya di mana-mana sangat besar
    • Saya rasa “hak akses feature flag” bisa bekerja dengan baik jika diperlakukan jelas berbeda dari feature flag yang biasanya dipakai engineer, yaitu untuk perubahan inkremental kecil, pengujian, deployment, dan A/B testing
      Hak akses harus terhubung jelas dengan fitur yang dilihat pelanggan, dan secara konseptual merupakan blok fitur yang jauh lebih besar. Kesulitan pendekatan ini adalah kita tetap harus mempertimbangkan banyak aspek terkait billing. Penanganan pelanggan menunggak, biaya kelebihan saat melewati batas tertentu, beberapa model harga untuk fitur yang sama, reset atau rollover penghitung penggunaan saat perubahan/upgrade paket, dan seterusnya menambah kompleksitas besar seiring waktu
      Karena itu, di Wingback kami memutuskan menyediakan hak akses fitur terpisah yang terintegrasi erat dengan rantai billing dan metering. Sebagai catatan, saya CTO-nya. Pada akhirnya, menurut saya kedua pendekatan bisa bekerja dengan baik, tergantung kompleksitas paket harga dan seberapa besar investasi yang sudah dilakukan pada feature flag. Jika ada feature gating untuk pelanggan, provisioning akun pelanggan dan penyediaan paket khusus menjadi jauh lebih mudah

  • Saya sulit menerima keseluruhan struktur logika “sistem X sangat kompleks, jadi jangan buat sendiri; pakailah solusi siap pakai”
    Solusi umum untuk X memang bisa sangat sulit dan kompleks, tetapi use case saya mungkin hanya membutuhkan bagian tertentu dari kompleksitas itu. Jadi saya bisa membuat solusi sendiri yang hanya menangani kompleksitas yang diperlukan, dan itu bisa jauh lebih sederhana daripada alat siap pakai
    Saya sepenuhnya mengambil posisi ini untuk tanggal dan waktu. Pendekatan saya terhadap tanggal dan waktu hanya membutuhkan library yang menyediakan dua pemanggilan fungsi: fungsi yang mengubah waktu epoch menjadi string waktu format ISO pada zona waktu tertentu, dan fungsi kebalikannya. Saya tidak menyentuh kode library lain sama sekali, dan sisa manipulasi waktu saya tangani di kode saya berdasarkan dua fungsi itu

    • Dalam billing, urusan uang berpindah tangan memiliki toleransi kesalahan yang sangat sempit dan juga diatur regulasi
      Sejak awal Anda harus memahami apa yang boleh dan tidak boleh dilakukan dalam penanganan data pribadi, siklus dan masa hidup berbagai opsi billing, batas refund, dukungan idempotensi, pengelolaan transaksi database yang masuk akal dengan model yang sesuai tugas, penerbitan invoice dan penampilannya kepada pelanggan, dan lain-lain
      Tidak semuanya dibutuhkan sekaligus, tetapi bahkan implementasi pertama yang bisa berjalan setidaknya membutuhkan separuhnya

  • Ada nuansa seperti “14 penderitaan menyeberang jalan dan mengapa Anda harus membeli dan membaca buku saya”
    Banyak orang mengira sebaiknya mulai berjalan dengan mata tertutup, lalu mengalami cedera dini atau meninggal
    Aturan menyeberang jalan berbeda di tiap negara, bahkan tiap kota. Anda mungkin belum tahu, tetapi Anda harus melihat ke dua arah. Banyak orang juga meninggal atau terluka karena tidak tahu bahwa mereka buta warna sehingga tidak bisa membedakan merah dan hijau. Anda sudah melihat ke dua arah, tetapi apakah Anda juga melihat ke atas? Di kota, benda bisa jatuh dari jendela; di desa, burung bisa terbang di atas kepala; dan sampah antariksa juga makin banyak jatuh ke Bumi. Objek bisa datang dari berbagai arah
    Bukan berarti artikel ini seburuk itu, tetapi akan lebih baik jika disusun sebagai tulisan metodologi. Saya jauh lebih ingin membaca tulisan seperti itu daripada tulisan yang dibingkai secara negatif

    • Saya sekarang bekerja di tim billing. Memang bukan sebagian besar karier saya dihabiskan di billing, tetapi artikel ini akurat
      Ini adalah contoh ideal proyek lelucon “memangnya sesulit apa?”, tetapi masalahnya semuanya benar
      Contohnya tak terhitung, tetapi jika pendekatannya keliru, Anda akan segera berhadapan dengan pertanyaan “berapa yang harus dibayar pelanggan”, lalu disusul “mengapa kita menagih jumlah ini, bukan jumlah lain”. Jika ini terjadi terlalu sering, tim keuangan akan datang dan bertanya apa yang telah Anda lakukan sampai laporan operasional perusahaan, bahkan laporan yang menentukan apakah orang diberhentikan atau tidak, menjadi tidak bisa dipercaya