Abonelik Yaşam Döngüsü Yönetimi: Yükseltmeler, Dunning ve Dolandırıcılık Tespiti

Abonelik faturalamasında mutlu yol kısadır; asıl uzun olan, sessizce gelir sızdıran uç durumlar kuyruğudur. Özensiz bir proration adımı plan yükseltmelerinde çift ücret keser; varsayılan bir yeniden deneme politikası dunning sırasında kartı boş yere arka arkaya dener; eksik dolandırıcılık sinyalleri sonunda chargeback olarak geri döner. Abonelikler tek bir işlem değildir; birer durum makinesidir ve her faturalama olayı tetiklenebilen, başarısız olabilen veya tekrarlayabilen bir geçiştir.

Önce aboneliği bir durum makinesi olarak modelleyin, geri kalan her şeyi bu modelin üzerine oturtun. Proration kuralları, dunning takvimi, dolandırıcılık kontrolleri ve yetki değişiklikleri böylece sahibi belli birer geçişe dönüşür. Stripe tarafında bunun karşılığı tek bir webhook handler’dır: imzayı doğrular, tekrarları eler ve olayı EventBridge’e yayınlar. İş mantığı ise bu yolun arkasındaki tüketicilerde çalışır.

Abonelik Durum Makinesi#

Neredeyse her abonelik ürünü altı durumla anlatılabilir: deneme, aktif, ödemesi gecikmiş, duraklatılmış, iptal edilmiş ve süresi dolmuş. Ürünler arasında değişen şey, hangi geçişlere izin verildiği ve bu geçişleri kimin tetikleyebildiğidir.

Her geçiş belirli bir Stripe webhook olayına karşılık gelir:

Geçiş	Stripe Olayı	Eylem
Oluşturuldu	customer.subscription.created	Erişim sağla, hoş geldin gönder
Deneme bitiyor	customer.subscription.trial_will_end	Ödeme yöntemi iste
Ödeme başarılı	invoice.payment_succeeded	Aktif durumu onayla
Ödeme başarısız	invoice.payment_failed	Dunning iş akışını başlat
Plan değişikliği	customer.subscription.updated	Yetkilendirmeleri güncelle
İptal	customer.subscription.deleted	Dönem sonunda erişimi kaldır

trial_will_end olayı, süre dolmadan 3 gün önce tetiklenir. Dönüşüm için en iyi pencere budur: bu pencere içinde ödeme yöntemi ekleyen kullanıcılar, son gün uyarılanlardan önemli ölçüde daha yüksek oranda dönüşüm sağlar.

Yükseltme ve Düşürme: Proration’ı Doğru Yapmak#

Proration, çoğu abonelik sisteminde ince hataların biriktiği yerdir. Temel soru: bir müşteri dönem ortasında plan değiştirdiğinde, faturalama farkını nasıl yönetirsiniz?

Üç Proration Stratejisi#

Anlık proration (Stripe varsayılanı): Müşteri, eski plandaki kullanılmayan süre için kredi alır ve yeni plandaki kalan süre için ücretlendirilir. Faturalama döneminin yarısında 10 $/ay’dan 20 $/ay’a yükselen bir müşteri 5 $ fazla öder: kullanılmayan süre için 5 $ kredi, ardından yeni plandaki kalan yarı için 10 $.

Sonraki faturalama döngüsü: Değişiklikler yenilemede yürürlüğe girer. Stripe API’de proration_behavior: 'none' olarak ayarlayın. Müşteriler için daha anlaşılırdır ve daha az destek talebi oluşturur. Ancak gelir tanıması gecikir.

Her zaman faturala: Proration tutarı için anında fatura oluşturur. proration_behavior: 'always_invoice' olarak ayarlayın. Faturalama doğruluğunun kullanıcı sürtünmesinden daha önemli olduğu kurumsal planlar için uygundur.

Strateji Seçimi#

Hedef Kitle	Strateji	Neden
B2C / Self-servis	Sonraki faturalama döngüsü	Daha basit UX, daha az destek talebi
B2B / Kurumsal	Anlık proration	Doğru faturalama, denetim izi
Kullanım tabanlı	Her zaman faturala	Lisanslı proration hemen faturalanır; kullanım yine dönem sonunda

Düşürme İşlemleri#

Düşürmeler, yükseltmelerden daha karmaşıktır. Müşteri bir kredi veya azaltılmış sonraki fatura bekler, ancak uygulama iade politikanıza bağlıdır:

• Sonraki faturaya kredi: Kullanılmayan bakiyeyi kredi olarak uygulayın. Para hareket etmez ve müşteri yenilemede azaltılmış bir ücret görür
• Anlık iade: Farkı karta iade edin. Daha yüksek müşteri memnuniyeti ama ödeme işlem maliyetlerini artırır
• Hesap kredisi: Eklentiler veya gelecekteki faturalama için kullanılabilecek platform kredileri verin. Parayı ekosisteminizde tutar

Dunning: Başarısız Ödemeleri Kurtarma#

Dunning (başarısız abonelik ödemelerini kurtarma süreci), abonelik yönetiminde en yüksek kaldıraç etkisine sahip alanlardan biridir. Ödeme başarısızlıklarından kaynaklanan istemsiz kayıp (involuntary churn), çoğu SaaS işletmesinde toplam kaybın %20-40’ını oluşturur.

Akıllı Yeniden Deneme Mantığı#

Tüm ödeme başarısızlıkları aynı değildir. Yeniden deneme stratejisi, red nedenine göre uyarlanmalıdır:

Red Kodu	Anlam	Yeniden Deneme Stratejisi
insufficient_funds	Kartta bakiye yok	3-5 gün bekle (maaş günü döngülerine göre ayarla)
card_expired	Kart süresi dolmuş	Yeniden denemeyin; kart güncellemesi isteyin
do_not_honor	Kartı veren banka reddetti	24 saat sonra bir kez dene, sonra alternatif ödeme iste
network_error	Geçici bağlantı	2-4 saat içinde yeniden dene
fraudulent	Dolandırıcılık şüphesi	Yeniden denemeyin; incelemeye alın

Stripe Smart Retries, yeniden deneme zamanlamasını kartı veren bankanın davranış kalıplarına göre optimize etmek için makine öğrenimi kullanır. Bu yaklaşım, statik yeniden deneme programlarına kıyasla geçici redleri (soft decline) %20’den fazla azaltabilir.

Pratik bir bulgu: tüm ödeme kurtarmanın yaklaşık %50’si yalnızca yeniden denemelerden gelir ve ilk dunning e-postası gönderilmeden önce başarısız ödemelerin yaklaşık %21’i otomatik yeniden denemelerle kurtarılır.

Dunning İletişim Takvimi#

Dunning iletişimleri için temel uygulama detayları:

• Tek tıkla ödeme güncelleme linkleri: Her e-posta, oturum açmaya gerek kalmadan ödeme bilgilerini güncellemek için doğrudan bir link içermelidir. Kart güncellemelerinin %70’inden fazlası mobil cihazlarda gerçekleşir, bu nedenle güncelleme akışı mobil uyumlu olmalıdır
• Kişiselleştirilmiş mesajlaşma: Kişiselleştirilmiş dunning e-postaları, genel şablonlardan önemli ölçüde daha etkilidir. Müşterinin adını kullanın, planından bahsedin ve empatik olun
• Kart güncelleyici hizmetleri: Visa Account Updater (VAU) ve Mastercard Automatic Billing Updater (ABU), süresi dolmuş kart bilgilerini otomatik olarak güncelleyebilir. Bu tek başına süresi dolmuş kartlardan kaynaklanan kalıcı redlerin (hard decline) %30-50’sini önler

Tolerans Süresi Stratejileri#

Tolerans süresi, bir ödeme başarısızlığından sonra müşterinin ne kadar süre erişimini koruduğunu belirler. Her plan seviyesi aynı süreyi gerektirmez:

Plan Seviyesi	Tolerans Süresi	Tolerans Süresinde Erişim
Temel	7 gün	Banner ile tam erişim
Pro	14 gün	Banner ile tam erişim
Kurumsal	30 gün	Tam erişim, hesap yöneticisi bilgilendirilir

Tolerans süresi bitiş tarihini abonelik metadata’sında saklayın. Her API isteğinde yetkilendirme durumunu kontrol edin ve kullanıcının iş akışını engellemeden ödeme sorununu ileten uygulama içi banner’lar gösterin.

Dolandırıcılık Tespit Kalıpları#

Abonelik sistemleri, çalıntı ödeme yöntemlerine karşı uzun süreli tekrarlanan ücretlere izin verdikleri için dolandırıcılık açısından cazip hedeflerdir.

Kart Test Saldırıları#

Kart testi, dolandırıcıların çalıntı kart numaralarını küçük abonelik ücretleri yaparak doğrulamasıdır. Kalıp tanınabilirdir: kısa bir zaman penceresinde aynı IP veya cihaz parmak izinden birden fazla abonelik denemesi.

Savunma önlemleri:

• Abonelik oluşturmayı sınırlayın: 15 dakikalık pencerede IP başına maksimum 3 deneme
• 2 başarısız denemeden sonra CAPTCHA isteyin
• Kart BIN kalıplarını izleyin: aynı BIN aralığından birden fazla kart, ele geçirilmiş bir partiyi gösterir
• Deneme kayıtları için bilinen tek kullanımlık e-posta alan adlarını engelleyin

İşlem Sıklığı Kontrolleri#

İşlem sıklığı kontrolleri (velocity checks), anormal davranışı yakalamak için belirli bir pencerede kaç deneme yapıldığını sayar:

interface VelocityRule {
  dimension: 'ip' | 'device_fingerprint' | 'email_domain' | 'card_bin';
  window: number; // saniye
  maxAttempts: number;
  action: 'block' | 'flag' | 'challenge';
}

const velocityRules: VelocityRule[] = [
  { dimension: 'ip', window: 900, maxAttempts: 5, action: 'block' },
  { dimension: 'device_fingerprint', window: 3600, maxAttempts: 3, action: 'block' },
  { dimension: 'email_domain', window: 86400, maxAttempts: 10, action: 'flag' },
  { dimension: 'card_bin', window: 3600, maxAttempts: 5, action: 'challenge' },
];

Deneme Süresi İstismarı Tespiti#

Deneme süresi istismarı, yani aynı kişinin tekrar tekrar ücretsiz deneme almak için birden fazla hesap açması, kalıcı bir sorundur. Yaygın tespit sinyalleri:

• Birden fazla hesapta aynı cihaz parmak izi
• Benzer e-posta kalıpları (john+1@gmail.com, john+2@gmail.com)
• Birden fazla hesaba bağlı aynı ödeme yöntemi
• Farklı “kullanıcılardan” aynı tarayıcı/cihaz yapılandırması

Stripe Radar, her ödeme denemesinde risk puanlaması sağlar. Abonelik oluşturmada risk puanı 75’in üzerindeki işlemleri engelleme gibi özel kurallar ayarlamak, meşru müşterileri engellemeden çoğu otomatik dolandırıcılığı yakalar.

Chargeback İzleme#

Chargeback oranlarını kritik eşiklerin altında tutun:

• Visa VAMP: %1,5 aşırı oran eşiği (2026’da %0,9’a düşecek)
• Mastercard: İşlemlerin %1,0’ı

Bu eşiklerin aşılması, izleme programlarına dahil edilme, anlaşmazlık başına ücretler veya kart işleme yetkisinin kaybıyla sonuçlanabilir.

Müşteri Kaybını Geri Kazanma#

İstemsiz Kayıp#

Yukarıdaki dunning stratejileri, ödeme kaynaklı kayba karşı birincil savunmadır. Bu savunmanın önünde duran üç önlem var:

• Ödeme yöntemi çeşitlendirmesi: Yedek yöntem olarak PayPal, SEPA Otomatik Ödeme veya banka havalesi sunun
• Otomatik kart güncelleyici entegrasyonu: Süresi dolan kartları başarısız olmadan önce proaktif olarak güncelleyin
• Ön-dunning bildirimleri: Kart son kullanma tarihinden 7 gün önce müşterileri uyarın

İstemli Kayıp#

Bir müşteri iptal başlattığında, iptal akışının kendisi bir elde tutma fırsatıdır:

1. Nedenini sorun: 3-5 iptal nedeni sunun (çok pahalı, kullanmıyorum, eksik özellikler, rakibe geçiyorum, diğer)
2. Alternatifler sunun: Nedene göre duraklatma, düşürme veya indirim teklif edin
3. Elde tutma teklifi: 3 ay için %10-30 indirim, iptal girişimlerinin anlamlı bir kısmını kurtarır
4. Onaylayın ve takip edin: Devam ederlerse, onay gönderin ve 7., 30. ve 90. günlerde geri kazanma e-postaları planlayın

Olay Güdümlü Mimari: Stripe + EventBridge#

Tek bir webhook handler, Stripe olaylarını alır ve downstream işleme için AWS EventBridge üzerinden yönlendirir. Bu kalıp, handler’ı iş mantığından ayırdığı için sistemi genişletmek ve hata ayıklamak kolaylaşır.

import Stripe from 'stripe';
import { EventBridgeClient, PutEventsCommand } from '@aws-sdk/client-eventbridge';

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
const eventBridge = new EventBridgeClient({});

const EVENT_BUS_NAME = process.env.EVENT_BUS_NAME || 'subscription-events';

interface WebhookResult {
  statusCode: number;
  body: string;
}

export async function handler(event: {
  body: string;
  headers: Record<string, string>;
}): Promise<WebhookResult> {
  const signature = event.headers['stripe-signature'];

  let stripeEvent: Stripe.Event;
  try {
    stripeEvent = stripe.webhooks.constructEvent(
      event.body,
      signature,
      process.env.STRIPE_WEBHOOK_SECRET!
    );
  } catch (err) {
    console.error('Webhook signature verification failed:', err);
    return { statusCode: 400, body: 'Invalid signature' };
  }

  // Idempotency kontrolu - bu olayı zaten işlediysek atla
  const alreadyProcessed = await checkIdempotency(stripeEvent.id);
  if (alreadyProcessed) {
    return { statusCode: 200, body: 'Already processed' };
  }

  // Stripe olayını EventBridge detail-type'a eşle
  const detailType = mapEventType(stripeEvent.type);

  await eventBridge.send(
    new PutEventsCommand({
      Entries: [
        {
          Source: 'subscription.stripe-webhook',
          DetailType: detailType,
          Detail: JSON.stringify({
            stripeEventId: stripeEvent.id,
            type: stripeEvent.type,
            subscription: extractSubscriptionData(stripeEvent),
            timestamp: new Date().toISOString(),
          }),
          EventBusName: EVENT_BUS_NAME,
        },
      ],
    })
  );

  // İdempotency için işlenmiş olarak işaretle
  await markProcessed(stripeEvent.id);

  return { statusCode: 200, body: 'OK' };
}

function mapEventType(stripeType: string): string {
  const mapping: Record<string, string> = {
    'customer.subscription.created': 'SubscriptionCreated',
    'customer.subscription.updated': 'SubscriptionUpdated',
    'customer.subscription.deleted': 'SubscriptionCanceled',
    'invoice.payment_succeeded': 'PaymentSucceeded',
    'invoice.payment_failed': 'PaymentFailed',
    'customer.subscription.trial_will_end': 'TrialEnding',
  };
  return mapping[stripeType] || 'UnknownEvent';
}

function extractSubscriptionData(event: Stripe.Event) {
  const obj = event.data.object as Stripe.Subscription | Stripe.Invoice;
  if ('subscription' in obj) {
    // Fatura olayı
    return {
      subscriptionId: obj.subscription,
      customerId: obj.customer,
      amountDue: (obj as Stripe.Invoice).amount_due,
      status: (obj as Stripe.Invoice).status,
    };
  }
  // Abonelik olayı
  const sub = obj as Stripe.Subscription;
  return {
    subscriptionId: sub.id,
    customerId: sub.customer,
    status: sub.status,
    currentPeriodEnd: sub.current_period_end,
    cancelAtPeriodEnd: sub.cancel_at_period_end,
  };
}

Bu handler üç şey yapar: webhook imzasını doğrular, idempotent işlemeyi kontrol eder ve normalize edilmiş bir olayı EventBridge’e yayınlar. Downstream tüketiciler (dunning iş akışları, yetkilendirme güncellemeleri, analitik) webhook handler’ına bağımlı olmadan belirli olay türlerine abone olur.

Farklı ödeme sağlayıcılarının abonelik faturalamayı nasıl yönettiğine daha derin bir bakış için ödeme sağlayıcı karşılaştırması yazısına bakın. Abonelik durum değişikliklerinin mobil ve web platformları arasında nasıl yayıldığını öğrenmek için yetkilendirme senkronizasyonu mimarisi yazısına bakın.

Temel Çıkarımlar#

• Her durum geçişini tek bir webhook olayına ve tek bir iş eylemine eşleyin. Eşlenmemiş geçişler, hiçbir alarmın yakalamadığı sessiz yetki kaymalarına yol açar
• Hedef kitlenize göre proration stratejisi seçin. B2C sonraki döngü değişikliklerinden faydalanır; B2B anlık doğruluk gerektirir
• Dunning’e yoğun yatırım yapın. Akıllı yeniden denemeler ve kişiselleştirilmiş iletişim, başarısız ödemelerin %70-85’ini kurtarabilir
• Dolandırıcılık tespitini katmanlandırın. İşlem sıklığı kontrolleri, cihaz parmak izi ve Stripe Radar birlikte meşru müşterileri engellemeden çoğu kötüye kullanım kalıbını yakalar
• Webhook işlemeyi iş mantığından ayırın. EventBridge, Stripe entegrasyonunu downstream işlemeden ayırır ve sistemin bakımını, genişletilmesini kolaylaştırır

Buradaki varsayılanlar, kart üzerinden çalışan self-servis SaaS faturalamasını varsayar. Kullanım tabanlı ürünlerde proration’ın kapsamı daha dardır. Stripe ölçülen kullanıma proration uygulamaz; bu kullanım dönem sonunda geriye dönük faturalanır. Dolayısıyla always_invoice yalnızca değişikliğin lisanslı kısmını hemen faturalar, kullanım kısmı yine dönem sonu faturasına düşer. Fatura kesilen kurumsal hesaplar da dunning’in dışında kalmaz, sadece akış farklıdır. Kart yeniden denemeleri ve otomatik erişim kısıtlaması yerine hatırlatmalar ve hesap yöneticisi eskalasyonu devreye girer; tahsilat ise bu akışın en sonunda yer alır.

Kaynaklar#

1. Using webhooks with subscriptions (yeni sekmede açılır) - Stripe’ın abonelik webhook olayları ve önerilen işleme kalıpları hakkında resmi rehberi.

2. How subscriptions work (yeni sekmede açılır) - Abonelik yaşam döngüsü, durumlar ve faturalama davranışını kapsayan Stripe dokümantasyonu.

3. Prorations (yeni sekmede açılır) - Stripe’ın plan değişiklikleri için proration hesaplamalarının nasıl çalıştığına dair açıklaması.

4. Modify subscriptions (yeni sekmede açılır) - Abonelikleri yükseltme, düşürme ve değiştirme için Stripe API rehberi.

5. Beyond webhooks: Event-driven payment architectures with Amazon EventBridge (yeni sekmede açılır) - EventBridge ile olay güdümlü ödeme işleme oluşturma hakkında AWS blogu.

6. Guidance for Building Payment Systems Using Event-Driven Architecture on AWS (yeni sekmede açılır) - Ödeme sistemleri için AWS Çözümler Kütüphanesi referans mimarisi.

7. Streamlining Financial Operations: Leveraging Stripe event destinations with Amazon EventBridge (yeni sekmede açılır) - Yerel Stripe-EventBridge entegrasyonu hakkında AWS blogu.

8. What Is Dunning Management? Why It Matters & Best Practices (yeni sekmede açılır) - Maxio’nun dunning yönetimi stratejileri ve kurtarma oranları hakkında kapsamlı rehberi.

9. Subscription Dunning: Recover 80% of Failed Payments (yeni sekmede açılır) - ProsperStack’in dunning etkinliği ve en iyi uygulamalar analizi.

10. How card testing and digital skimming are evolving (yeni sekmede açılır) - Mastercard’ın kart testi saldırı kalıpları ve savunma mekanizmaları hakkında genel bakışı.

11. Velocity Check: Fraud Prevention Technique (yeni sekmede açılır) - SEON’un ödeme dolandırıcılığını önlemek için işlem sıklığı (velocity) kontrolleri uygulama rehberi.

12. Stripe Radar (yeni sekmede açılır) - Stripe’ın makine öğrenimi tabanlı dolandırıcılık tespit platformu dokümantasyonu.

13. What are velocity checks & how do they prevent payment fraud? (yeni sekmede açılır) - Checkout.com’un işlem sıklığına dayalı dolandırıcılık önleme hakkında teknik açıklaması.