Abonelik Bazlı Mobil Uygulama Modeli Nasıl Kurulur?

Abonelik bazlı mobil uygulama modeli kurmak için App Store ve Google Play faturalandırma sistemleri (IAP) entegre edilmeli, freemium veya paywall mimarisi oluşturulmalıdır. "Abonelik Bazlı Mobil Uygulama Modeli Nasıl Kurulur?" sorusunun yanıtı yalnızca basit bir kod parçasında değil; veri güvenliği, komisyon optimizasyonu, yasal uyumluluk ve kullanıcı tutundurma (retention) stratejilerinin doğru kurgulanmasında yatmaktadır. Bu rehber; yazılım mimarlarından kurumsal karar vericilere kadar tüm paydaşlar için sürdürülebilir, güvenli ve yüksek dönüşümlü bir mobil gelir modeli tasarlamanın teknik ve ticari yol haritasını sunmaktadır.

Abonelik Modeline Geçişte Kurumsal Strateji ve Planlama

Uygulamanız Abonelik Modeline Uygun Mu? (Sürdürülebilirlik Analizi)

Bir mobil uygulamanın tek seferlik satın alma modelinden veya reklam gelirlerinden abonelik bazlı bir modele (Subscription-Based Business Model) geçiş kararı, ürünün sunduğu temel değer önerisinin sürekliliğiyle doğrudan ilişkilidir. Kullanıcıya düzenli aralıklarla (haftalık, aylık, yıllık) dinamik içerik, yeni özellikler, bulut depolama, yapay zeka tabanlı veri işleme veya operasyonel kolaylık sunmayan uygulamalar abonelik modelinde başarısız olmaya mahkumdur. Örneğin, sadece tek bir probleme anlık çözüm sunan ve tekrarlayan kullanımı bulunmayan niş bir hesap makinesi uygulaması için abonelik dayatmak, kullanıcı kaybını (churn) dramatik şekilde artırır.

Sürdürülebilirlik analizinde uygulamanın kategorisi ve kullanım sıklığı belirleyici rol oynar. SaaS (Software as a Service) çözümleri, e-öğrenme (EdTech) platformları, içerik akış (streaming) servisleri, düzenli güncellenen fitness/sağlık uygulamaları ve iş verimliliği (productivity) araçları abonelik modeline en yüksek uyum gösteren segmentlerdir. Bu tür uygulamalarda kullanıcıya sunulan fayda zamanla birikir ve kullanıcının sistemde kalma motivasyonu artar.

Hedef pazarların sosyo-ekonomik dinamikleri de bu modelin başarısında kritik bir değişkendir:

• Amerika Birleşik Devletleri (US) ve Birleşik Krallık (UK): Abonelik yorgunluğu (subscription fatigue) seviyesi yüksek olmasına rağmen, kullanıcıların "değer üreten" yazılımlara aylık ödeme yapma alışkanlığı son derece olgundur. Bu pazarlarda ürün kalitesi ve kesintisiz kullanıcı deneyimi (UX) dönüşümün anahtarıdır.

• Birleşik Arap Emirlikleri (AE): Yüksek satın alma gücüne sahip, premium ve VIP özelliklere bütçe ayırmaktan kaçınmayan, ancak kişiselleştirilmiş hizmet beklentisi üst düzeyde olan bir kitle mevcuttur.

• Türkiye (TR): Fiyat hassasiyeti yüksek olduğundan yerelleştirilmiş fiyatlandırma (localized pricing) stratejileri, esnek ödeme periyotları ve şeffaf iptal mekanizmaları kurulması şarttır.

Gelir Öngörüsü: MRR, LTV ve Churn Metriklerinin Temelleri

Abonelik modelinin finansal motorunu yönetmek, geleneksel e-ticaret veya tek seferlik satış modellerinden çok farklı matematiksel formüllere dayanır. Modelin merkezinde Aylık Tekrarlayan Gelir (MRR - Monthly Recurring Revenue) ve Yıllık Tekrarlayan Gelir (ARR - Annual Recurring Revenue) yer alır. MRR, o ay aktif olan ve ödeme yapan tüm kullanıcıların net abonelik bedellerinin toplamıdır. Gelir modelinin sağlıklı büyüdüğünü doğrulamak için Cohort (Kohort) analizi yapılarak kullanıcıların aylar içerisindeki davranışsal sadakati ölçülmelidir.

Müşteri Yaşam Boyu Değeri (LTV - Lifetime Value), bir kullanıcının uygulamada kaldığı süre boyunca şirkete kazandırdığı toplam net ekonomik değerdir. Churn Rate (Müşteri Kaybı Oranı) ise belirli bir dönemde aboneliğini sonlandıran kullanıcıların toplam abone sayısına oranıdır. LTV'yi hesaplamak için kullanılan temel matematiksel formül şu şekildedir:

$$\text{LTV} = \frac{\text{ARPU (Kullanıcı Başına Ortalama Gelir)}}{\text{Churn Rate}}$$

Bu formülün sürdürülebilir bir iş modeline dönüşebilmesi için LTV ile Müşteri Edinme Maliyeti (CAC - Customer Acquisition Cost) arasındaki oranın (LTV:CAC) asgari 3:1 seviyesinde olması gerekir. Eğer CAC değeriniz LTV değerinize yaklaşıyorsa veya onu geçiyorsa (1:1 veya daha düşük), kullanıcı kazanmak için harcadığınız pazarlama bütçesi şirketi finansal zarara uğratıyor demektir. Churn oranını %1 dahi düşürmek, LTV değerini çarpan etkisiyle yukarı taşıyarak kârlılığı doğrudan optimize eder.

---

Finansal Yapı: App Store ve Google Play Komisyon Politikaları

Apple ve Google Standart Kesinti Oranları (%30 vs. %15 Kuralı)

Apple App Store ve Google Play Store, platformlarında dağıtılan uygulamaların dijital ürün ve abonelik satışlarından standart olarak %30 oranında komisyon kesintisi yapar. Bu kesinti, kullanıcı faturayı ödediği anda otomatik olarak tahsil edilir ve kalan tutar geliştiricinin hesabına aktarılır. Ancak abonelik modelini teşvik etmek amacıyla her iki platform da geliştirici dostu bir esneklik sunmaktadır: Bir kullanıcı aynı uygulamanın aboneliğinde kesintisiz olarak 12 ayı (1 yıl) tamamladığında, sonraki faturalama dönemlerinden itibaren komisyon oranı otomatik olarak %15'e düşer.

Finansal projeksiyonlar yapılırken net gelir hesabı sadece komisyon üzerinden kurulmamalıdır. Ülkelerin yerel vergi kanunları, katma değer vergileri (KDV / VAT), dijital hizmet vergileri ve stopaj kesintileri platformlar tarafından brüt fiyattan düşülür. Örneğin:

• Türkiye (TR): %20 oranındaki KDV ve varsa diğer yasal kesintiler, brüt abonelik ücretinden düşüldükten sonra kalan matrah üzerinden Apple/Google komisyonu hesaplanır.

• Birleşik Krallık (UK): Standart %20 VAT kesintisi uygulanır.

• Birleşik Arap Emirlikleri (AE): Standart %5 VAT kesintisi mevcuttur.

• Amerika Birleşik Devletleri (US): Eyalet bazlı satış vergileri (Sales Tax) son kullanıcı faturasına eklenerek tahsil edilir veya eyalet yasalarına göre geliştirici matrahından mahsup edilir.

Aşağıdaki tablo, 10 USD brüt abonelik ücreti üzerinden standart ve 1 yılını doldurmuş kullanıcılar için basitleştirilmiş bir gelir dağılımı simülasyonunu göstermektedir (Vergiler ülkeden ülkeye değiştiği için bu tabloda vergi düşülmemiş doğrudan matrah esas alınmıştır):

Küçük İşletme Programları ve Komisyon İndirimlerinden Yararlanma Şartları

Geliştiricilerin ve KOBİ'lerin finansal yükünü hafifletmek adına Apple, App Store Small Business Program; Google ise Google Play 15% Service Fee Tier programlarını devreye almıştır. Bu programlar sayesinde, belirli ciro limitlerinin altında kalan işletmeler ilk günden itibaren %15 komisyon oranından yararlanabilmektedir.

• Apple App Store Small Business Program: Bir takvim yılı içerisinde tüm ilişkili geliştirici hesaplarından elde edilen net geliri (komisyon ve vergiler düştükten sonra geliştiriciye kalan tutar) 1 milyon USD'nin altında olan şirketler bu programa başvurabilir. Başvuru onaylandıktan sonraki dönemde yapılan tüm satışlarda komisyon oranı %15 olarak uygulanır. Eğer net gelir yıl içinde 1 milyon USD sınırını aşarsa, sınırın aşıldığı andan itibaren standart %30 oranı devreye girer.

• Google Play %15 Hizmet Ücreti Kademesi: Google Play'de her geliştirici hesabı (veya ilişkili geliştirici grupları), her takvim yılında elde ettiği ilk 1 milyon USD brüt geliri için otomatik olarak %15 komisyon öder. Gelirin 1 milyon USD'yi aşan kısmı için o yıl içinde %30 standart oran uygulanır. Google Play sisteminde Apple'dan farklı olarak her yılın ilk 1 milyon USD'lik dilimi için indirim hakkı sıfırlanarak tekrar sunulur ve başvuru süreci Apple kadar katı değildir; ancak ilişkili hesapların (Associated Developer Accounts) beyan edilmesi zorunludur.

---

Teknik Mimari: In-App Purchase (IAP) Entegrasyonu Nasıl Yapılır?

Apple StoreKit ve Google Play Billing Library Kurulum Adımları

Teknik entegrasyonun temelini, her iki platformun da kendi yerel işletim sistemleri için sağladığı resmi kütüphaneler oluşturur. iOS tarafında modern Swift projelerinde StoreKit 2 API'leri kullanılırken, Android tarafında Kotlin tabanlı Google Play Billing Library (Güncel sürüm v6 veya v7) entegre edilmelidir. Client-side (istemci tarafı) implementasyon adımları, kullanıcının mağaza arayüzü ile doğrudan etkileşime girmesini sağlar.

iOS üzerinde StoreKit 2 ile bir abonelik satın alma akışı şu kod mimarisiyle başlatılır:

import StoreKit

// Ürünleri mağazadan çekme
let productIds: Set<String> = ["com.webizm.app.monthly_premium"]
let products = try await Product.products(for: productIds)

if let premiumProduct = products.first {
    // Satın alma işlemini tetikleme
    let result = try await premiumProduct.purchase()
    
    switch result {
    case .success(let verificationResult):
        // JWS (JSON Web Signature) doğrulaması
        switch verificationResult {
        case .verified(let transaction):
            // İşlem başarılı ve Apple tarafından imzalanmış. Entitlement verilebilir.
            await transaction.finish()
            await updateEntitlementStatus(for: transaction)
        case .unverified(_, let error):
            // İmza doğrulanamadı, güvenlik ihlali veya manipülasyon şüphesi
            print("Doğrulama başarısız: \(error.localizedDescription)")
        }
    case .pending:
        // Ebeveyn onayı bekleyen (Ask to Buy) veya banka provizyon aşamasındaki işlemler
        break
    case .userCancelled:
        // Kullanıcı satın alma ekranını kapattı
        break
    @unknown default:
        break
    }
}

Android tarafında ise @@CODE0@@ nesnesi üzerinden asenkron bir bağlantı kurulması ve satın alma dinleyicisinin (@@CODE1@@) doğru şekilde konfigüre edilmesi gerekir. Android istemcisinin yaşam döngüsü (lifecycle) yönetimi esnasında bağlantının kopması veya arka plana alınması gibi durumlara karşı, bağlantının her istek öncesinde aktif olup olmadığı mutlaka kontrol edilmelidir.

Backend İhtiyaçları ve Cross-Platform Senkronizasyon Zorlukları

Yalnızca istemci tarafında (App-Side Only) yapılan satın alma doğrulamaları büyük bir güvenlik açığıdır. Jailbreak yapılmış cihazlarda istemci bellek manipülasyonu yapan araçlar (örneğin iOS'te yerel sertifika taklit eden araçlar veya Android'de lisans yamalayıcılar) kullanılarak uygulama içi satın alma ekranları kolayca baypas edilebilir. Bu nedenle, kurumsal bir abonelik yapısında Server-to-Server (S2S) Validation (Sunucudan Sunucuya Doğrulama) mimarisi kurulması zorunludur.

S2S mimarisinde, Apple ve Google sunucularından gelen anlık olay bildirimleri (Webhooks) işlenir. Apple App Store Server Notifications V2, Google ise Google Play Real-Time Developer Notifications (RTDN) servislerini sunar. Bu servisler sayesinde bir kullanıcı aboneliğini iptal ettiğinde, ödemesi başarısız olduğunda, duraklatıldığında veya geri ödeme (refund) aldığında, platformlar doğrudan sizin backend sunucunuza güvenli bir JSON post isteği gönderir.

Backend katmanında çözülmesi gereken en büyük zorluk, çapraz platform (cross-platform) senkronizasyonudur. Bir kullanıcının iOS cihazından satın aldığı aylık aboneliği, web tarayıcısında veya Android tabletinde de kullanabilmesi gerekir. Bunu sağlamak için:

1. Satın alma işlemi başlatılmadan önce, kullanıcının uygulamanızda benzersiz bir hesaba (UID) sahip olması zorunlu tutulmalıdır.

2. Satın alma başarılı olduktan sonra Apple/Google tarafından üretilen orijinal işlem kimliği (@@CODE0@@ veya @@CODE1@@), backend veritabanınızda o kullanıcının profil kaydıyla (UUID) eşleştirilmelidir.

3. Abonelik durumunu sorgulayan yetki (Entitlement) kontrolü, istemci cihazdan değil, her açılışta doğrudan sizin backend API'niz üzerinden gerçekleştirilmelidir.

Geliştirme Sürecini Hızlandıran Altyapılar: RevenueCat ve Qonversion Kullanımı

Sıfırdan bağımsız bir abonelik backend mimarisi kurmak; Apple ve Google'ın sürekli güncellenen API versiyonlarını takip etmeyi, karmaşık veritabanı durum makinelerini (state machines) yönetmeyi ve yüksek erişilebilirlikli webhook kuyruk sistemleri tasarlamayı gerektirir. Bu süreç kıdemli bir yazılım ekibi için ortalama 3 ila 6 aylık yoğun bir geliştirme ve test mesaisi anlamına gelir.

Bu süreyi ve teknik riskleri minimize etmek için RevenueCat, Qonversion veya Adapty gibi hazır abonelik yönetim platformları (Subscription Infrastructure Providers) tercih edilmektedir. Bu platformlar, geliştirdiğiniz mobil uygulamaya eklenen hafif bir SDK ve bulut tabanlı bir panel aracılığıyla tüm karmaşık süreçleri soyutlar.

Aşağıdaki şemada, geleneksel bir özel backend mimarisi ile hazır bir altyapı sağlayıcısının (örneğin RevenueCat) sağladığı akışın teknik karşılaştırması yer almaktadır:

[Geleneksel Özel Mimari]:
App --(Satın Alma Tetikleme)--> App Store/Google Play --(Receipt)--> App
App --(Receipt Gönderimi)--> Kendi Backend Sunucunuz --(API Doğrulama)--> Apple/Google API
Kendi Backend Sunucunuz --(Webhook Dinleme/İşleme)--> DB Güncelleme --> App Entitlement

[Yararlanıcı SDK Mimarisi (RevenueCat)]:
App --(RevenueCat SDK purchase())--> App Store/Google Play
RevenueCat Cloud --(Anlık S2S Entegrasyonu)--> Apple/Google (Doğrulama ve Durum Takibi)
RevenueCat Cloud --(Basitleştirilmiş Webhook)--> Kendi Sunucunuz (İsteğe bağlı veri senkronizasyonu)
App --(SDK Entitlement Check)--> Premium Yetki Kilidi Açılır

---

Kullanıcı Deneyimi ve Dönüşüm: Paywall (Ödeme Duvarı) Mimarisi

Freemium Modeli ile Premium Model Arasındaki Keskin Çizgiyi Belirlemek

Abonelik modelinin en popüler türevi olan Freemium (Free + Premium) iş modelinde, uygulamanın temel özellikleri tüm kullanıcılara ömür boyu ücretsiz sunulurken, gelişmiş özellikler, ek içerikler veya reklamsız deneyim ödeme duvarının (paywall) arkasına gizlenir. Buradaki en kritik yönetimsel karar, "neyin ücretsiz kalacağı" ve "neyin ücretli olacağı" arasındaki dengenin kurulmasıdır.

Eğer ücretsiz sürüm çok fazla özellik barındırıyorsa, kullanıcıların premium aboneliğe geçiş yapma motivasyonu (conversion intent) düşük kalır. Aksine, eğer ücretsiz sürüm neredeyse hiçbir işe yaramayacak kadar kısıtlayıcıysa, kullanıcılar uygulamayı ilk 5 dakika içinde cihazlarından kaldırır (day-1 retention kaybı). Çizgiyi netleştirmek için kullanıcıların "aha! momenti" olarak adlandırılan, uygulamadan ilk gerçek faydayı sağladıkları anı analiz etmelisiniz. Bu faydayı sağlayan temel fonksiyon ücretsiz kalmalı, bu faydanın hızını, kapasitesini, derinliğini veya estetiğini artıran katmanlar ise premium olmalıdır.

Örneğin, bir yapay zeka tabanlı görsel düzenleme uygulamasında:

• Ücretsiz Özellik: Temel filtrelerle günde 3 adet görsel işleme hakkı (kullanıcıya ürünün çalıştığı ve kaliteli olduğu ispatlanır).

• Premium Özellik: Sınırsız görsel işleme, yüksek çözünürlüklü (4K) çıktı alma, filigranın (watermark) kaldırılması ve gelişmiş nesne silme araçları.

Yüksek Dönüşümlü Bir Paywall Arayüzü Nasıl Tasarlanmalı?

Paywall (Ödeme Duvarı), uygulamanızın finansal dönüşüm noktasıdır. Başarılı bir paywall tasarımı; netlik, güvenilirlik, kullanıcı psikolojisi ve yasal yönergelerin mükemmel bir birleşimidir. Tasarımda karmaşık tablolar veya anlaşılması güç yasal terimler yerine, kullanıcının o anda elde edeceği temel faydalara odaklanılmalıdır.

Dönüşüm oranlarını artıran kanıtlanmış paywall UX elementleri şunlardır:

1. Değer Önerisi Odaklı Başlık (Value Hook): "Premium'a Geç" gibi jenerik ifadeler yerine, "Tüm Raporlarınızı Saniyeler İçinde PDF'e Dönüştürün" gibi doğrudan probleme dokunan başlıklar tercih edilmelidir.

2. Fiyat Ankrajı (Price Anchoring): Genellikle en pahalı olan yıllık paket, aylık bazda bölünerek ("Sadece 4.99 USD / Ay") gösterilir ve yanına aylık paketin normal fiyatı ("Aylık 12.90 USD") yerleştirilerek yıllık paketin %60 daha avantajlı olduğu vurgulanır.

3. Birincil Eylem Butonu (Primary CTA): Dikkat çeken, arka planla kontrast oluşturan, üzerinde "Ücretsiz Denemeyi Başlat ve Katıl" veya "Şimdi Başla" yazan belirgin bir buton yer almalıdır.

4. Güven Verici Detaylar (Trust Badges): "İstediğiniz zaman kolayca iptal edebilirsiniz", "Taahhüt yoktur", "Güvenli 256-bit mağaza ödemesi" gibi ibareler kullanıcının satın alma kaygısını (friction) en aza indirir.

Ücretsiz Deneme (Free Trial) Stratejileri ve Suistimal Önleme Yöntemleri

Ücretsiz deneme süreleri (Free Trial), kullanıcıyı abonelik modeline alıştırmanın en etkili yoludur. Genellikle 3 günlük, 7 günlük veya 14 günlük deneme süreleri sunulur. En sık yapılan hata, her uygulama kategorisine standart 7 günlük deneme süresi tanımlamaktır. Kullanıcının uygulamanızın değerini anlaması için gereken süre (Time-to-Value) analiz edilmelidir. Eğer kullanıcı uygulamanın faydasını ilk 10 dakikada anlıyorsa (örneğin bir dosya dönüştürücü), 3 günlük bir deneme süresi yeterlidir. Eğer uygulama zamanla veri biriktirdikçe değer kazanıyorsa (örneğin bir bütçe takip uygulaması), 14 günlük bir deneme süresi daha yüksek dönüşüm sağlayabilir.

Deneme sürelerinin suistimal edilmesi (trial looping), geliştiriciler için önemli bir ciro kaybı kaynağıdır. Kullanıcılar sürekli yeni geçici e-posta hesapları açarak ücretsiz deneme süresini sonsuza dek uzatmak isteyebilirler. Bunun önüne geçmek için şu teknik önlemler uygulanmalıdır:

• Cihaz Kimliği (Device Fingerprinting) Kontrolü: iOS tarafında @@CODE0@@ veya @@CODE1@@ API'leri, Android tarafında ise Play Integrity API kullanılarak, o fiziksel cihazın daha önce bir deneme süresi başlatıp başlatmadığı donanım düzeyinde güvenli şekilde kontrol edilmeli ve tek bir cihaza birden fazla deneme hakkı tanınmamalıdır.

• Original Transaction ID Kontrolü: Backend sunucusunda, yeni oluşturulan hesapların sunduğu makbuzların (receipts) orijinal işlem kimlikleri veritabanında sorgulanmalıdır. Eğer aynı Google/Apple hesabı ile ilişkili makbuz daha önce başka bir yerel hesapta kullanılmışsa, deneme süresi bloke edilmelidir.

---

Risk Yönetimi ve Yasal Uyum: Mağaza Reddi (App Rejection) Nasıl Önlenir?

Abonelik Şartlarının ve Gizlilik Politikalarının Doğru İbrazı

Apple ve Google, kullanıcıların farkında olmadan veya yanıltıcı (deceptive UX) yöntemlerle aboneliğe başlatılmasını engellemek amacıyla son derece katı kurallar uygulamaktadır. Uygulamanızın mağaza inceleme sürecinden (App Store Review / Google Play Console Release) başarıyla geçebilmesi için paywall ekranında ve uygulama ayarlarında yasal metinlerin eksiksiz bulunması zorunludur.

Her paywall ekranının alt kısmında, okunabilir boyutta şu bilgiler açıkça yazılmalıdır:

• Abonelik ücretinin tam tutarı ve faturalama periyodu (Örn: "Yıllık 49.99 USD, iptal edilmediği sürece otomatik olarak yenilenir.").

• Varsa ücretsiz deneme süresinin net kuralları (Örn: "7 gün ücretsiz, ardından yıllık 49.99 USD. Deneme süresi bitmeden en az 24 saat önce iptal ederseniz ücret yansıtılmaz.").

• Kullanım Koşulları (EULA / Terms of Use) ve Gizlilik Politikası (Privacy Policy) belgelerine doğrudan yönlendiren tıklanabilir aktif bağlantılar (deep-links).

Ayrıca, hedeflediğiniz pazarlara göre yerel veri koruma kanunlarına tam uyum sağlamalısınız. Avrupa Birliği ülkeleri için GDPR, Birleşik Krallık için UK GDPR, Türkiye için KVKK ve Amerika Birleşik Devletleri için eyalet düzeyindeki gizlilik yasaları (örneğin Kaliforniya için CCPA) uyarınca, kullanıcının kişisel verilerini ve satın alma geçmişini rızası olmadan üçüncü parti analiz araçlarıyla paylaşmamalı, rıza yönetim pencerelerini (Consent Management Platforms) uygulama açılışında doğru şekilde sunmalısınız.

Abonelik İptal ve Geri Ödeme (Refund) Süreçlerinin Yönetimi

Abonelik iptali süreçlerini zorlaştırmak, saklamak veya "karanlık desenler" (dark patterns) olarak adlandırılan manipülatif arayüz tasarımlarıyla engellemeye çalışmak hem Apple/Google politikalarının doğrudan ihlalidir hem de ciddi tüketici koruma davalarına (örneğin ABD FTC veya Birleşik Krallık CMA soruşturmaları) yol açabilir.

• İptal Kolaylığı Kuralı: Apple App Store Review Guidelines (Özellikle Madde 3.1.2) uyarınca, uygulamanızın ayarlar veya profil menüsünde, kullanıcının sistem abonelik ayarlarına doğrudan gitmesini sağlayan bir buton bulunmalıdır. iOS üzerinde https://apps.apple.com/account/subscriptions URL'ine yönlendiren bir yönlendirme köprüsü (deep link) kurulması onay sürecini hızlandırır.

• Geri Ödeme Politikaları: Geliştiriciler, uygulama içi satın almalarda doğrudan geri ödeme yapma yetkisine sahip değildir; bu süreç tamamen Apple ve Google'ın inisiyatifindedir. Ancak sunucunuz, platformlardan gelen REFUND webhook bildirimini aldığı an, ilgili kullanıcının premium yetkilerini veritabanında askıya alacak şekilde kodlanmalıdır. Aksi halde, geri ödeme alıp uygulamayı ücretsiz kullanmaya devam eden suiistimalci bir kitle oluşacaktır.

Apple ve Google'ın Katı Abonelik Yönergelerinde Dikkat Edilmesi Gerekenler

Uygulamanızın mağazaya gönderildikten sonra reddedilmesini (rejection) önlemek için teknik ekiplerin ve ürün yöneticilerinin App Store İnceleme Yönergeleri ile Google Play Geliştirici Politikaları'ndaki hassas maddelere tam uyum göstermesi gerekir.

En sık karşılaşılan reddedilme nedenleri şunlardır:

• Geri Yükle (Restore Purchases) Butonunun Eksikliği: Kullanıcı cihazını değiştirdiğinde veya uygulamayı silip tekrar yüklediğinde, daha önce satın aldığı aktif aboneliği ücret ödemeden geri yükleyebilmelidir. Paywall ekranında net bir şekilde görünen ve çalışan bir "Restore" veya "Satın Almaları Geri Yükle" butonu bulunmak zorundadır.

• Alternatif Ödeme Yönlendirmeleri: Apple ve Google'ın izin verdiği istisnai durumlar (örneğin Reader App muafiyeti veya AB dijital pazarlar yasası kapsamındaki alternatif ödeme yöntemleri) haricinde, uygulama içinden harici bir web sitesine yönlendirme yaparak "Kredi kartıyla web sitemizden daha ucuza satın alın" şeklinde linkler koymak doğrudan mağazadan atılma sebebidir. Tüm dijital içerik satışları ilgili platformun kendi faturalandırma sistemiyle (IAP) yapılmalıdır.

---