Kodsuz Stripe abonelikleri: geliri sızdıran hatalar

Abonelik gelir sızıntıları genellikle nerede başlar

Aboneliklerdeki gelir sızıntıları nadiren dramatiktir. Küçük, yinelenen hatalar olarak görünürler: müşteriler olması gerektiği halde erişimi korur, yükseltmeler tam ücretlendirilmez veya krediler iki kez uygulanır. Bir kötü kenar durumu haftalarca sessizce tekrar edebilir, özellikle abonelikler ölçeklendikçe.

Kodsuz Stripe abonelikleri kuruyor olsanız bile faturalamanın mantığı vardır. Stripe faturalama motorudur, ama uygulamanız "aktif"in ne anlama geldiğine, ne zaman özelliklerin açılacağına ve yenilemelere veya başarısız ödemelere nasıl cevap verileceğine karar verir. No-code araçlar birçok işi ortadan kaldırır, ama kurallarınızı tahmin edemezler.

Çoğu sızıntı dört yerden başlar:

• Webhook'ların yanlış işlenmesi (kaçırılan olaylar, kopyalar, yanlış sıra)
• Denemelerin beklediğiniz şekilde sona ermemesi (iptal veya ödemesizlik sonrası deneme erişiminin devam etmesi)
• Plan değişikliklerindeki proratasyon (yükseltme ve düşürmelerin az ücretlendirilmesi veya sürpriz krediler oluşturması)
• Başarısız ödemeler ve yeniden denemeler (dunning sırasında erişimin açık kalması ya da çok erken kapatılması)

Yaygın bir desen "mutlu yol testi"nin çalışmasıdır. Abone olursunuz, erişim elde edersiniz, ilk fatura ödenir. Sonra gerçek dünya gelir: kart başarısız olur, müşteri döngü ortasında yükseltme yapar, biri deneme sırasında iptal eder veya Stripe ödemeyi gece yeniden dener. Uygulamanız sadece bir alanı kontrol ediyorsa (veya sadece bir olaya abone oluyorsa), ücretsiz süre tanıyabilir veya kazara çift kredi oluşturabilir.

AppMaster gibi bir platform kullanıyorsanız ekranları ve akışları hızlıca oluşturmak kolaydır. Risk, varsayılan akışın doğru faturalama politikası olduğunu varsaymaktır. Erişim kurallarınızı tanımlamanız ve backend'inizin Stripe olaylarına tutarlı şekilde tepki verdiğini doğrulamanız gerekir.

Erişimin gerçek kaynağına karar verin

Kodsuz Stripe abonelikleri yürütürken, sonradan birçok sızıntıyı önleyen bir karar: şu an bir kullanıcının erişimine hangi sistemin karar verdiğidir.

İki yaygın seçenek vardır:

• Stripe gerçekten tek kaynak olsun: erişime karar verirken gerektiğinde Stripe'tan abonelik durumunu sorgularsınız.
• Veritabanınız gerçek kaynak olsun: bir erişim durumu saklar ve faturalama olayları olduğunda güncellersiniz.

İkinci seçenek genelde uygulama için daha hızlıdır ve web ile mobil arasında tutarlılığı koruması daha kolaydır, ama yalnızca güvenilir şekilde güncellediğinizde.

Birçok ürün için pratik yaklaşım: Stripe faturalama için kaynak, veritabanınız erişim için kaynak olsun. Veritabanınız elle veya "ödendi olarak işaretle" gibi UI düğmeleriyle değiştirilmemeli. Stripe olaylarından türetilmeli (ve ara sıra mutabakat yapılmalı).

Bunu yapmak için stabil kimliklere ihtiyacınız var. En azından, kullanıcı veya hesap kaydınıza şu alanları kaydedin:

• Stripe müşteri ID'si (kimin ödediği)
• Stripe abonelik ID'si (hangi planda oldukları)
• En son fatura ID'si (proratasyon dahil ne faturalandırıldığı)
• En son payment_intent ID'si (gerçekte ödeme denemesi hangi kayıtta)

Sonra her abonelik durumunun ürününüz içinde ne anlama geldiğini tanımlayın. Ekranları, otomasyonları veya webhook'ları inşa etmeden önce bunu basit kurallar olarak yazın.

Birçok ekip tarafından kullanılan açık bir varsayılan politika:

• active: tam erişim
• trialing: trial_end'e kadar tam erişim, sonra durumu yeniden kontrol et
• past_due: kısa bir hoşgörü süresi için sınırlı erişim (örneğin, salt okunur)
• unpaid: ücretli özellikleri engelle, faturalama sayfasına ve veri dışa aktarımına izin ver
• canceled: izin veriyorsanız period_end'e kadar erişimi koru, sonra engelle

"Sonsuza dek ücretsiz" boşluklardan kaçının. Eğer past_due durumunda tam erişime izin veriyorsanız, bunun için sakladığınız tarihleri temel alan kesin bir kesme noktası olmalı, belirsiz bir "sonra hallederiz" yaklaşımı değil.

AppMaster içinde inşa ediyorsanız, erişim kararını iş mantığı olarak ele alın: hesabın üzerinde güncel erişim durumunu saklayın, Stripe olaylarından güncelleyin ve web ile mobil UI'nizin tutarlı şekilde o alanı kontrol etmesini sağlayın. Bu, Stripe olayları geç veya yanlış sırada gelse bile davranışı öngörülebilir kılar.

Webhook'lar: kaçırılan olayları ve çift işlemeyi önleyen desenler

Webhook'lar gelir sızıntılarının başladığı sessiz yerdir. Stripe olayları birden fazla kez gönderebilir, yanlış sırada gönderebilir veya saatler sonra teslim edebilir. Her webhook'u "muhtemelen gecikmiş" ve "muhtemelen kopya" olarak ele alın ve erişim güncellemelerinizi yine de doğru tutacak şekilde tasarlayın.

Önemli olaylar (ve genelde görmezden gelebilecekleriniz)

Gerçek abonelik durum değişikliklerini temsil eden küçük bir olay setine bağlı kalın. Çoğu kurulum için bunlar neredeyse ihtiyacınız olan her şeyi kapsar:

• checkout.session.completed (Checkout kullanarak abonelik başlattığınızda)
• customer.subscription.created, customer.subscription.updated, customer.subscription.deleted
• invoice.paid (bir faturalama dönemi gerçekten ödendiği an)
• invoice.payment_failed (ödeme başarısız olduğu an)

Birçok ekip charge.updated veya payment_intent.* gibi gürültülü olaylara aşırı tepki verip çelişkili kurallar oluşturur. Eğer faturalar ve abonelikler iyi işleniyorsa, alt seviye olaylar çoğu zaman kafa karışıklığı ekler.

Idempotency: Stripe yeniden denediğinde çift açılmayı durdurun

Stripe webhook'ları yeniden dener. invoice.paid her gördüğünüzde erişim "verirseniz", bazı müşteriler fazladan süre, fazladan kredi veya tekrarlanan haklar alacaktır.

Basit bir desen işe yarar:

• Herhangi geri dönülmez bir işlem yapmadan önce event.id'yi işlendi olarak kaydedin
• Aynı event.id'yi tekrar görürseniz erken çıkın
• Ne değiştiğini kaydedin (kullanıcı/hesap, abonelik ID'si, önceki erişim durumu, yeni erişim durumu)

AppMaster'da bu, bir veritabanı tablosu artı bir Business Process akışının "zaten işlendi mi?" kontrolü ile temiz şekilde eşleşir.

Olay sıralaması: gecikmiş ve yanlış sıradaki mesajlar için tasarlayın

customer.subscription.updated olayının invoice.paid'dan önce geleceğini veya her olayı sırayla göreceğinizi varsaymayın. Erişimi, ne olmasını beklediğinize göre değil, bilinen en güncel abonelik ve fatura durumuna göre belirleyin.

Bir şey tutarsız görünüyorsa, mevcut aboneliği Stripe'dan alın ve uzlaştırma yapın.

Ayrıca ham webhook payload'larını (en az 30-90 gün) saklayın. Destek "neden erişimi kaybettim?" veya "neden iki kez ücretlendirildim?" diye sorduğunda, bu denetim izi bir gizemi cevaba dönüştürür.

Ücretsiz erişim veya fatura karışıklığı yaratan webhook hataları

Webhook'lar Stripe'ın bir şey gerçekten olduğunda gönderdiği mesajlardır. Uygulamanız onları görmezse veya yanlış anda tepki verirse, hizmeti ücretsiz verebilir veya tutarsız faturalama davranışı yaratabilirsiniz.

Yaygın bir hata, paranın tahsil edildiği an yerine checkout tamamlandığında erişim vermektir. "Checkout tamamlandı" müşterinin aboneliği başlattığı anlamına gelebilir, ilk faturanın ödendiği anlamına gelmez. Kartlar başarısız olabilir, 3D Secure yarıda bırakılabilir ve bazı ödeme yöntemleri daha sonra sonuçlanır. Erişim için özellikleri açma anı olarak invoice.paid'ı (veya faturaya bağlı başarılı bir payment_intent'i) dikkate alın.

Başka bir sızıntı kaynağı sadece mutlu yolu dinlemektir. Abonelikler zaman içinde değişir: yükseltmeler, düşürmeler, iptaller, duraklatmalar ve past due durumları. Eğer abonelik güncellemelerini hiç işlemiyorsanız, iptal olmuş bir müşteri haftalarca erişimi koruyabilir.

Dört tuzak:

• Aboneliğin aktif olduğunu front-end'e güvenerek kabul etmek yerine, veritabanınızı webhook'lardan güncellemek
• Webhook imzalarını doğrulamamak; sahte isteklerin erişimi değiştirmesini kolaylaştırır
• Test ve canlı olayları karıştırmak (örneğin test modu webhook'larını üretimde kabul etmek)
• Sadece bir olay türünü işleyip her şeyin "kendiliğinden düzene gireceğini" varsaymak

Gerçek dünyadan bir başarısızlık: müşteri checkout'u tamamlar, uygulamanız premiumu açar ve ilk fatura başarısız olur. Sistem başarısızlık olayını hiç işlemezse, müşteri ödeme yapmadan premium kalır.

AppMaster gibi bir platformda Kodsuz Stripe abonelikleri kuruyorsanız amaç aynı: bir sunucu tarafı erişim kaydı tutun ve yalnızca doğrulanmış Stripe webhook'ları ödeme başarılı, başarısız veya abonelik durumu değiştiğinde onu değiştirin.

Denemeler: sonsuza dek sürmeyen ücretsiz sürelerden kaçının

Deneme sadece "ücretsiz faturalama" değildir. Net bir vaat: müşterinin neyi, ne kadar süreyle kullanabileceği ve sonrasında ne olacağı. En büyük risk, denemeyi UI'de bir etiket gibi ele almak yerine zamanla sınırlı bir erişim kuralı olarak görmemektir.

Deneme erişiminin ürününüzde ne anlama geldiğine karar verin. Tam erişim mi, yoksa sınırlı koltuklar, özellikler veya kullanım mı? Deneme bitmeden nasıl hatırlatma yapacağınızı (e-posta, uygulama içi afiş) ve müşteri kart eklemediyse faturalama sayfanızın ne gösterdiğini kararlaştırın.

Erişimi is_trial = true gibi yerel bir boolean'a bağlamak yerine doğrulayabileceğiniz tarih/timestamp'lara bağlayın. Abonelik Stripe tarafından deneme ile oluşturulduğunda deneme erişimini verin ve deneme bittiğinde abonelik aktif ve ödenmiş değilse deneme erişimini kaldırın. Eğer uygulamanız trial_ends_at saklıyorsa, bunu kullanıcı tıklamasından değil Stripe olaylarından güncelleyin.

Kart toplama zamanlaması "sonsuz ücretsiz"ün genelde sızdığı yerdir. Kart toplanmadan denemelere izin veriyorsanız dönüşüm yolunu planlayın:

• Deneme bitmeden önce açık bir "ödeme yöntemi ekle" adımı gösterin
• Denemeye kart olmadan başlatmaya izin verip vermeyeceğinize karar verin
• Dönüşüm sırasında ödeme başarısız olursa erişimi hemen veya kısa bir hafta içinde azaltın
• Uygulama içinde tam deneme bitiş tarihini her zaman gösterin

Kenar durumlar önemlidir çünkü denemeler düzenlenir. Destek denemeyi uzatabilir veya kullanıcı birinci günde iptal edebilir. Kullanıcılar deneme sırasında da yükseltme yapabilir ve yeni planın hemen geçmesini beklerler. Basit kurallar seçin ve tutarlı kalın: deneme sırasında yapılan yükseltme ya deneme bitiş tarihini korumalı ya da denemeyi bitirip hemen faturalamayı başlatmalıdır. Hangi seçeneği seçerseniz seçin, öngörülebilir ve görünür olsun.

Yaygın bir hata: kullanıcı "Denemeyi Başlat"a tıkladığında deneme erişimi verirsiniz ama sadece kullanıcı "İptal" tıkladığında kaldırırsınız. Eğer sekmeyi kapatır veya webhook başarısız olursa erişimi korurlar. Kodsuz bir uygulamada (AppMaster dahil), erişimi frontend tarafından ayarlanan manuel bir bayrak yerine Stripe webhook'larından alınan abonelik durumu ve deneme bitiş zaman damgalarına dayandırın.

Proratasyon: plan değişikliklerinde kazara eksik ücretlendirmeyi durdurun

Proratasyon, bir müşteri döngü ortasında aboneliği değiştirdiğinde Stripe'ın yalnızca kullandıkları süre için fatura ayarlaması yapmasıdır. Birisi yükseltme, düşürme, miktar değiştirme (örneğin koltuklar) veya farklı bir fiyata geçiş yaptığında Stripe prorata faturası oluşturabilir.

En yaygın gelir sızıntısı, yükseltmeler sırasında az ücretlendirmedir. Bu, uygulamanız yeni plan özelliklerini hemen açıp faturalama değişikliğinin daha sonra yürürlüğe girmesi veya proratasyon faturasının hiç ödenmemesi durumunda olur. Müşteri bir sonraki yenilemeye kadar daha iyi planı ücretsiz alır.

Bir proratasyon politikası seçin ve ona bağlı kalın

Yükseltmeler ve düşürmeler aynı şekilde ele alınmamalıdır, eğer bunu özellikle istemiyorsanız.

Basit, tutarlı bir politika örneği:

• Yükseltmeler: hemen geçerli olsun, farkın prorata ücreti şimdi alınsın
• Düşürmeler: bir sonraki yenilemede yürürlüğe girsin (döngü ortasında iade yok)
• Miktar artışları (daha fazla koltuk): hemen geçerli olsun, prorata ile faturalansın
• Miktar azalışları: yenilemede geçerli olsun
• İsteğe bağlı: "proratasyon yok"u yalnızca yıllık sözleşmeler gibi özel durumlar için izin verin, kazara değil

AppMaster içinde Kodsuz Stripe abonelikleri kuruyorsanız, plan-değişikliği akışı ile erişim-kontrol kurallarınızın bu politikayla eşleştiğinden emin olun. Eğer yükseltmeler şimdi ücretlendirilecekse, Stripe proratasyon faturasının ödendiği doğrulanana kadar premium özellikleri açmayın.

Döngü ortası değişiklikler koltuklar veya kullanım katmanları ile karmaşık olabilir. Bir ekip 25. günde 20 koltuk ekleyip 27. günde 15 koltuğu kaldırabilir. Mantığınız tutarsızsa, ekstra koltukları ücretlendirmeden verebilir veya geri ödeme tetikleyen kafa karıştırıcı krediler oluşturabilirsiniz.

Müşteri tıklamadan önce proratasyonu açıklayın

Proratasyon tartışmaları genelde sürpriz faturalar yüzünden olur, kötü niyet yüzünden değil. Onay butonunun yakınına politika ve zamanlamayı kısa bir cümle ekleyin:

• "Yükseltmeler bugün başlar ve şimdi prorata ücretlendirilirsiniz."
• "Düşürmeler bir sonraki faturalama tarihinde başlar."
• "Koltuk eklemek hemen faturalandırılır; koltuk kaldırma ise bir sonraki döngüde uygulanır."

Açık beklentiler itirazları, iade taleplerini ve "neden iki kez ücretlendirildim?" sorularını azaltır.

Başarısız ödemeler ve yeniden denemeler: dunning ve erişimi doğru yönetin

Başarısız ödemeler abonelik kurulumlarının sessizce para sızdırdığı yerdir. Eğer uygulamanız bir ödeme başarısız olduktan sonra erişimi sonsuza dek açık tutarsa, hizmeti ödenmeden sunarsınız. Eğer erişimi çok erken keserseniz, gereksiz müşteri kaybı ve destek talepleri yaratırsınız.

Önemli durumları bilin

Başarısız bir tahsilattan sonra Stripe aboneliği past_due ve daha sonra unpaid (veya ayarlarınıza bağlı olarak iptal) durumlarına taşıyabilir. Bu durumları farklı ele alın. past_due genelde müşterinin kurtarılabilir olduğunu ve Stripe'ın yeniden denediğini gösterir. unpaid genelde faturanın ödenmediğini ve hizmeti durdurmanız gerektiğini gösterir.

Kodsuz Stripe aboneliklerinde sık görülen hata, sadece tek bir alanı kontrol etmek (örneğin "abonelik aktif") ve asla fatura hatalarına tepki vermemektir. Erişim faturalama sinyallerini takip etmeli, varsayımları değil.

Geliri koruyan basit bir dunning planı

Yeniden deneme programınızı ve hoşgörü süresini önceden belirleyin, sonra bunları uygulamanızın uygulayabileceği kurallar olarak kodlayın. Stripe yeniden denemeleri yapılandırılmışsa onları yönetir, ama uygulamanız yine de yeniden deneme penceresi sırasında erişime ne yapılacağını belirler.

Pratik bir model:

• invoice.payment_failed alındığında: hesabı "ödeme sorunu" olarak işaretleyin, kısa bir hoşgörü süresi (örneğin 3–7 gün) için erişimi koruyun
• Abonelik past_due iken: uygulama içinde bir afiş gösterin ve "kartı güncelle" mesajı gönderin
• Ödeme başarılı olduğunda (invoice.paid veya invoice.payment_succeeded): ödeme sorunu bayrağını temizleyin ve tam erişimi geri verin
• Abonelik unpaid olduğunda (veya iptal edildiğinde): ana işlemleri kısıtlayın veya salt-okunur yapın, sadece fatura sayfasını saklamayın
• Son fatura durumu ve bir sonraki yeniden deneme zamanını kaydedin ki destek ne olduğunu görebilsin

Sonsuz hoşgörüden kaçınmak için kendi tarafınızda kesin bir son tarih saklayın. Örneğin, ilk hata olayı alındığında bir hoşgörü bitiş zaman damgası hesaplayın ve daha sonraki olaylar gecikse veya kaçırılırsa bile bunu uygulayın.

"Kartı güncelle" akışı için, müşteri yeni bilgileri girince sorunun düzeldiğini varsaymayın. Kurtarmayı sadece Stripe bir fatura ödendiğini veya başarılı bir ödeme olayı gösterdiğinde onaylayın. AppMaster'da bu net bir Business Process olabilir: bir ödeme başarılı webhook'u geldiğinde kullanıcıyı tekrar aktif yap, özellikleri aç ve bir onay mesajı gönder.

Örnek senaryo: bir müşteri yolculuğu, dört yaygın tuzak

Maya 14 günlük bir deneme başlatır. Kartını girer, denemeyi başlatır, 10. günde yükseltir, sonra bankası yenileme sırasında reddeder. Bu normaldir ve tam da gelir sızıntılarının olduğu yerdir.

Adım adım zaman çizelgesi (ve uygulamanız ne yapmalı)

1. Deneme başlar: Stripe aboneliği oluşturur ve bir deneme bitişi ayarlar. Genelde customer.subscription.created ve (kurulumunuza bağlı olarak) yaklaşan bir fatura görürsünüz. Uygulamanız abonelik denemede olduğu için erişim vermeli ve deneme bittiğinde erişimin otomatik değişmesi için deneme bitiş zamanını kaydetmelidir.

Tuzak 1: sadece "kayıt başarılı" anında erişim vermek ve deneme sona erdiğinde bunu güncellememe.

2. Deneme sırasında yükseltme: Maya 10. günde Basic'ten Pro'ya geçer. Stripe aboneliği günceller ve bir fatura veya proratasyon oluşturabilir. customer.subscription.updated, invoice.created, invoice.finalized ve para tahsil edilirse invoice.paid olaylarını görebilirsiniz.

Tuzak 2: "plan değişti"yi hemen ücretli erişim olarak kabul etmek; oysa fatura halen açık veya ödeme daha sonra başarısız olabilir.

3. Yenileme: 14. günde ilk ücretli dönem başlar, sonra sonraki ay yenileme faturası denenir.

Tuzak 3: tek bir webhook'a bel bağlayıp diğerlerini kaçırmak; bu yüzden ya invoice.payment_failed sonrası erişimi kaldırmazsınız ya da invoice.paid sonrası yanlışlıkla erişimi kaldırırsınız (kopyalar ve yanlış sıra olayları).

4. Kart reddedilir: Stripe faturayı ödenmemiş olarak işaretler ve ayarlarınıza göre yeniden denemelere başlar.

Tuzak 4: kullanıcıyı hemen kilitlemek yerine kısa bir hoşgörü süresi ve net bir "kartı güncelle" yolu kullanmamak.

Destek ekibinin sorunları hızlı çözmesi için ne saklanmalı

Küçük bir denetim izi saklayın: Stripe müşteri ID'si, abonelik ID'si, mevcut durum, trial_end, current_period_end, en son fatura ID'si, son başarılı ödeme tarihi ve son işlenen webhook olay ID'si ile zaman damgası.

Maya destekle iletişime geçtiğinde, ekibiniz iki soruyu hızlıca yanıtlayabilmeli: şu an Stripe ne söylüyor ve uygulamamız en son ne uyguladı?

QA kontrol listesi: yayına almadan önce faturalama davranışını doğrulayın

Faturalamayı açıp kapatılan bir düğme değil, test edilmesi gereken bir özellik gibi ele alın. Çoğu gelir sızıntısı Stripe olayları ile uygulamanızın erişim hakkındaki kararları arasındaki boşluklarda olur.

Başlarken "Stripe faturalama yapabilir mi?" ile "uygulama erişim veriyor mu?"yi ayırın ve ikisini de tam olarak yayınlayacağınız ortamda test edin.

Yayın öncesi kurulum kontrolleri

• Test ve canlı ayrımını doğrulayın: anahtarlar, webhook uç noktaları, ürünler/fiyatlar, ortam değişkenleri
• Webhook uç noktası güvenliğini doğrulayın: imza doğrulama açık olsun, imzalanmamış veya hatalı olaylar reddedilsin
• Idempotency'yi kontrol edin: tekrarlanan olaylar ekstra yetki, fatura veya e-posta üretmesin
• Kayıtları kullanılabilir yapın: event ID, müşteri, abonelik ve nihai erişim kararınızı saklayın
• Eşlemenizi doğrulayın: her kullanıcı hesabı tam olarak bir Stripe müşterisine eşlensin (veya net bir çoklu-müşteri kuralınız olsun)

AppMaster'da bu genelde Stripe entegrasyonunuzu, ortam ayarlarınızı ve Business Process akışlarınızın her webhook olayı ve sonucu için temiz bir denetim izi kaydettiğini onaylamak demektir.

Abonelik davranışı test vakaları

Bunları kısa, senaryolu bir QA oturumu olarak çalıştırın. Gerçek roller kullanın (normal bir kullanıcı, bir admin) ve uygulamanızda "erişim açık/kapalı"nın ne anlama geldiğini yazın.

• Denemeler: bir deneme başlatın, deneme sırasında iptal edin, bitmesine izin verin, bir kez uzatın, dönüşümün sadece ödeme başarılı olduğunda gerçekleştiğini doğrulayın
• Proratasyon: döngü ortasında yükselt, döngü ortasında düşür, aynı günde iki plan değişikliği yap; faturanın ve erişimin politikanızla eşleştiğini doğrulayın
• Kredi/iadeler: bir kredi veya iade verin ve premium erişimi sonsuza dek tutmadığınızı (veya çok erken kaldırmadığınızı) doğrulayın
• Başarısız ödemeler: başarısız bir yenilemeyi simüle edin, yeniden deneme zamanlamasını ve hoşgörü süresini doğrulayın, erişimin ne zaman kısıtlandığını kontrol edin
• Kurtarma: başarısız bir ödemeden sonra ödemeyi tamamlayın ve erişimin derhal (ve yalnızca bir kez) geri geldiğini doğrulayın

Her test için üç şeyi kaydedin: Stripe'ın olay zaman çizelgesi, veritabanı durumunuz ve kullanıcının uygulamada gerçekten neler yapabildiği. Bu üçü uyuşmadığında, sızıntıyı bulmuşsunuz demektir.

Sonraki adımlar: güvenli uygulama ve öngörülebilir faturalama

Faturalama kurallarınızı sade bir dille yazın ve spesifik tutun: erişim ne zaman başlar, ne zaman durur, ne sayılır "ödendi", denemeler nasıl biter ve plan değişikliklerinde ne olur. İki kişi okuduğunda farklı sonuçlar hayal ediyorsa, iş akışınız para sızdırır.

Bu kuralları her faturalama mantığı değişikliğinde çalıştırdığınız tekrarlanabilir bir test planına dönüştürün. Birkaç özel Stripe test müşterisi ve sabit bir senaryo "tıkla bak" testinden iyidir.

Test ederken bir denetim izi tutun. Destek ve finans hızlı cevaplara ihtiyaç duyacak: "bu kullanıcı neden erişimi korudu?" veya "neden iki kez ücretlendirildik?" gibi. Önemli abonelik ve fatura değişikliklerini (durum, geçerli dönem tarihleri, deneme bitişi, en son fatura, payment intent sonucu) loglayın ve hangi webhook olay ID'sinin işlendiğini saklayın ki ne olduğunu ispatlayabilesiniz ve aynı olayı iki kez işlemeden kaçının.

Kodsuz olarak bunu uyguluyorsanız, AppMaster (appmaster.io) yapıyı tutarlı tutmanıza yardımcı olabilir. Billing verilerini Data Designer (PostgreSQL) içinde modelleyebilir, Stripe webhook'larını Business Process Editor'da idempotency kontrolleriyle işleyebilir ve web ile mobil UI'nizin okuduğu tek bir "erişim kaynağı" alanıyla erişimi kontrol edebilirsiniz.

Gerçek hayata benzeyen bir kuru çalışma ile bitirin: bir ekip arkadaşı kaydolur, uygulamayı kullanır, yükseltir, bir ödeme başarısız olur, sonra düzeltir. Her adım yazılı kurallarınızla eşleşiyorsa, yayına hazırsınız demektir.

Sonraki adım: AppMaster'da minimal bir Stripe abonelik akışı oluşturmayı deneyin, sonra yayına almadan önce QA kontrol listesini çalıştırın.