Abonelik modeline geçtik, rakamlar tutmuyor: tekrarlayan tahsilat nasıl kurulur?

Abonelik faturalandırması dışarıdan "her ay aynı kartı çek" işi gibi görünür. İçeride birbirinden bağımsız üç mekanizma var: fiyatların tutulduğu katalog, tahsilat döngüsü ve müşterinin neye erişebildiğini belirleyen hak tanımı. Çoğu ekip üçünü tek tabloya sıkıştırıyor. Fatura ilk plan değişikliğinde tutmamaya başlıyor, kart yenilemelerinde sessiz gelir kaybı çıkıyor, deneme süresi biterken kimsenin beklemediği iptaller geliyor ve muhasebe "bu tahsilat hangi aya ait" diye sorduğunda cevap veren kimse olmuyor. Bu yazı o üç mekanizmayı ayırmanın ve aradaki kararları kod yazılmadan önce vermenin pratik yolunu anlatıyor.

Abonelik tek bir alan değil, üç ayrı kavram

Birinci kavram katalog: ürün, fiyat, para birimi, periyot. İkinci kavram abonelik: hangi müşteri, hangi fiyattan, hangi dönem için, hangi durumda. Üçüncüsü erişim hakkı: kaç kullanıcı açabilir, hangi modülleri görür, aylık kotası nedir.

Bunları ayırmanın bedeli bir tablo fazlası, birleştirmenin bedeli şu: Pro planın fiyatını 400 liradan 500 liraya çıkarıyorsunuz, plan tablosundaki tek satırı güncelliyorsunuz ve geçen ayın faturalarının tutarı da değişiyor. Aynı şekilde, aboneliği aktif ve pasif diye iki değerle tutan bir sistemde "ödemesi gecikti ama üç gün daha girebilsin" kuralının yazılacağı yer yoktur. Veri modelinin ilk haftada verilen kararları en çok bu üç kavramın karıştığı yerde geri dönüyor.

Fiyatı plana gömerseniz zam yapamazsınız

Fiyat kaydını değişmez (immutable) tutun. Zam yapmak, var olan satırı güncellemek değil, yeni bir fiyat kaydı oluşturup yeni aboneleri ona yönlendirmektir. Mevcut müşteriler, siz taşıyana kadar eski fiyat kaydına bağlı kalır. Stripe, Paddle ve benzerlerinin fiyat nesnelerini neredeyse hiç güncellettirmemesinin sebebi bu.

Bu yapı iki soruyu da kendiliğinden cevaplıyor: bu müşteri hangi fiyattan abone oldu, ve eski fiyattan devam eden kaç müşteri kaldı. Kampanyalı fiyatı ayrı bir indirim kaydı olarak tutun, fiyatın kendisine yedirmeyin; indirimin kaç dönem geçerli olduğu ve ne zaman düştüğü sonradan sorulacak. Birden fazla para biriminde satıyorsanız her para birimi için ayrı fiyat tanımlayın, kuru tahsilat anında çevirmeyin. Para ve kur saklama tarafındaki kurallar burada aynen geçerli.

Dönem ortasında plan değişikliği: oransal ücret kimin lehine?

Müşteri ayın 15'inde 400 liralık plandan 800 liralık plana geçti. İki iş kararı var ve ikisi de teknik değil: yükseltme anında mı geçerli olsun, ve kalan süre için ne kadar ücret alınsın?

Stripe bu hesabı saniye hassasiyetinde yapıyor ve belgelerin açıkça yazdığı gibi varsayılan davranış proration_behavior=create_prorations, yani fark kalemleri oluşturuluyor ama hemen tahsil edilmiyor. Aynı sayfada iki cümle daha var ve sürprizlerin çoğu oradan çıkıyor: negatif oransal tutarlar otomatik iade edilmez, pozitif olanlar da anında faturalandırılmaz. Farkı o anda tahsil etmek istiyorsanız always_invoice, hiç oranlamak istemiyorsanız none demeniz gerekiyor.

Pratikte işleyen politika şu: yükseltmeyi anında uygulayın ve farkı hemen faturalandırın, düşürmeyi dönem sonuna erteleyin. Böylece iade yönetmek zorunda kalmazsınız. Müşteriye "şimdi şu kadar çekilecek" yazısını göstermeden önce tutarı önizleyin ve önizlemede kullandığınız zaman damgasını güncelleme isteğinde de gönderin, yoksa ekranda gördüğü rakamla kartından çekilen rakam birbirini tutmaz.

Deneme süresi bittiğinde ne olacağı bir karar

Kart istemeden deneme vermek dönüşümü artırır, kart isteyerek vermek tahsilatı garanti eder. İkisi de savunulabilir. Savunulamaz olan, kart yoksa ne olacağına karar vermemektir.

Stripe'ta bu davranışın adı trial_settings.end_behavior.missing_payment_method ve üç değeri var: varsayılan create_invoice fatura kesip aboneliği gecikmiş duruma düşürür, cancel aboneliği iptal eder, pause ödeme yöntemi eklenene kadar dondurur. Üçü üç farklı müşteri deneyimi üretir. Hatırlatma tarafında da sessiz kalmayın: Stripe'ın customer.subscription.trial_will_end olayı varsayılan olarak bitişten 3 gün önce geliyor, Stripe'ın kendi hatırlatma e-postaları ise 7 gün önce gidiyor. Kendi hatırlatmanızı kuracaksanız bu iki pencereyi bilerek seçin.

Tahsilat sessizce düşer, dunning sessizce çalışmaz

Tekrarlayan tahsilatta asıl kayıp iptal eden müşteriden değil, ödemesi geçmediği için sessizce kaybolan müşteriden geliyor. Yeniden deneme politikası bu yüzden bir ayar değil, ürün kararı.

Stripe'ın önerdiği varsayılan 2 hafta içinde 8 deneme, kendi takviminizi kurarsanız en fazla 3 deneme tanımlayabiliyorsunuz. Burada bilinmesi gereken şey, her reddin tekrar denemeyle çözülmediği. lost_card, stolen_card ve authentication_required gibi kodlar sert ret sayılıyor ve yeni bir ödeme yöntemi girilmeden yapılan denemeler hiçbir şey değiştirmiyor. Denemeler bittiğinde aboneliğin iptal mi edileceği, ödenmemiş mi sayılacağı, gecikmiş durumda mı bırakılacağı yoksa dondurulacağı mı, bunu siz seçiyorsunuz.

Teknik tarafı kurduktan sonra işin yarısı iletişimde kalıyor. Kart düştüğünde giden e-posta spam klasörüne düşüyorsa hiç denememişsinizdir; işlemsel e-postaların neden ulaşmadığı ayrı bir konu ve dunning akışını doğrudan etkiliyor. Uygulamanın içine de bir uyarı şeridi koyun, kart güncelleme ekranına tek tıkla gitsin.

Kart yenilendi diye müşteri kaybetmeyin

Kartların ömrü aboneliklerden kısa. Süresi dolan, kaybolan ya da çalındığı için yeniden basılan her kart, hiçbir şey yapmazsanız bir tahsilat hatası demek.

Kart şebekeleri bunun için güncelleme servisleri işletiyor ve ödeme sağlayıcınız saklı kart bilgisini kendiliğinden tazeleyebiliyor. Stripe'ın belgeleri bu konuda dürüst bir uyarı da veriyor: destek ABD'de geniş, diğer ülkelerde kart çıkaran kuruluşa göre değişiyor ve hangi kartın otomatik güncellemeyi desteklediğini önceden anlamanın bir yolu yok. Yani otomatik güncelleme bir güvence değil, bir ihtimal. İki şeyi birlikte yapın: güncelleme olaylarını (payment_method.automatically_updated) dinleyip kendi kaydınızı tazeleyin, bir yandan da son kullanma tarihi yaklaşan kartlar için kendi hatırlatmanızı gönderin. Kartın kendisini değil, son dört hanesini, son kullanma tarihini ve sağlayıcının verdiği referansı saklayın.

Tekrarlayan çekim izin ister, bu izin bir metin değil bir kayıt

Saklı kartla ileride çekim yapabilmek için müşterinin onayı gerekiyor ve bu onayın neleri kapsaması gerektiği belirsiz değil. Stripe'ın SCA rehberi üç maddeyi sayıyor: müşterinin sizin adına ödeme başlatmanıza izin vermesi, ödemelerin beklenen sıklığı ve tutarın nasıl belirlendiği. Bu üç cümle ödeme adımında ekranda görünmeli.

Türkiye tarafında düzenleme de aynı noktaya basıyor. 1 Aralık 2021 tarihli Resmî Gazete'de yayımlanan tebliğin 10 uncu maddesinin on birinci fıkrası, hassas müşteri verisine erişimde veya düzenli ödeme talimatı verilirken güçlü kimlik doğrulama kullanılmasını şart koşuyor. Yükümlülük doğrudan size değil ödeme kuruluşuna ait, ama akışınızı belirleyen şey bu: talimatın kurulduğu ilk işlem 3D Secure ile doğrulanır, sonraki çekimler o talimat üzerinden yürür. Hangi müşterinin hangi tarihte, sözleşmenin hangi sürümünü onayladığını denetim izinde tutun. İtiraz geldiğinde istenen şey tam olarak bu kayıt oluyor.

Fatura kesmek tahsilat yapmakla aynı şey değil

Tahsilat geçtiği an işin bittiğini düşünmek Türkiye'de pahalıya mal oluyor. Vergi Usul Kanunu'nun 231 inci maddesinin 5 inci bendi net: fatura, hizmetin yapıldığı tarihten itibaren azami yedi gün içinde düzenlenir ve bu süre içinde düzenlenmeyen faturalar hiç düzenlenmemiş sayılır. Aylık abonelikte bu, her dönem için faturanın zamanında üretilmesi gereken bir iş demek.

Fatura üretimini tahsilat akışının içine gömmeyin. e-Arşiv ya da e-Fatura entegrasyonu yavaşladığında ya da sağlayıcı taraf hata döndürdüğünde müşterinin ödemesi takılmamalı; fatura işini kuyruğa alın ve yeniden denenebilir kurun. İade ve iptalde ne yapılacağını da baştan yazın, çünkü kesilmiş bir faturayı silmek diye bir şey yok. Muhasebe tarafında da bir ayrım var: yıllık tahsil ettiğiniz bedel o ayın geliri değil, hizmet verdikçe gelire dönüşen bir yükümlülük. Hangi tutarın hangi döneme ait olduğunu yazılımın raporlayabilmesi gerekiyor, nasıl muhasebeleştirileceğini mali müşavirinizle netleştirin.

MRR'ı üç ayrı yerden hesaplamayın

Aboneliğe geçen her şirkette aynı sahne yaşanıyor: yönetim panelinde bir MRR, finansın tablosunda başka bir MRR, ödeme sağlayıcısının ekranında üçüncü bir rakam. Üçü de yanlış değil, üçü farklı şey sayıyor.

Karar verilmesi gereken sorular kısa. Yıllık plan hangi aya yazılacak, iadeler düşülecek mi, deneme süresindeki abonelikler sayılacak mı, dönem ortası oransal kalemler MRR'a mı yoksa tek seferlik gelire mi gidecek, vergi dahil mi hariç mi. Bu tanımları tek bir yerde yazıp tek bir kayıt kaynağından üretin. Her raporun başka sayı vermesinin sebebi neredeyse her zaman bu tanımların hiç yazılmamış olması.

Ayın 31'inde başlayan abonelik ve sayaç tuzakları

31 Ocak'ta başlayan aylık abonelik 31 Şubat'ta yenilenemez. Şubat'ta hangi güne düşeceği, Mart'ta 31'e geri dönüp dönmeyeceği, 29 Şubat'ta ne olacağı birer kurallar bütünü ve test edilmeden doğru çalıştığı görülmez. Dönem sınırlarının hangi saat diliminde hesaplandığı da aynı şekilde: müşteri İstanbul'da, sunucu UTC'de, fatura günü birbirini tutmuyorsa sebebi genelde budur. Tarih ve saat dilimi tarafındaki tuzaklar abonelikte doğrudan paraya dokunuyor.

Kullanım bazlı ücretlendirme yapıyorsanız bir tuzak daha var. Sayaç olaylarını benzersiz bir kimlikle gönderin ki aynı kullanım iki kez faturalanmasın. Yeniden denemeler ve kuyruk tekrarları yüzünden aynı olayın iki kez düşmesi istisna değil, normal çalışma koşulu. Ödeme entegrasyonunda mükerrerliği engelleme kuralları burada da aynen geçerli.

Bu haftaya sığan ilk adım

Bir tablo açın ve beş satırı doldurun: dönem ortası yükseltmede ne oluyor, düşürmede ne oluyor, deneme bitince kart yoksa ne oluyor, tahsilat üst üste başarısız olunca kaçıncı günde erişim kesiliyor, iptal eden müşterinin verisi ne kadar süre duruyor. Bu beş satırın cevabını bilen ekip sayısı, abonelik ürünü olan ekip sayısından belirgin biçimde az.

Sonra bir şey daha yapın: canlıdaki aboneliklerden rastgele beş tanesini seçip son üç dönemin faturalarını elle hesaplayın. Tutmuyorsa nerede ayrıştığını bulmak, raporu düzeltmekten çok daha ucuza geliyor. Mevcut abonelik akışınızı gözden geçirmek ya da yeni bir ürünün faturalandırmasını doğru kurmak için destek isterseniz, plan listeniz ve son üç ayın tahsilat raporuyla gelin, konuşma çok daha hızlı ilerler.