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

Mobil monetizasyon ilk bakışta basit görünür -- ta ki ilk App Store red yanıtını alana ya da makbuz doğrulamanızda jailbreak'li cihazların premium içeriğe ücretsiz erişmesine izin veren bir açık keşfedene kadar. Uygulama mağazası ödeme kuralları, komisyon yapıları ve teknik gereksinimler, her mobil geliştiricinin dikkatli şekilde yönetmesi gereken karmaşık bir alan oluşturur.

Bu yazıda mobil IAP'nin pratik tarafını ele alıyoruz: her iki mağazanın gereksinimleri, farklı iş modelleri için çalışan paywall kalıpları, RevenueCat'in çapraz platform abonelik yönetimini neden basitleştirdiği ve event-driven mimari ile güvenilir bir makbuz doğrulama pipeline'ı nasıl kurulur.

Not: IAP zorunlu olmadığında doğru web ödeme sağlayıcısını seçmek için ödeme sağlayıcıları ve uyumluluk yazısına bakabilirsiniz. Doğrulanmış satın almaların platformlar arasında nasıl yayıldığını öğrenmek için çok kanallı yetkilendirme senkronizasyonu yazısını inceleyebilirsiniz.

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#

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 %17 (standart) veya %10 (küçük işletme) alır -- %30/%15 yerine
• Ç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ını seçmek içerik türünüze, kullanıcı tabanınıza ve iş modelinize bağlıdır.

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 veya uzmanlaşmış veritabanları gibi. Risk: ürünü henüz deneyimlememiş kullanıcıları yüksek sürtünme 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. Temel gerilim: ücretsiz katman kullanıcıları tutmaya yetecek kadar iyi, yükseltmeyi motive edecek kadar sınırlı olmalıdır.

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. İçerik ağırlıklı uygulamalarda, kullanıcıların taahhüt etmeden önce örnekleme yapması gerektiğinde iyi çalışır.

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 doğal 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.

Neden Doğrudan Uygulama Yerine 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#

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 yaklaşık$900-$1.000/ay'dır. 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 Uygulamanın 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ı Vazgeçilmez#

İ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, 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 bildirimlerine neden olur.

Kullanıcıların Neden İhtiyacı Var#

• 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 uygulama için:

// iOS - StoreKit 2// Uygulama başlangıcında mevcut yetkilendirmeleri kontrol etconst 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ı sorgulaconst 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 bakınız

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

İşte RevenueCat webhook olaylarını alan, doğrulayan ve downstream işleme için AWS EventBridge'e satın alma olayları yayınlayan pratik bir backend handler.

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(`Islenmemis olay turu: ${rcEvent.type}`);    return { statusCode: 200, body: "Event type not handled" };  }
  // EventBridge'e yayinla  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#

• Standart IAP ile başlayın -- alternatif faturalandırma kullanmak için özel bir nedeniniz yoksa. Komisyon oranları yakınlaşıyor ve doğrudan IAP uygulamak ve sürdürmek 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 uygulamalar için RevenueCat kullanın -- çok basit satın alma akışlarınız yoksa veya özel bir abonelik altyapı ekibini haklı çıkaracak kadar yüksek geliriniz yoksa.
• Sunucu tarafı makbuz doğrulama zorunludur -- gerçek gelir yöneten her uygulama için. Yalnızca istemci tarafı 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 ve kullanıcılar bunu bekler. Cihaz transferleri, yeniden yüklemeler ve Family Sharing senaryolarında test edin.

Kaynaklar#

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