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

Abonelik faturalaması kısa bir mutlu yola ve gelir kaybedilmeden fark edilmeyen uzun bir uç durumlar kuyruğuna sahiptir. Naif bir proration adımı plan yükseltmelerinde çift ücret keser; varsayılan bir yeniden deneme politikası dunning sırasında kartları yakar; 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ı çalıştırılabilen, başarısız olabilen veya tekrarlayabilen bir geçiştir.

Bu yazı, Stripe ve AWS EventBridge üzerinde abonelik sistemi kuran backend geliştiricileri için pratik bir rehberdir. Yaşam döngüsü durum makinesini, dönem ortası değişiklikler için proration yaklaşımlarını, müşterileri e-posta görmezden gelmeye alıştırmadan gelir kurtaran dunning kalıplarını ve chargeback öncesinde dikkat edilmesi gereken dolandırıcılık sinyallerini ele alır.

Abonelik Durum Makinesi

Her abonelik sistemi bir durum makinesidir. Durumları ve geçişleri anlamak, güvenilir faturalama mantığı oluşturmanın temelidir.

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. Bu, dönüşüm için en iyi penceredir — 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ükseltme yapan bir müşteri ek 5 $öder: kullanılmayan süre için -5$ kredi artı 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	Gelir kaybını önler

İpucu: B2C ürünlerinde, kullanıcı değişikliği onaylamadan önce proration tutarını göstermeyi düşünün. “Yeni planınız 20 $/ay. Bu faturalama döneminin geri kalanı için bugün 5$ ücretlendirileceksiniz” ifadesi sürpriz ücretleri ortadan kaldırır ve chargeback’leri azaltır.

Düşürme İşlemleri

Düşürmeler, yükseltmelerden daha karmaşıktır. Müşteri bir kredi veya azaltılmış sonraki fatura bekler, ancak uygulama iade felsefenize 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 deneme — kart güncelleme iste
do_not_honor	Kuruluş 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 deneme — incelemeye al

Stripe Smart Retries, yeniden deneme zamanlamasını kuruluş bankasını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 yumuşak redleri %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 Kadansı

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 kesin redlerin %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. Farklı planlar farklı muameleyi hak eder:

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 gereksinimi
• 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

Hız Kontrolleri

Hız kontrolleri, anormal davranışları yakalamak için işlem sıklığını izler:

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 Kötüye Kullanım Tespiti

Deneme kötüye kullanımı — aynı kişinin tekrarlanan ücretsiz denemeler elde etmek için birden fazla hesap oluşturması — kalıcı bir sorundur. Yaygın tespit sinyalleri:

• Birden fazla hesapta aynı cihaz parmak izi
• Benzer e-posta kalıpları ([email protected], [email protected])
• 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 yeteneğinin kaybıyla sonuçlanabilir.

Kayıp Kurtarma

İstemsiz Kayıp

Ödeme başarısızlıkları toplam kaybın %20-40’ına neden olur. Yukarıdaki dunning stratejileri birincil savunmadır. Ek önlemler:

• Ö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

İpucu: “Kurtarma oranını” takip edin — iptal akışını başlatan ancak tamamlamayan kullanıcıların yüzdesi. Bu metrik, elde tutma tekliflerinizin etkinliğini doğrudan ölçer.

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

Aşağıdaki kod örneği, Stripe olaylarını alan ve bunları downstream işleme için AWS EventBridge üzerinden yönlendiren bir webhook handler’ı gösterir. Bu kalıp, webhook handler’ını iş mantığından ayırarak sistemi genişletmeyi ve hata ayıklamayı kolaylaştırı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

• Abonelikleri bir durum makinesi olarak modelleyin. Her durum geçişi belirli bir webhook olayına eşlenmeli ve tanımlanmış bir iş eylemi tetiklemelidir
• 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. Hız 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ırarak sistemi bakımı ve genişletmesi daha kolay hale getirir

Kaynaklar

1. Using webhooks with subscriptions - Stripe’ın abonelik webhook olayları ve önerilen işleme kalıpları hakkında resmi rehberi.

2. How subscriptions work - Abonelik yaşam döngüsü, durumlar ve faturalama davranışını kapsayan Stripe dokümantasyonu.

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

4. Modify subscriptions - Abonelikleri yükseltme, düşürme ve değiştirme için Stripe API rehberi.

5. Beyond webhooks: Event-driven payment architectures with Amazon EventBridge - 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 - Ödeme sistemleri için AWS Çözümler Kütüphanesi referans mimarisi.

7. Streamlining Financial Operations: Leveraging Stripe event destinations with Amazon EventBridge - Yerel Stripe-EventBridge entegrasyonu hakkında AWS blogu.

8. What Is Dunning Management? Why It Matters & Best Practices - Maxio’nun dunning yönetimi stratejileri ve kurtarma oranları hakkında kapsamlı rehberi.

9. Subscription Dunning: Recover 80% of Failed Payments - ProsperStack’in dunning etkinliği ve en iyi uygulamalar analizi.

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

11. Velocity Check: Fraud Prevention Technique - SEON’un ödeme dolandırıcılığı önleme için hız kontrolleri uygulama rehberi.

12. Stripe Radar - 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? - Checkout.com’un hız tabanlı dolandırıcılık önleme hakkında teknik açıklaması.