Hei — saya melihat pesanmu tadi pagi, tangkapan layar seseorang yang bertanya "bagaimana cara saya membayar ini" di kotak masuk dukungan aplikasimu. Selamat, sungguh-sungguh. Itulah momen ketika proyek sampingan berhenti menjadi sekadar demo. Ini juga momen ketika seratus keputusan kecil yang selama ini bisa kamu tunda, semuanya muncul di hari Selasa yang sama. Kamu memintaku untuk langsung memberitahumu apa yang harus dilakukan. Aku akan melakukannya, tapi aku ingin menjelaskan alasannya dulu, karena "alasan" itulah yang membuatmu tidak perlu bertanya lagi tiga bulan dari sekarang saat yang kamu pakai ternyata Lemon Squeezy alih-alih Stripe, atau langganan alih-alih pembelian sekali bayar.
Keputusan yang sebenarnya kamu buat
Kamu membingkai ini sebagai "penyedia pembayaran mana yang harus saya gunakan," tapi sebenarnya ini dua keputusan yang bertumpuk. Pertama: apakah kamu ingin menjadi merchant of record, atau ingin orang lain yang menjadi itu? Kedua: seperti apa bentuk penagihanmu — pembelian sekali bayar, langganan, atau berbasis pemakaian? Salah di keputusan pertama, dan enam bulan dari sekarang kamu akan menghabiskan akhir pekan untuk mendaftar PPN di negara yang belum pernah kamu kunjungi. Salah di keputusan kedua, itu cuma migrasi yang merepotkan, bukan masalah hukum, jadi ini yang lebih tidak menakutkan di antara keduanya.
Menjadi merchant of record berarti secara hukum kamulah yang menjual produk tersebut. Kamu mengumpulkan uangnya, kamu bertanggung jawab untuk mencari tahu pajak penjualan dan PPN di setiap yurisdiksi tempat pelangganmu tinggal, dan kamu yang melaporkannya. Stripe dengan senang hati akan menghitung pajak itu untukmu (Stripe Tax), tapi menghitung bukan berarti menyetorkan — kamu tetap harus mendaftar dan melapor di setiap tempat begitu kamu melewati ambang batasnya. Layanan merchant of record seperti Lemon Squeezy atau Paddle mengambil alih seluruh masalah itu darimu: secara hukum merekalah penjualnya, mereka mengumpulkan dan menyetorkan pajak di mana pun, dan mereka membayarkanmu hasil bersihnya. Kamu melepas sebagian margin sebagai gantinya.
| Opsi | Siapa penjualnya | Tarif potongan umum | Penanganan pajak | Paling cocok untuk |
|---|---|---|---|---|
| Stripe (langsung) | Anda | ~2,9% + $0,30/transaksi, +0,5% untuk Stripe Tax | Anda daftar dan lapor, Stripe tinggal menghitung | Anda berharap berkembang melampaui beberapa ribu transaksi per bulan dan menginginkan biaya lebih rendah dalam jangka panjang |
| Lemon Squeezy | Lemon Squeezy | ~5% + $0,50/transaksi | Ditangani sepenuhnya, mereka bertindak sebagai penjual resmi | Pembuat solo, produk pertama, tidak ingin memikirkan pajak sama sekali |
| Paddle | Paddle | ~5% + biaya bervariasi menurut wilayah | Ditangani sepenuhnya, lebih condong ke enterprise | SaaS dengan langganan dan sebagian kebutuhan penagihan (invoicing) |
| PayPal | Anda | ~3,5-4,5%, sengketa yang berpihak pada pembeli | Anda yang menangani | Pelanggan yang secara khusus mempercayai PayPal, bukan pilihan default |
Untuk posisi Anda saat ini — satu pelanggan, produk sederhana, belum tahu apakah ini akan jadi bisnis — saya akan mengarahkan Anda ke Lemon Squeezy atau Paddle ketimbang Stripe langsung. Tambahan biaya dua persen itu murah sebagai asuransi agar tidak jadi pelapor pajak dadakan di negara bagian yang belum pernah Anda injak. Anda selalu bisa bermigrasi ke Stripe langsung nanti, begitu volumenya sepadan dengan usaha pindah dan Anda siap menghadapi urusan administrasinya. Tidak ada yang pindah penyedia pembayaran untuk bersenang-senang, tapi itu masalah yang bisa diselesaikan dalam sehari, bukan setahun.
Saya sendiri pernah melakukan kesalahan ini di proyek sebelumnya — langsung pakai Stripe karena "semua orang pakai Stripe," mengumpulkan beberapa ratus dolar per bulan dari segelintir pelanggan Eropa, lalu delapan belas bulan kemudian menerima email yang sangat sopan tapi sangat membingungkan soal pendaftaran VAT MOSS. Biayanya satu sore bersama akuntan dan empat puluh menit panik murni mencari di Google "apakah saya berutang uang ke Belanda." Tidak fatal. Tapi sepenuhnya bisa dihindari.
Sebelum menyentuh kunci live
Apa pun pilihan Anda, jangan langsung pasang dalam mode produksi. Setiap penyedia ini memiliki mode uji/sandbox dengan nomor kartu palsu yang memicu hasil tertentu — pembayaran berhasil, kartu ditolak, memerlukan 3D Secure, saldo tidak cukup. Coba semuanya sebelum menyentuh kunci asli. Jalur kegagalan itulah yang benar-benar akan Anda temui di minggu pertama, dan jauh lebih tidak menyenangkan untuk di-debug secara live dengan kartu milik orang sungguhan.
Di chat build Anda, sampaikan secara eksplisit bahwa Anda ingin ini bertahap: minta integrasi dipasang dalam mode uji terlebih dahulu, dengan banner atau flag yang jelas terlihat agar tidak ada yang — termasuk Anda di masa depan — tanpa sengaja mengenakan biaya ke kartu asli saat menguji. Lalu buat langkah kedua yang disengaja untuk mengganti dengan kunci live. Dua perintah, bukan satu, meskipun lebih cepat cukup bilang "tambahkan pembayaran" dan biarkan sistem menebak mode mana yang dipakai. Friksi itu justru tujuannya.
Anda juga perlu memutuskan apa yang terjadi saat webhook terpicu sementara server Anda sedang down, lambat, atau eventnya datang dua kali. Ini bukan hipotetis — ini terjadi di minggu pertama, secara konsisten. Event yang benar-benar perlu Anda tangani, minimal:
checkout.session.completed(atau yang setara) — berikan akses, inilah momen pelanggan resmi menjadi pelangganinvoice.payment_failed— untuk langganan, putuskan sekarang apakah itu penguncian instan atau masa tenggang, karena "penguncian instan" adalah kesan pertama yang buruk untuk kartu yang baru saja mengalami gangguan sementaracustomer.subscription.deleted— seseorang membatalkan, cabut akses di akhir periode, bukan seketika, kecuali ketentuan Anda menyatakan sebaliknya- Event pengembalian dana (refund) — putuskan sekali, secara tertulis untuk diri sendiri, apa sebenarnya kebijakan refund Anda, sebelum permintaan refund pertama memaksa Anda memutuskannya secara langsung
Idempotensi lebih penting di sini dibanding hampir di bagian mana pun lain dalam aplikasi Anda. Jika webhook datang dua kali — dan itu akan terjadi, penyedia mencoba ulang pada respons non-200 apa pun — Anda tidak boleh memberikan akses dua kali atau, lebih buruk, menagih ganda pada state internal. Simpan ID event dan periksa apakah sudah pernah diproses sebelum Anda bertindak berdasarkan itu.
Pertanyaan harga yang Anda hindari
Anda menyebutkan dalam pesan Anda belum yakin apakah harus mengenakan biaya $9/bulan atau sekali bayar $49. Saya rasa keduanya tidak salah, tapi perhatikan apa yang sebenarnya Anda hindari: percakapan dengan pelanggan tentang apa nilai berulangnya. Harga sekali bayar lebih mudah disetujui dan lebih mudah Anda bangun (tanpa dunning, tanpa penanganan perpanjangan gagal, tanpa alur pembatalan). Langganan adalah taruhan bahwa Anda akan terus meningkatkan produk itu cukup agar orang tidak berhenti — itu komitmen nyata, bukan sekadar centang di halaman harga. Jika Anda tidak yakin masih akan aktif mengerjakan ini enam bulan lagi, harga sekali bayar adalah penawaran yang lebih jujur. Anda selalu bisa menambahkan tingkat langganan nanti begitu ada sesuatu yang berkelanjutan untuk dilanggan.
Satu hal lagi, lalu saya biarkan Anda lanjut: pasang kebijakan refund dan pembatalan yang sungguhan di halaman sebelum menerima dolar pertama, bahkan jika hanya tiga kalimat. Bukan karena ada yang akan menuntut Anda gara-gara biaya $9, tapi karena menuliskannya memaksa Anda benar-benar memutuskannya, dan "nanti saya pikirkan kalau ada yang tanya" adalah cara Anda berakhir membuat keputusan kebijakan di tengah email marah alih-alih di sore hari yang tenang.
Pasang dulu sandbox-nya. Kirim pesan ke saya begitu Anda sudah mencoba kartu ditolak palsu melalui sistem itu — itulah versi "berhasil" yang benar-benar penting.
