Mobil IAP ve Paywall Stratejileri - App Store, Play Store, RevenueCat

Mobil in-app purchase uygulaması, birbirine uyumsuz iki faturalandırma sistemi üzerinde çalışır: Apple App Store ve Google Play; her birinin kendine özgü komisyon kuralları, makbuz formatları ve sunucu tarafı doğrulama gereksinimleri vardır. Bu doğrulama pipeline’ındaki açıklar, jailbreak’li veya root’lu cihazların ödeme yapmadan entitlement talep etmesine olanak tanır; tek bir reddedilen paywall akışı ise abonelik lansmanını engelleyebilir. Çapraz platform bir uygulamada geçerli varsayılan şudur: mağazaların standart faturalandırmasını RevenueCat soyutlamasının arkasında kullanmak. Entitlement’ı sunucuda doğrulanmış duruma bakarak verin; istemci tarafındaki bir kontrol yeterli değildir. RevenueCat yolunda bu doğrulama RevenueCat sunucularında, mağazalarla doğrudan entegrasyonda ise kendi sunucunuzda çalışır.

Her iki mağaza da dijital ürünler için kendi faturalandırmasını zorunlu kılar, komisyon ve makbuz formatında ayrışır, abonelik durumu değiştiğinde de sizin tüketmeniz gereken sunucu bildirimleri gönderir. RevenueCat bu farkın büyük kısmını üstlenir: makbuz doğrulama, birleşik müşteri görünümü ve aynı app user ID kullanıldığında platformlar arası geri yükleme. Üstlenmediği kısım sizde kalır: bu app user ID’yi oturumlar ve cihazlar arasında sabit tutmak, webhook olaylarını kendi servislerinizin okuduğu yetkilendirme durumuna dönüştürmek.

App Store ve Play Store Ödeme Kuralları#

Apple ve Google, uygulamalar içinde tüketilen dijital ürünler için kendi faturalandırma sistemlerini zorunlu kılar. Kurallar detaylarda farklılık gösterir ve düzenleyici baskılar bu kuralları yeniden şekillendirmektedir.

Komisyon Oranları Özet Tablosu#

Özellik	Apple App Store	Google Play Store
Standart komisyon	%30	%30
Küçük geliştirici oranı	%15 (yılda $1M altı)	%15 (ilk $1M/yıl)
Abonelikler (1. yıl)	%30	%15
Abonelikler (2. yıl+)	%15 (12 ay tutunma sonrası)	%15
Medya (e-kitap, streaming)	Standart oranlar	%10 (şartlar sağlanırsa)
AB alternatif faturalandırma	%17 veya %10 (indirimli)	%27 (%3 indirim)

IAP Gerektiren Durumlar#

Uygulama içinde tüketilen dijital ürünler mağazanın faturalandırma sistemini kullanmalıdır:

• Premium özellik açan abonelikler
• Sanal para birimleri, coin’ler, gem’ler
• Ek içerik (seviyeler, filtreler, çıkartmalar)
• Premium uygulama işlevselliği

IAP gerektirmeyen durumlar:

• Fiziksel ürünler ve gerçek dünya hizmetleri (Uber, Amazon alışveriş)
• Kişiden kişiye hizmetler (özel ders, danışmanlık)
• Uygulama dışında tüketilen içerik (bulut depolama, e-posta hizmetleri)

Reader App Kuralı (Apple)#

Apple belirli uygulamaları “reader” (okuyucu) uygulama olarak sınıflandırır: müzik, video, haber, kitap ve dergi gibi daha önce satın alınmış içeriği sunan uygulamalar. Bu uygulamalar:

• Hesap oluşturma veya yönetimi için web sitelerine tek bir harici bağlantı ekleyebilir
• Başka yerde satın alınan içeriğe erişim izni verebilir
• Web’de yönetilen abonelikler için IAP’yi atlayabilir

Netflix, Spotify ve Kindle bu sınıflandırmayı kullanır. Uygulamanız bu kalıba uyuyorsa, kullanıcıları web tabanlı kayda yönlendirebilir ve %30 komisyondan tamamen kaçınabilirsiniz.

AB Dijital Pazar Yasası (DMA)#

Mart 2024’ten itibaren AB, Apple’ı DMA kapsamında “gatekeeper” olarak tanımladı. Bu şu anlama gelir:

• Alternatif ödeme sağlayıcıları: AB/AEA’da dağıtılan uygulamalar iOS 17.4+ üzerinde üçüncü taraf ödeme işlemcileri kullanabilir
• İndirimli komisyon: Alternatif ödeme kullanırken Apple, %30/%15 yerine %17 (standart) veya %10 (küçük işletme) alır
• Çekirdek Teknoloji Ücreti: Apple, 1 milyon kurulumun üzerindeki ilk yıllık kurulum başına 0,50 EUR alır (tartışmalı ve devam eden yasal süreçlere konu)
• Google’ın yaklaşımı: AEA’da alternatif faturalandırma kullanılırken %3 hizmet ücreti indirimi sunar

Çoğu bağımsız geliştirici ve startup için standart IAP yolu daha basit kalır. Alternatif faturalandırma rotası, önemli bir AB kullanıcı tabanına ve komisyon tasarruflarının uygulama karmaşıklığını aştığı yüksek gelire sahip uygulamalar için daha anlamlıdır.

İşe Yarayan Paywall Kalıpları#

Doğru paywall kalıbı; içerik türünüze, kullanıcı tabanınıza ve iş modelinize göre değişir.

Hard Paywall#

Her şey satın alma duvarının arkasında. Kullanıcıların değeri zaten anladığı köklü markalar için en iyi sonucu verir (profesyonel araçlar, uzmanlaşmış veritabanları). Riski şu: yüksek sürtünme, ürünü henüz denememiş kullanıcıları uzaklaştırır.

Freemium#

En yaygın mobil kalıp. Gerçekten kullanışlı bir ücretsiz katman sunun, ardından gelişmiş özellikleri aboneliğin arkasına koyun. Buradaki denge: ücretsiz katman kullanıcıyı tutmaya yetecek kadar iyi, yükseltmeye ikna edecek kadar sınırlı olmalı.

Metered Paywall#

Kullanıcılar dönem başına belirli sayıda ücretsiz kullanım hakkı alır, sonra abone olmalıdır. New York Times bu kalıbı haber uygulamaları için popülerleştirdi. Kullanıcının abone olmadan önce içeriği denemesi gereken, içerik ağırlıklı uygulamalarda iyi sonuç verir.

Hybrid#

Birden fazla yaklaşımın öğelerini birleştirir. Tipik bir hibrit yaklaşım, ücretsiz deneme süresi sunabilir, freemium’a geçiş yapabilir ve belirli premium içeriğe ölçülü sınırlar uygulayabilir. Esnek monetizasyona ihtiyaç duyan SaaS tarzı mobil uygulamalarda giderek yaygınlaşıyor.

Deneme Süreleri#

Apple ve Google ücretsiz deneme sürelerini yerleşik olarak destekler. Denemeler iptal edilmediği sürece otomatik olarak ücretli aboneliklere dönüşür. Pratik bir not: paywall arayüzünde deneme koşullarını net şekilde iletin. Belirsiz deneme iletişimi geri ödemelere, kötü yorumlara ve potansiyel mağaza politikası ihlallerine yol açar.

Doğrudan Entegrasyon Yerine Neden RevenueCat#

IAP’yi doğrudan StoreKit 2 (iOS) ve Google Play Billing Library v7 (Android) ile uygulamak mümkündür ama ölçekte zorlaşır. Her platformun kendi API’si, makbuz formatı ve abonelik yaşam döngüsü semantiği vardır.

Çapraz Platform Zorluğu#

Konu	Doğrudan Entegrasyon	RevenueCat
Makbuz doğrulama	Her mağaza için ayrı geliştirme	Sunucu tarafında otomatik
Abonelik durumu	Platformlar arası kendiniz takip	Birleşik müşteri görünümü
Grace period ve yeniden deneme	Platform başına özel mantık	Otomatik
Paywall yapılandırma	Uygulama güncellemesi gerekli	Uzaktan yapılandırma
Analitik (MRR, churn)	Geliştirme veya üçüncü taraf	Hazır gösterge paneli
A/B testi	Özel altyapı	Yerleşik destek

RevenueCat Ne Sağlar#

RevenueCat her iki mağaza üzerinde bir soyutlama katmanı olarak çalışır. SDK şunları yönetir:

• Birleşik satın almalar: iOS, Android, Amazon ve Stripe web faturalandırması için tek API
• Sunucu tarafı makbuz doğrulama: Apple ve Google sunucuları ile satın almaları otomatik doğrular
• Abonelik yaşam döngüsü: Denemeleri, grace period’ları, faturalandırma yeniden denemelerini ve iptalleri yönetir
• Offering sistemi: Uygulama güncellemesi olmadan ürünleri ve paywall’ları uzaktan yapılandırın
• RevenueCat Paywalls: Önceden hazırlanmış, özelleştirilebilir paywall UI şablonları
• Webhook’lar: Backend’inize gerçek zamanlı abonelik olayları gönderir
• Analitik: MRR, churn oranı, LTV, deneme dönüşüm oranları hazır olarak sunulur

Fiyatlandırma Değerlendirmesi#

RevenueCat fiyatlandırması gelirle ölçeklenir:

• Ücretsiz: Aylık $2.500 MTR’ye (aylık takip edilen gelir) kadar
• Starter: $2.500 üzeri MTR’nin %1’i
• Pro: $119/ay + MTR’nin %0,9’u
• Enterprise: Özel fiyatlandırma

Yüksek ölçekte yüzdelik ücret birikir. Ayda $100K gelir üreten bir uygulama için RevenueCat maliyeti Pro planda $1.000/ay’ın biraz üzerindedir ($119 artı MTR’nin %0,9’u). Bunun değerli olup olmadığı, tasarruf edilen mühendislik zamanına kıyasla kendi abonelik altyapınızı kurma ve sürdürme maliyetine bağlıdır.

Doğrudan Entegrasyonun Mantıklı Olduğu Durumlar#

• Abonelik mantığı olmayan basit tek seferlik satın alma uygulamaları
• Makbuz doğrulama davranışı üzerinde tam kontrol gerektiğinde
• RevenueCat ücretlerinin özel bir ekibin maliyetini aştığı çok yüksek gelirli uygulamalar

Makbuz Doğrulama: Sunucu Tarafı Şart#

İstemci tarafı makbuz doğrulama atlatılabilir. Değiştirilmiş uygulama dosyaları, jailbreak’li cihazlar ve proxy araçları makbuzları taklit edebilir veya yeniden oynatabilir. Sunucu tarafı doğrulama, ister RevenueCat sunucularında ister kendi sunucunuzda çalışsın, ciddi monetizasyon için temel gerekliliktir.

Doğrulama Akışı#

Apple App Store Server API#

Apple’ın sunucu tarafı doğrulaması, kullanımdan kaldırılan verifyReceipt endpoint’inin yerine App Store Server API’yi kullanır. Temel noktalar:

• Kriptografik doğrulama için JWS imzalı işlemler
• Tam satın alma geçmişi için transaction history endpoint’i
• Gerçek zamanlı abonelik olayları için App Store Server Notifications V2 (SUBSCRIBED, DID_RENEW, EXPIRED, REFUND)

Google Play Developer API#

Google’ın doğrulaması Android Publisher API’yi kullanır:

• Abonelik durumu için purchases.subscriptions.get
• Tek seferlik satın almalar için purchases.products.get
• Google Cloud Pub/Sub üzerinden Real-time Developer Notifications (RTDN)

Sunucu Bildirimleri Zorunludur#

Her iki mağaza da abonelik durumları değiştiğinde gerçek zamanlı olaylar gönderir. Bunları işlemezseniz backend’inizde eski yetkilendirme verileri kalır:

• Kullanıcı iptal eder ama dönem sonuna kadar hala erişimi vardır
• İlk başarısızlıktan sonra faturalandırma yeniden denemesi başarılı olur
• Geri ödeme işlenir ve erişimi iptal etmeniz gerekir

Satın Alma Geri Yükleme: Zorunlu Bir Özellik#

Apple ve Google, kullanıcıların önceki satın almalarını geri yüklemeleri için bir mekanizma sağlanmasını zorunlu kılar. Bu özelliğin eksikliği uygulama reddine yol açabilir ve destek talebi yaratır.

Geri Yükleme Gerektiren Durumlar#

• Cihaz yükseltmeleri veya değişiklikleri
• Uygulama yeniden yükleme
• Fabrika sıfırlamaları
• Family Sharing (Apple): aile üyeleri arasında paylaşılan abonelikler

Uygulama Yaklaşımı#

RevenueCat ile geri yükleme, müşteri kimliği senkronizasyonu aracılığıyla otomatik olarak yönetilir. Kullanıcı yeni bir cihazda oturum açtığında, RevenueCat müşteriyi eşleştirir ve yetkilendirmeleri otomatik olarak geri yükler.

Doğrudan entegrasyon için:

// iOS - StoreKit 2
// Uygulama başlangıcında mevcut yetkilendirmeleri kontrol et
const checkEntitlements = async () => {
  // StoreKit 2 işlemleri otomatik olarak senkronize eder
  // Transaction.currentEntitlements tüm aktif yetkilendirmeleri döner
  for await (const result of Transaction.currentEntitlements) {
    // Her aktif yetkilendirmeyi işle
    await grantAccess(result);
  }
};

// Android - Google Play Billing Library v7
// Mevcut satın almaları sorgula
const restorePurchases = async (billingClient: BillingClient) => {
  const params = QueryPurchasesParams.newBuilder()
    .setProductType(ProductType.SUBS)
    .build();

  const purchasesResult = await billingClient.queryPurchasesAsync(params);
  // Her satın almayı işle ve erişimi geri yükle
  for (const purchase of purchasesResult.purchasesList) {
    await acknowledgePurchaseIfNeeded(purchase);
    await grantAccess(purchase);
  }
};

Ele Alınması Gereken Uç Durumlar#

• Account hold (Google): Kullanıcının geçici olarak erişimini kaybettiği, iptalden önceki grace period
• Faturalandırma yeniden denemesi: Her iki mağaza da başarısız ödemeleri otomatik olarak yeniden dener; backend’inizin durum geçişlerini yönetmesi gerekir
• Geri ödemeler: Geri ödeme işlendiğinde yetkilendirmeyi iptal edin. Apple REFUND bildirimi gönderir; Google REVOKED bildirimi gönderir
• Çapraz platform geri yükleme: iOS’ta satın alan bir kullanıcı Android’de de erişim bekler (ve tam tersi). Bu bir backend yetkilendirme sistemi gerektirir; çok kanallı yetkilendirme senkronizasyonu yazısına bakabilirsiniz

Kod Örneği: RevenueCat Webhook’tan EventBridge’e#

Aşağıdaki backend handler, RevenueCat webhook olaylarını alır, doğrular ve downstream işleme için satın alma olaylarını AWS EventBridge’e yayınlar.

import {
  EventBridgeClient,
  PutEventsCommand,
} from "@aws-sdk/client-eventbridge";

const eventBridge = new EventBridgeClient({});

interface RevenueCatWebhookEvent {
  api_version: string;
  event: {
    type: string;
    app_user_id: string;
    product_id: string;
    period_type: string;
    purchased_at_ms: number;
    expiration_at_ms: number | null;
    store: "APP_STORE" | "PLAY_STORE" | "STRIPE" | "AMAZON";
    environment: "PRODUCTION" | "SANDBOX";
    price_in_purchased_currency: number;
    currency: string;
    transaction_id: string;
  };
}

export const handler = async (event: {
  headers: Record<string, string>;
  body: string;
}) => {
  // Webhook doğruluğunu kontrol et
  const authHeader = event.headers["authorization"];
  if (authHeader !== `Bearer ${process.env.REVENUECAT_WEBHOOK_SECRET}`) {
    return { statusCode: 401, body: "Unauthorized" };
  }

  const webhook: RevenueCatWebhookEvent = JSON.parse(event.body);
  const rcEvent = webhook.event;

  // Production'da sandbox olaylarını atla
  if (
    rcEvent.environment === "SANDBOX" &&
    process.env.NODE_ENV === "production"
  ) {
    return { statusCode: 200, body: "Sandbox event ignored" };
  }

  // RevenueCat olay türlerini domain olaylarına eşle
  const eventTypeMap: Record<string, string> = {
    INITIAL_PURCHASE: "purchase.completed",
    RENEWAL: "subscription.renewed",
    CANCELLATION: "subscription.cancelled",
    EXPIRATION: "subscription.expired",
    BILLING_ISSUE: "subscription.billing_failed",
    PRODUCT_CHANGE: "subscription.plan_changed",
  };

  const domainEventType = eventTypeMap[rcEvent.type];
  if (!domainEventType) {
    console.log(`İşlenmemiş olay türü: ${rcEvent.type}`);
    return { statusCode: 200, body: "Event type not handled" };
  }

  // EventBridge'e yayınla
  await eventBridge.send(
    new PutEventsCommand({
      Entries: [
        {
          Source: "payments.mobile-iap",
          DetailType: domainEventType,
          Detail: JSON.stringify({
            customerId: rcEvent.app_user_id,
            productId: rcEvent.product_id,
            store: rcEvent.store,
            transactionId: rcEvent.transaction_id,
            periodType: rcEvent.period_type,
            price: {
              amount: rcEvent.price_in_purchased_currency,
              currency: rcEvent.currency,
            },
            purchasedAt: new Date(rcEvent.purchased_at_ms).toISOString(),
            expiresAt: rcEvent.expiration_at_ms
              ? new Date(rcEvent.expiration_at_ms).toISOString()
              : null,
          }),
          EventBusName: process.env.EVENT_BUS_NAME || "default",
        },
      ],
    })
  );

  return { statusCode: 200, body: "Event processed" };
};

Bu handler, RevenueCat’in webhook formatı ile dahili olay şemanız arasında temiz bir sınır sağlar. Downstream tüketiciler (yetkilendirme servisi, analitik, bildirimler) RevenueCat’in detaylarını bilmeden EventBridge kurallarına abone olur.

Temel Çıkarımlar#

• Alternatif faturalandırmaya geçmek için özel bir nedeniniz yoksa standart IAP ile başlayın. Komisyon oranları yakınlaşıyor; doğrudan IAP’yi uygulamak da sürdürmek de daha basit.
• Paywall kalıbınızı içerik türünüze göre seçin, rakiplerin ne yaptığına göre değil. Freemium çoğu uygulama için çalışır, ama metered içerik ağırlıklı ürünler için daha iyi sonuç verir.
• Çapraz platform uygulamalarda RevenueCat kullanın. İstisna: satın alma akışınız çok basitse veya geliriniz özel bir abonelik altyapı ekibini karşılayacak kadar yüksekse.
• Gerçek gelir yöneten her uygulamada sunucu tarafı makbuz doğrulama zorunludur. Yalnızca istemci tarafında yapılan doğrulama bir güvenlik açığıdır.
• Mağaza bildirimlerini işleyin (Apple Server Notifications V2, Google RTDN). Bunlar olmadan yetkilendirme verileriniz gerçeklikten sapacaktır.
• Satın alma geri yükleme isteğe bağlı değildir: her iki mağaza da bunu zorunlu kılar, kullanıcılar da bekler. Cihaz transferleri, yeniden yüklemeler ve Family Sharing senaryolarında test edin.

Kaynaklar#

1. Apple App Store Review Guidelines (yeni sekmede açılır) - IAP gereksinimleri, reader app kuralları ve ödeme politikalarını kapsayan resmi yönergeler
2. Apple App Store Small Business Program (yeni sekmede açılır) - Yıllık $1M altı kazanan geliştiriciler için %15 indirimli komisyon detayları
3. Google Play Billing Documentation (yeni sekmede açılır) - Entegrasyon rehberleri ile resmi Android faturalandırma kütüphanesi belgeleri
4. RevenueCat Documentation (yeni sekmede açılır) - Kapsamlı SDK belgeleri, webhook referansı ve entegrasyon rehberleri
5. AB Dijital Pazar Yasası (yeni sekmede açılır) - Uygulama mağazası ödeme kurallarını etkileyen DMA düzenlemeleri hakkında Avrupa Komisyonu sayfası
6. Apple StoreKit 2 Documentation (yeni sekmede açılır) - Async/await API ve JWS imzalı işlemlerle modern Apple IAP framework’ü
7. App Store Server API (yeni sekmede açılır) - Sunucu tarafı satın alma doğrulama ve işlem geçmişi endpoint’leri
8. Google Play Developer API (yeni sekmede açılır) - Android abonelikleri ve ürünleri için sunucu tarafı satın alma doğrulama
9. RevenueCat Webhook Events Reference (yeni sekmede açılır) - Webhook olay türleri ve payload formatlarının tam listesi
10. Apple App Store Server Notifications V2 (yeni sekmede açılır) - Apple’dan gerçek zamanlı abonelik yaşam döngüsü bildirimleri
11. Google Real-time Developer Notifications (yeni sekmede açılır) - Google Play abonelik olayları için Pub/Sub tabanlı bildirim sistemi
12. RevenueCat Paywalls Documentation (yeni sekmede açılır) - Önceden hazırlanmış paywall şablonları ve uzaktan yapılandırma seçenekleri