Abonelik Planları ve Faturalama için Web Uygulaması Nasıl Oluşturulur?

Abonelik İşiniz için Gereksinimleri Netleştirin

Ödeme sağlayıcısını seçmeden veya veritabanını tasarlamadan önce aslında ne sattığınızı ve müşterilerin zaman içinde nasıl değişeceğini netleştirin. Çoğu faturalama sorunu, gerçekte gereksinim sorunlarıdır.

Erken dönemde riski azaltmanın faydalı bir yolu, faturalamayı sadece bir arka uç özelliği olarak değil, bir ürün yüzeyi olarak görmektir: ödeme akışı, izinler, e-postalar, analitik ve destek iş akışlarıyla temas eder.

Abonelik modelinizi tanımlayın

Önce ürününüzün ticari şeklini seçin:

• B2B vs B2C: B2B genellikle faturalar, satın alma siparişi alanları, ekip yönetimi ve yönetici kontrolleri gerektirir. B2C ise hızlı checkout ve basit iptalleri önceliklendirir.
• Koltuk bazlı (seats) vs kullanım bazlı: Koltuk bazlı modeller öngörülebilirdir (ör. kullanıcı başına $15/ay). Kullanım bazlı faturalama ölçüm kuralları (ne sayılır, ne zaman ölçülür, yuvarlama) ve müşterinin kullanımı görmesi için görünürlük gerektirir.
• Hesap yapısı: Bir “sahip” mi var ve birden fazla üyesi mi? Bir kişi birden fazla çalışma alanına ait olabilir mi? Bu kararlar izinleri, faturalama iletişim kişilerini ve kimin iptal edebileceğini etkiler.

Örnekler yazın: “12 üyeli bir şirket ay ortasında 8 üyeye düşürür” ya da “Bir kullanıcı bir ay ara verir, sonra geri döner.” Eğer bunu net olarak tarif edemiyorsanız, güvenilir şekilde inşa edemezsiniz.

Desteklemeniz gereken iş akışlarını listeleyin

En azından şu adımlar ve sonuçlar belgelenmiş olmalı:

• Kayıt → deneme → ilk ödeme (veya hemen ücretlendirme)
• Yükseltme/düşürme (prorasyon olacak mı? hemen mi yoksa sonraki yenilemede mi uygulanacak?)
• İptal (hemen sonlanır mı, dönem sonu mu, yoksa duraklatma mı?)
• Yenileme (otomatik yenileme, manuel yenileme, hoşgörü süresi)

Ayrıca ödeme başarısız olduğunda erişime ne olacağını kararlaştırın: anında kilitleme, sınırlı mod veya bir hoşgörü penceresi.

Self-servis vs yönetici tarafından yönetilen değişikliklere karar verin

Self-servis destek yükünü azaltır ancak bir müşteri portalı, net onay ekranları ve korunma önlemleri (ör. limitleri bozacak düşürmeleri engelleme) gerektirir. Yönetici tarafından yapılan değişiklikler ilk aşamada daha basittir, fakat iç araçlar ve denetim günlükleri gerekir.

Başarı metriklerini belirleyin

Ürün kararlarını yönlendirecek birkaç ölçülebilir hedef seçin:

• Aktivasyon oranı (denemeden aktif olana veya kayıttan ilk değere dönüş)
• Churn (müşteri sayısı ve gelir bazlı churn)
• MRR/ARR ve genişleme (yükseltmeler, eklenen koltuklar)
• Faturalama ile ilgili destek talepleri (geri ödemeler, başarısız ödemeler, kafa karışıklığı)

Bu metrikler hangi otomasyonların öncelikli olduğunu ve neyin bekleyebileceğini belirlemenize yardımcı olur.

Planları, Fiyatlandırmayı, Denemeleri ve Eklentileri Tasarlayın

Herhangi bir faturalama kodu yazmadan önce, gerçekten ne sattığınıza karar verin. Temiz bir plan yapısı destek taleplerini, başarısız yükseltmeleri ve “neden ücretlendirildim?” e-postalarını azaltır.

Değerle eşleşen bir fiyat modeli seçin

Yaygın modeller iyi çalışır, ancak faturalamada farklı davranırlar:

• Sabit ücret (Flat-rate): herkes için tek bir fiyat. Anlatması ve uygulaması en kolay olan.
• Katmanlı (Tiered): farklı özellik limitlerine sahip paketler (ör. Starter/Pro/Business). “Büyüdükçe beraberinizde olma” konumlandırması için iyidir.
• Koltuk başı (Per-seat): fiyat ekip büyüklüğüyle ölçeklenir. Bir koltuk olarak neyin sayılacağını (davet edilen kullanıcı mı yoksa aktif kullanıcı mı) açıkça belirtin.
• Kullanım bazlı: tükettiğiniz kadar ödersiniz (API çağrıları, depolama, mesajlar). Geriye dönük mi fatura kesiyorsunuz, ön ödemeli bir kota mı var, yoksa sert limitler mi uyguluyorsunuz bunları kararlaştırın.

Model karıştırıyorsanız (ör. temel plan + koltuk başı + kullanım aşımı), mantığı şimdi belgeleyin—bu sizin faturalama kurallarınız olur.

Faturalama aralıklarını ve deneme kurallarını belirleyin

İşinize uygunsa aylık ve yıllık sunun. Yıllık planlar genellikle şunları gerektirir:

• Net tasarruf mesajı (“2 ay ücretsiz”)
• Döngü ortasında yükseltme/düşürme için prorasyon kuralları

Denemeler için karar verin:

• Süre (7/14/30 gün)
• Ödeme yöntemi önceden gerekli mi?
• Sonunda ne olur (otomatik dönüştürme, duraklatma veya onay gereksinimi)
• Deneme sırasında düşürmelere izin veriliyor mu

Eklentiler, kuponlar ve grandfather edilmiş planlar

Eklentiler mini-ürünler gibi fiyatlandırılıp faturalandırılmalı: tek seferlik mi yoksa yinelenen mi, miktar bazlı mı yoksa sabit mi, ve hangi planlarla uyumlu oldukları.

Kuponların basit korunma kuralları olmalı: süresi (tek seferlik mi tekrar eden mi), uygunluk ve eklentilere uygulanıp uygulanmadığı.

Grandfathered (eski fiyatı koruyan) planlar için, kullanıcıların eski fiyatı sonsuza kadar koruyup korumayacağını, plan değiştirdiklerinde iptal olup olmayacağını veya bir sonlandırma tarihine kadar mı devam edeceğini belirleyin.

UI için plan isimleri ve limitleri yazın

Plan isimleri sonuçları çağrıştırmalı (“Starter”, “Team”)—iç etiketler yerine. Her plan için özellik limitlerini sade dille tanımlayın (ör. “3 projeye kadar”, “aylık 10.000 e-posta”) ve UI'de şunların gösterildiğinden emin olun:

• Nelerin dahil olduğu
• Limit aşıldığında ne olacağı (engelleme, aşım ücreti veya yükseltme yönlendirmesi)
• Sürpriz olmadan yükseltme/düşürme yolları

Planlar ve Faturalama için Veri Modelinizi Oluşturun

Bir abonelik uygulaması yüzeyde basit görünür (“aylık tahsilat”), ama faturalama net bir veri modeli olmadıkça karmaşıklaşır. Temel nesnelerinizi adlandırarak ve ilişkilerini açıkça belirleyerek başlayın; böylece raporlama, destek ve kenar durumlar tek seferlik yamalara dönüşmez.

Temel varlıklar (ne saklamalılar)

En azından bunları planlayın:

• Customer: kimlik, e-posta, fatura adresi, vergi kimlikleri (uygunsa) ve ödeme yöntemlerine bağlantılar.
• Plan: ürün katmanı (ör. Starter, Pro). Çoğunlukla pazarlama/özellik bilgisi tutun.
• Price: faturalandırılabilir tutar ve periyod (ör. $29/ay, $290/yıl). Bir Plan'ın birden fazla Price'ı olabilir, bu yüzden ayrı tutulur.
• Subscription: hangi Customer hangi Price'ta, başlangıç tarihi, mevcut dönem başlangıç/bitiş tarihleri ve yenileme davranışı.
• Invoice: belirli bir dönem için tahsil etmeyi amaçladığınız şey (satır öğeleri, toplamlar, vergi, indirimler) ve Subscription referansları.
• Payment: bir Invoice ile ilişkilendirilmiş para hareketi denemesi/sonucu.
• Refund: bir Payment'e bağlı ters işlemler.

Yararlı bir kural: Planlar değeri tanımlar; Price’lar parayı tanımlar.

Durum değişikliklerini karışıklık olmadan temsil edin

Subscription ve Invoice her ikisi de durumlara ihtiyaç duyar. Bunları açık ve zaman bazlı tutun.

Subscription için yaygın durumlar: trialing, active, past_due, canceled, paused. Invoice için: draft, open, paid, void, uncollectible.

Mevcut durumu ve bunu açıklayan zaman damgalarını/nedenleri saklayın (ör. canceled_at, cancel_reason, past_due_since). Bu, destek taleplerini çok daha kolay yapar.

Faturalama işlemleri için denetim günlükleri

Faturalama append-only bir denetim günlüğü gerektirir. Kim ne zaman ne yaptı kaydedin:

• plan değişikliği, prorasyon kararı, geri ödeme verildi, fatura elle iptal edildi
• aktör (müşteri, yönetici, sistem webhook'u), ilgiliysa IP/cihaz
• önceki/sonraki değerler (özet halinde bile olsa)

Yönetici vs müşteri izinleri

Açık bir çizgi çizin:

• Müşteri: faturaları/makbuzları görüntüleme, ödeme yöntemini güncelleme, iptal/yeniden başlatma, belgeleri indirme.
• Yönetici/destek: geri ödeme yapma, ücretsiz dönem verme, nadiren durumları zorla değiştirme, müşteri vergi bilgilerini düzenleme, denetim geçmişini görüntüleme.

Bu ayrım self-servisi güvenli tutarken operasyonlara gerekli araçları verir.

Bir Ödeme Yaklaşımı Seçin ve Bir Sağlayıcı Entegre Edin

Ödeme kurulumunuzu seçmek, yapacağınız en etkili kararlardan biridir. Geliştirme süresini, destek yükünü, uyumluluk riskini ve fiyatlandırmada ne kadar hızlı yineleme yapabileceğinizi etkiler.

Hepsi bir arada faturalama sağlayıcısı vs özel faturalama motoru

Çoğu ekip için hepsi bir arada bir sağlayıcı (ör. Stripe Billing) yineleyen ödemeler, faturalar, vergi ayarları, müşteri portalları ve dunning araçlarına en hızlı yoldur. Esneklikten biraz ödün verirsiniz ama hız ve kanıtlanmış kenar durum işleme kazanırsınız.

Özel bir faturalama motoru, alışılmışın dışında sözleşme mantığınız, birden fazla ödeme işlemcisi kullanma ihtiyacınız veya faturalama ve gelir tanıma konusunda katı gereksinimleriniz varsa mantıklı olabilir. Maliyet süreklidir: prorasyon, yükseltme/düşürme, geri ödemeler, yeniden deneme programları ve çok fazla muhasebe işini siz inşa edip sürdüreceksiniz.

Barındırılan checkout vs gömülü formlar (PCI kapsamı)

Barındırılan checkout sayfaları, hassas kart bilgileri sunucularınıza hiç değmediği için PCI uyumluluk kapsamınızı azaltır. Ayrıca yerelleştirmesi ve güncel tutulması (3DS, cüzdan ödemeleri vb.) daha kolaydır.

Gömülü formlar daha sıkı UI kontrolü sunabilir, ancak genellikle güvenlik sorumluluğunuzu ve test yükünüzü artırır. Erken aşamadaysanız, barındırılan checkout genellikle pragmatik varsayılandır.

Webhooklar/olaylar: uygulamanızı senkronize tutun

Ödemelerin uygulamanız dışında gerçekleşeceğini varsayın. Sağlayıcı webhook'larını (olaylarını) abonelik durum değişiklikleri için tek gerçek kaynak olarak kullanın—ödeme başarılı/başarısız, abonelik güncellendi, ücret iade edildi gibi—and veritabanınızı buna göre güncelleyin. Webhook işleyicilerini idempotent ve yeniden denemeye dayanıklı yapın.

Yayın öncesi hata modlarını belgeleyin

Kart reddi, süresi dolmuş kart, yetersiz bakiye, banka hataları ve chargeback durumlarında ne olacağını yazın. Kullanıcının ne göreceğini, hangi e-postaların gönderileceğini, erişimin ne zaman duraklatılacağını ve desteğin ne yapabileceğini tanımlayın. Bu, ilk başarısız yenileme geldiğinde sürprizleri azaltır.

Kayıt, Checkout ve Abonelik Oluşturmayı İnşa Edin

Bu, fiyatlandırma stratejinizin çalışan bir ürüne dönüştüğü noktadır: kullanıcı bir plan seçer, öder (veya denemeye başlar) ve hemen doğru düzeyde erişim alır.

Hızla uçtan uca bir abonelik web uygulaması göndermeye çalışıyorsanız, vibe-coding tarzı bir iş akışı sizi detayları atlamadan hızlandırabilir. Örneğin Koder.ai'de plan katmanlarınızı, koltuk limitlerinizi ve faturalama akışlarınızı sohbetle tanımlayabilir, ardından oluşturulan React UI ve Go/PostgreSQL arka ucunu yineleyebilirsiniz; bu sırada gereksinimler ve veri modeli hizalanmış olur.

Net bir fiyatlandırma sayfası ve seçim akışı oluşturun

Fiyat sayfanız seçimi tereddütte bırakmayacak şekilde olmalı. Her katmanın önemli limitlerini (koltuklar, kullanım, özellikler), nelerin dahil olduğunu ve faturalama aralığı geçişini (aylık/yıllık) gösterin.

Akışı öngörülebilir tutun:

• Plan seç → hesap oluştur (veya giriş yap) → checkout → onay

Eklentileri destekliyorsanız (ek koltuklar, öncelikli destek), nihai fiyat tutarlı olsun diye kullanıcıların bunları checkout öncesi seçmesine izin verin.

Gerçek dünya ayrıntılarıyla checkout'ı uygulayın

Checkout sadece kart numarası almak değildir. Kenar durumların ortaya çıktığı yerdir, bu yüzden baştan neleri zorunlu kılacağınızı belirleyin:

• Denemeler: aboneliği deneme modunda başlatın ve deneme bitiminde ne olacağını tanımlayın (otomatik faturalama, ödeme yöntemi zorunlu, veya “ödemek için devam et” gibi).
• Kuponlar/promosyonlar: indirim kodlarını uygulayın ve ayarlanmış ara toplamı net gösterin.
• Vergiler/KDV: konumu (ülke/eyalet/posta kodu) toplayın ve son ödeme adımından önce tahmini vergiyi gösterin.
• Gerekli alanlar: fatura adı, e-posta, şirket adı, KDV numarası (uygunsa) ve fatura adresi.

Abonelik oluşturmayı onaylayın ve erişimi verin

Ödemeden sonra sağlayıcının sonucunu (ve varsa webhook onayını) doğrulamadan özellikleri açmayın. Abonelik durumunu ve yetkilendirmeleri saklayın, ardından erişimi sağlamak (ör. premium özellikleri etkinleştirme, koltuk limitlerini ayarlama, kullanım sayacı başlatma) için işlem yapın.

Destek taleplerini azaltan işlem e-postaları gönderin

Şunları otomatik olarak gönderin:

• Hoş geldiniz e-postası: “sonraki adımlar” ve /account/billing bağlantısı içerebilir
• Makbuz/fatura e-postası başarılı ödeme sonrası
• Deneme bitiş hatırlatıcıları (ör. 7 gün ve 1 gün önce)

Bu e-postalar uygulamada görülenle tutarlı olsun: plan adı, yenileme tarihi ve nasıl iptal edileceği veya ödeme bilgilerinin nasıl güncelleneceği bilgisi.

Bir Müşteri Faturalama Portalı ve Self-Servis Oluşturun

Bir müşteri faturalama portalı, destek biletlerinin çözüldüğü yerdir—iyi bir durumda. Kullanıcılar faturalama sorunlarını kendileri çözebiliyorsa, churn, chargeback ve “faturamı güncelleyin” e-postaları azalır.

Müşterilerin yönetebilmesi gerekenler

İşe temel olanlarla başlayın ve görünür olmalarını sağlayın:

• Ödeme yöntemi güncellemeleri: müşterilerin kart bilgilerini güncellemesini sağlayın (ve uygun olduğunda geçmiş-due fatura için hemen yeniden deneme başlatın).
• Fatura bilgileri: fatura adresi ve şirket bilgilerini güncelleme desteği, böylece gelecek faturalar doğru olur.

Stripe gibi bir sağlayıcı entegre ediyorsanız, onların barındırılan portalına yönlendirebilir veya kendi UI'nızı oluşturup API çağrıları yapabilirsiniz. Barındırılan portallar daha hızlı ve daha güvenlidir; özel portallar marka ve kenar durumlar üzerinde daha fazla kontrol verir.

Yükseltmeler, düşürmeler ve prorasyon

Plan değişiklikleri kafa karışıklığı yaratır. Portalınız açıkça göstermeli:

• mevcut plan, yenileme tarihi ve bir sonraki ücretlendirme
• yeni fiyat ve ne zaman yürürlüğe gireceği
• prorasyon davranışı (kullanılmayan süre için kredi vs hemen ücretlendirme)

Prorasyon kurallarını önceden tanımlayın (ör. “yükseltmeler hemen uygulanır ve prorate ücret alınır; düşürmeler bir sonraki yenilemede uygulanır”). Ardından UI'nın bu politikayı yansıtmasını sağlayın ve açık bir onay adımı ekleyin.

Adil hissettiren iptal seçenekleri

Her ikisini sunun:

• Dönem sonu iptal (yenilemeye kadar erişim devam eder)
• Hemen iptal (erişim şimdi sona erer, isteğe bağlı geri ödeme mantığıyla)

Erişim ve faturalama açısından ne olacağını her zaman gösterin ve bir onay e-postası gönderin.

İstendiğinde faturalar ve makbuzlar

Bir “Faturalama geçmişi” alanı ekleyin ve fatura/makbuz indirme bağlantıları, ödeme durumu (ödenmiş, açık, başarısız) gösterin. Bu aynı zamanda KDV numarası düzeltmeleri veya fatura yeniden düzenleme gibi kenar durumlar için /support yönlendirmesi vermek için iyi bir yerdir.

Faturalama, Makbuzlar ve İade İşleme Uygulayın

Faturalama sadece “PDF gönder” demek değildir. Ne ücretlendirdiğinizin, ne zaman ücretlendirdiğinizin ve sonrasında ne olduğunun kaydıdır. Fatura yaşam döngüsünü net modellediğinizde destek ve finans işleri çok daha kolay olur.

Net bir fatura yaşam döngüsü tanımlayın

Faturaları durumlu nesneler olarak ele alın ve nasıl geçiş yapacaklarına dair kurallar koyun. Basit bir yaşam döngüsü şunları içerebilir:

• Draft: oluşturuldu ama finalize edilmedi (satır öğeleri düzenlenebilir).
• Open: finalize edildi ve ödemeyi bekliyor.
• Paid: ödeme başarılı (makbuz düzenlenebilir).
• Void: ödeme öncesi iptal edilmiş finalize fatura.
• Refunded: ödeme tersine çevrildi (tam veya kısmi).

Geçişleri açık tutun (ör. bir Open faturayı düzenleyemezsiniz; void edip yeniden düzenlemelisiniz) ve denetim için zaman damgalarını kaydedin.

Fatura numaraları, PDF'ler ve güvenli depolama

Benzersiz ve insan tarafından okunabilir fatura numaraları oluşturun (genellikle ön ekli ardışık, ör. INV-2026-000123). Eğer ödeme sağlayıcınız numara oluşturuyorsa, o değeri de saklayın.

PDF'ler için ham dosyaları uygulama veritabanında saklamaktan kaçının. Bunun yerine saklayın:

• sağlayıcının fatura URL'si (barındırılan fatura sayfası) ve/veya
• güvenli nesne depolamada kontrollü erişimli bir PDF bağlantısı.

İadeler, kısmi iadeler ve kredi notları

İade işlemleri muhasebe ihtiyaçlarınıza uygun olmalı. Basit SaaS için ödemeyle ilişkilendirilmiş bir iade kaydı yeterli olabilir. Eğer resmi düzeltmeler gerekiyorsa, kredi notları destekleyin ve bunları orijinal faturaya bağlayın.

Kısmi iadeler satır öğesi netliği gerektirir: iade edilen tutarı, para birimini, nedeni ve hangi fatura/ödemeye ait olduğunu saklayın.

UI ve e-postada fatura geçmişini gösterin

Müşteriler self-servis bekler. Faturalama alanınızda (ör. /billing) fatura geçmişini durum, tutar ve indirme bağlantılarıyla gösterin. Ayrıca finalize edilen faturaları/makbuzları otomatik e-posta ile gönderin ve aynı ekrandan talep üzerine yeniden gönderin.

Vergiler, KDV/GST ve Uyumluluk Temelleriyle İlgilenin

Vergiler, abonelik faturalamasının en kolay yanlış gidebileceği konulardan biridir—çünkü ne tahsil edeceğiniz müşterinin nerede olduğuna, ne sattığınıza (yazılım mı yoksa “dijital hizmet” mi) ve alıcının tüketici mi yoksa işletme mi olduğuna bağlıdır.

Hangi vergilerin uygulanacağını kararlaştırın

Satış yapacağınız yerleri ve hangi vergi rejimlerinin geçerli olduğunu listeleyerek başlayın:

• Satış vergisi (çoğunlukla ABD): eyalete göre ve bazı bölgelerde ilçe/şehir bazında farklı kurallar.
• KDV (UK/EU ve birçok bölge): genellikle müşterinin ülkesine göre tahsil edilir.
• GST (ör. Avustralya, Yeni Zelanda, Asya'nın bazı kısımları): benzer kavram, farklı eşik ve kurallar.
• Dijital hizmet kuralları: bazı ülkeler SaaS/dijital ürünleri fiziksel mallardan farklı şekilde ele alır.

Emin değilseniz, bunu bir yazma işi yerine iş kararı olarak ele alın—erken danışmanlık alın ki faturaları sonra yeniden yapmanız gerekmesin.

Gerekli müşteri vergi bilgilerini toplayın

Checkout ve faturalama ayarlarınız, vergiyi doğru hesaplamak için gereken asgari verileri yakalamalı:

• Müşterinin ülkesi (bazı durumlarda eyalet/provinca)
• Fatura adresi (genellikle vergi kanıtı için gerekir)
• İşletme vs tüketici göstergesi
• KDV ID / vergi ID (uygunsa ve doğrulama sonucu)

B2B KDV için geçerli bir KDV ID sağlandığında ters yükümlülük veya muafiyet uygulanması gerekebilir—faturalama akışınız bunu öngörülebilir ve müşteriye görünür kılmalıdır.

Gerekliyse vergi araçlarını kullanın

Birçok ödeme sağlayıcısı yerleşik vergi hesaplama (ör. Stripe Tax) sunar. Bu, hata riskini azaltır ve kuralları güncel tutmaya yardımcı olur. Birçok bölgede satış yapıyorsanız, yüksek hacminiz varsa veya gelişmiş muafiyetler gerekiyorsa, kuralları sabit kodlamak yerine özel bir vergi servisini düşünün.

Destek ve raporlama için vergi dökümünü saklayın

Her fatura/ücret için açık bir vergi kaydı saklayın:

• Uygulanan vergi oran(lar)ı, vergilendirilebilir tutar, vergi tutarı ve toplam
• Kararda kullanılan müşteri konumu kanıtı
• Sağlanan KDV/GST ID ve doğrulama sonucu

Bu, “neden vergi alındı?” sorusunu yanıtlamayı, iadeleri doğru işlemenizi ve ileride temiz finans raporları üretmeyi kolaylaştırır.

Başarısız Ödemeleri, Yeniden Denemeleri ve Dunning'i Yönetin

Başarısız ödemeler abonelik işlerinde normaldir: kartlar süresi dolabilir, limitler değişebilir, bankalar ödemeyi engelleyebilir veya müşteriler ödeme bilgilerini güncellemeyi unutabilir. Göreviniz, kullanıcıları şaşırtmadan geliri geri kazanmak ve destek taleplerini azaltmaktır.

Basit bir dunning akışı uygulayın (yeniden denemeler + hatırlatmalar)

Net bir programla başlayın ve tutarlı tutun. Yaygın bir yaklaşım 7–14 gün içinde 3–5 otomatik yeniden deneme ve bununla eş zamanlı e-posta hatırlatmalarıdır; hatırlatmalar ne olduğunu ve ne yapılması gerektiğini açıklar.

Hatırlatmaları odaklı tutun:

• Ne olduğu (“Nisan yenileme ödemeniz gerçekleşmedi”)
• Neden olabileceği (süresi dolmuş kart, banka reddi, yetersiz bakiye)
• Bir eylem butonu (“Ödeme yöntemini güncelle”)

Stripe gibi bir sağlayıcı kullanıyorsanız, yerleşik yeniden deneme kurallarına ve webhook'lara güvenin ki uygulamanız gerçek ödeme olaylarına tepki versin.

Hoşgörü süreleri ve erişim askıya alma kuralları

“Past-due” (ödeme gecikmesi) ne anlama geldiğini tanımlayın ve belgeleyin. Birçok uygulama, özellikle yıllık planlar veya kurumsal hesaplar için kısa bir hoşgörü süresi tanır.

Pratik bir politika:

• Gün 0–3: ödeme başarısız oldu → hizmet devam eder, hatırlatmalar gönderilir
• Gün 4–14: sınırlı özellik (isteğe bağlı) + daha güçlü hatırlatmalar
• 14. günden sonra: ödeme başarılı olana kadar erişim askıya alınır

Ne seçerseniz seçin, UI'da öngörülebilir ve görünür yapın.

Ödeme yöntemi güncellemeleri ve otomatik kurtarma

Checkout ve faturalama portalınız kart güncellemeyi hızlı yapmalı. Güncellemeden sonra, en son açık faturayı hemen ödemeyi deneyin (veya sağlayıcının “şimdi yeniden dene” aksiyonunu tetikleyin) ki müşteriler anında çözümü görsün.

Reddedilme mesajlarını eyleme geçirilebilir yapın

“Sadece ‘Ödeme başarısız’” gibi belirsiz mesajlardan kaçının. Nazik bir mesaj, tarih/saat ve sonraki adımları gösterin: başka bir kart deneyin, bankayla iletişime geçin veya fatura bilgilerini güncelleyin. Eğer bir /billing sayfanız varsa, kullanıcıları doğrudan oraya yönlendirin ve buton yazılarını e-posta ve uygulamada tutarlı hale getirin.

Destek ve Operasyon için Yönetici Araçları Ekleyin

Abonelik faturalama akışınız “kur ve unut” halinde kalmayacak. Gerçek müşteriler ödeme yapmaya başladıktan sonra, ekibinizin üretimde elle veri düzenlemeden yardımcı olabileceği güvenli, tekrarlanabilir yollar gerekecektir.

Erken aşamada sevk edilecek temel yönetici araçları

En yaygın destek taleplerini karşılayacak küçük bir yönetici alanıyla başlayın:

• Plan yönetimi: plan oluştur/devre dışı bırak, fiyatları ayarla, deneme uzunluklarını yapılandır ve eklentileri yönet. Mevcut aboneleri bozmayacak şekilde planları silmek yerine “eski” durumuna alma.
• Müşteri arama: e-posta, müşteri ID, fatura numarası veya kartın son 4 hanesi ile (sağlayıcının referansı üzerinden, ham olarak saklanmaz) arama. Önemli bilgileri hızlıca gösterin: mevcut plan, sonraki yenileme tarihi, durum ve son ödeme denemeleri.
• Geri ödemeler ve iptaller: “son faturayı iade et”, “dönem sonu iptal et” ve “hemen iptal et” için net butonlar; onay uyarıları ve kısa bir neden zorunlu kılın.

Saatler kazandıran destek iş akışları

Destek açısından bir etkileşimde çözüm sağlayan hafif araçlar ekleyin:

• Kredi ver (ör. $20 hesap kredisi) ve ne zaman uygulanacağını takip et
• Denemeleri uzat X gün ile (sınırlarla: maksimum uzatma, bir kerelik mi yoksa tekrar edilebilir mi)
• Hesaplara yönelik iç notlar (sadece personele görünür), destek taleplerine bağlantılar içeren

Rol tabanlı erişim kontrolü (RBAC)

Her çalışan faturalamayı değiştirme yetkisine sahip olmamalı. Support (gör + not), Billing Specialist (iade/kredi) ve Admin (plan değişiklikleri) gibi roller tanımlayın. İzinleri sadece UI'da değil, sunucu tarafında da zorunlu kılın.

Hassas işlemler için denetim günlükleri

Her hassas yönetici eylemini kaydedin: yapan kişi, zaman, ne değişti ve ilgili müşteri/abonelik ID'leri. Logları aranabilir ve ihlal incelemesi için dışa aktarılabilir yapın ve kayıtları etkilenen müşteri profiline bağlayın.

Abonelik Metrikleri için Analitik ve Raporlama

Analitik, faturalama sisteminizi karar verici bir araca dönüştürür. Sadece ödemeleri toplamıyor—hangi planların işe yaradığını, müşterilerin nerede zorlandığını ve hangi geliri güvenle bekleyebileceğinizi öğreniyorsunuz.

İzlenecek temel metrikler (ve nedenleri)

Güvenilir uçtan uca hesaplayabileceğiniz küçük bir abonelik metrik setiyle başlayın:

• MRR/ARR: yinelenen gelir tabanınız. Yeni, genişleme, daralma ve churn bazında bölün ki büyümeyi gerçekten neyin sürdürdüğünü görün.
• Churn: hem müşteri churn hem de gelir churn izleyin (farklı hikayeler anlatırlar).
• LTV: pazarlama harcaması kararları için faydalı, ama churn veriniz temizse anlamlıdır.
• Deneme dönüşümü: plan, kanal ve dönüşüm süresine göre ölçün.
• Genişleme geliri: yükseltmeler, eklentiler, koltuk artırımları—genellikle büyütmesi en kolay gelir kaynağı.

Kohortlar ve tutunma grafikleri

Zaman noktasındaki toplamlar sorunları saklayabilir. Aynı hafta/ayda başlayan müşterileri karşılaştırabileceğiniz abonelik kohort görünümleri ekleyin.

Basit bir tutunma grafiği şu soruları yanıtlar: “Yıllık planlar daha iyi tutuyor mu?” veya “Geçen ay yapılan fiyat değişikliği 4. haftadaki tutunmayı düşürdü mü?”

Faturalama kararlarını destekleyen olay takibi

Ana eylemleri olay olarak enstrümante edin ve bağlam ekleyin (plan, price, kupon, kanal, hesap yaşı):

• upgrade / downgrade
• cancel (iptal nedeni ile birlikte)
• payment failed
• payment recovered

Tutarlı bir olay şeması koruyun ki raporlama elle temizleme projesine dönüşmesin.

Müdahale edilebilecek uyarılar

Aşağılar için otomatik uyarılar kurun:

• ödeme başarısızlıklarında ani artışlar
• iadelerde olağandışı artış
• churn oranının normal aralığın dışına çıkması

Uyarıları ekibin gerçekten izlediği araçlara gönderin (e-posta, Slack) ve destek ekibinin hızlıca incelemesi için internal dashboard rotasına (/admin/analytics) bağlantı verin.

Güvenlik, Güvenilirlik ve Test Kontrol Listesi

Abonelikler küçük ama maliyetli hatalarda başarısız olur: bir webhook iki kez teslim edilir, bir yeniden deneme tekrar ücretlendirir veya sızmış bir API anahtarı iade oluşturur. Aşağıdaki kontrol listesiyle faturalamayı güvenli ve öngörülebilir tutun.

Gizli anahtarları ve webhookları koruyun

Ödeme sağlayıcı anahtarlarını bir secret manager'da (veya şifreli ortam değişkenlerinde) saklayın, düzenli döndürün ve asla git'e commit etmeyin.

Webhookları her isteği doğrulanmamış girdi gibi ele alın:

• Sağlayıcının webhook imzasını her çağrıda doğrulayın ve eski zaman damgalarını reddedin.
• Webhook uç noktalarını yalnızca HTTPS ile koruyun, izin listeleri ve hız sınırlamaları uygulayın.
• Webhook olay ID'lerini ve sonuçlarını loglayın ki destek “ne oldu” sorusunu hızlıca izleyebilsin.

PCI kapsamını minimumda tutun (kart verisi saklamayın)

Stripe (veya benzeri) kullanıyorsanız, ham kart numaralarının sunucularınıza hiç değmemesi için Checkout, Elements veya ödeme tokenları kullanın. PAN, CVV veya manyetik şerit verilerini asla saklamayın.

“Payment method” kaydederken sadece sağlayıcının referans ID'sini (örn. pm_...) ve görüntüleme için last4/marka/son kullanım tarihini saklayın.

Faturalama işlemlerini idempotent yapın

Ağ zaman aşımı olur. Sunucunuz “abonelik oluştur” veya “fatura oluştur” gibi çağrıları tekrar ederse çift ücretleme olabilir.

• Para hareketi oluşturabilecek API çağrılarında idempotency key kullanın.
• Veritabanınızda dış ID'ler (customer ID, subscription ID, invoice ID) için benzersizlik sağlayın.

Paranın risk altında olduğunu varsayarak test edin

Bir sandbox ortamı kullanın ve otomatik testler yazın ki şunları kapsasın:

• Kayıt → deneme → dönüşüm → iptal → yeniden etkinleştirme
• Webhook teslimatı sırasız, gecikmeli ve çoğaltılmış olarak geldiğinde
• Başarısız ödemeler, yeniden denemeler ve faturalama portalında kart güncellemeleri
• Dönem ortası plan değişiklikleri (prorasyon açık/kapalı), kuponlar ve eklentiler

Şema değişikliklerini üretime göndermeden önce, production-benzeri veride bir migration provası çalıştırın ve örnek geçmiş webhook olaylarını yeniden oynatarak hiçbir şeyin kırılmadığından emin olun.

Ekip hızlı iterasyon yapıyorsa, uygulamaya almadan önce hafif bir “planlama modu” adımı eklemeyi düşünün—ister bir iç RFC, ister araç destekli bir iş akışı olsun. Örneğin Koder.ai'de önce faturalama durumlarını, webhook davranışlarını ve rol izinlerini tasarlayıp, ardından uygulamayı snapshot ve geri alma imkanlarıyla oluşturabilirsiniz.