Uygulama İçi Satın Alma ve Abonelik Modelleri

Uygulamanın para kazanma modeli genellikle geliştirme bitmek üzereyken konuşulur: "Premium özellikleri ücretli yapalım, bir de aylık plan koyalım." Ama satın alma ve abonelik altyapısı sonradan eklenen bir buton değildir; mağaza kuralları, ürün tanımları, sunucu tarafında doğrulama ve kullanıcının hangi içeriğe erişeceğini belirleyen yetki mantığı birlikte tasarlanmalıdır. Bu rehberde uygulama içi satın alma türlerini, tek seferlik ödeme, abonelik ve freemium modellerinin hangi ürüne uyduğunu, App Store ve Google Play'in temel kurallarını ve satın almaların sunucuda neden ve nasıl doğrulanması gerektiğini anlatıyoruz.

Uygulama içi satın alma nedir, hangi türleri var?

Uygulama içi satın alma (in-app purchase), kullanıcının uygulama içinden dijital içerik veya özellik satın almasını sağlayan ve ödemesi mağazanın kendi sistemiyle alınan işlemdir. Kart bilgisi sizin sunucunuza hiç gelmez; tahsilatı, faturayı, iadeleri ve abonelik yenilemesini mağaza yönetir. Apple dört ürün türü tanımlar, Google Play ise benzer türleri "tek seferlik ürünler" ve "abonelikler" başlıkları altında toplar.

Ürünler App Store Connect'te ve Play Console'da ayrı ayrı tanımlanır; her birinin bir ürün kimliği (product ID) olur. Bu kimlikleri iki mağazada aynı tutmak, örneğin premium_aylik ve premium_yillik, uygulama ve sunucu kodunu sadeleştirir.

Gelir modelleri: hangisi sizin ürününüze uyar?

Model seçimini belirleyen soru şudur: Kullanıcı uygulamadan bir kez mi değer alıyor, yoksa sürekli mi? Sürekli içerik üreten, sunucu maliyeti olan ya da düzenli güncellenen bir ürün için abonelik doğaldır. Bir kez satın alınıp yıllarca kullanılan bir araç için ise abonelik kullanıcıya haksız gelebilir.

Uygulamada modeller sıkça birleştirilir: reklamlı ücretsiz katman, reklamları kaldıran tek seferlik ürün ve ileri özellikleri açan abonelik bir arada olabilir. Ancak her ek katman, satın alma ekranını ve destek yükünü karmaşıklaştırır. İlk sürümde tek bir ücretli katmanla başlayıp kullanıcı davranışını gördükten sonra genişletmek daha sağlıklıdır; bu yaklaşımı MVP rehberimizde ayrıntılı anlattık.

Freemium'da en sık hata, ücretsiz katmanı ya çok cömert ya da çok kısıtlı tutmaktır. Kullanıcı, ürünün değerini ücretsiz katmanda görebilmeli ama düzenli kullandıkça ücretli katmanın sınırına doğal olarak ulaşmalıdır. Proje sayısı, kayıt sayısı, depolama alanı veya dışa aktarma gibi kullanımla birlikte büyüyen sınırlar, belirli bir özelliği tamamen kilitlemekten genellikle daha adil algılanır.

Mağaza kuralları: neyi mağaza üzerinden satmak zorundasınız?

İki mağazanın temel kuralı benzer: uygulama içinde satılan dijital içerik ve özellikler mağazanın ödeme sistemiyle satılmalıdır. Apple bunu App Review Guidelines'ın 3.1.1 maddesinde, Google ise Ödemeler politikasında düzenler. Fiziksel ürünler ve uygulama dışında tüketilen hizmetler bu kuralın dışındadır: e-ticaret siparişi, yemek teslimatı, taksi yolculuğu veya kuaför randevusu kendi ödeme altyapınızla alınabilir. Bu durumda banka sanal POS'u veya ödeme kuruluşu seçimi gündeme gelir; farkları sanal POS ve ödeme altyapısı rehberimizde karşılaştırdık.

Dikkat edilmesi gereken diğer kurallar:

• Geri yükleme: Apple, geri yüklenebilir satın almalar için bir "Satın almaları geri yükle" yolu sunmanızı ister. Telefonunu değiştiren kullanıcı premium erişimini kaybetmemelidir.
• Abonelik süresi ve kapsamı: Apple'ın 3.1.2 maddesine göre otomatik yenilenen bir abonelik en az yedi gün sürmeli ve kullanıcının tüm cihazlarında kullanılabilir olmalıdır.
• Şeffaf satın alma ekranı: Fiyat, dönem, deneme süresi ve deneme bitince ne kadar ücret alınacağı açıkça yazmalı. Apple, ücretsiz deneme süresini ve sonrasında uygulanacak fiyatı satın alma akışında net biçimde belirtmenizi öneriyor.
• Çok platformlu hizmetler: Kullanıcı aboneliğini web sitenizden aldıysa, uygulamada bu erişimi tanıyabilirsiniz. Apple'ın 3.1.3(b) maddesi, aynı içeriğin uygulama içinde de satın alınabilir olması koşuluyla buna izin verir.
• Harici ödeme bağlantıları: Bazı ülkelerde yasal düzenlemeler nedeniyle mağazalar harici ödeme seçeneklerine sınırlı izin veriyor. Bu istisnalar ülkeye ve programa göre değiştiği için kendi hedef pazarınızın kurallarını mağazaların güncel politika sayfalarından kontrol edin.

Mağazalar her satıştan komisyon alır ve oranlar ürün türüne, abonelik süresine ve geliştiricinin dahil olduğu programa göre değişir. Örneğin Apple'da otomatik yenilenen aboneliklerde ilk yıldan sonra komisyon düşer ve küçük işletmeler için ayrı bir program bulunur. Güncel oranlar sık değiştiği için burada rakam vermiyoruz; fiyatlandırmanızı resmi sayfalardaki oranlarla ve vergiler düşüldükten sonra elinize geçecek net tutar üzerinden hesaplayın.

Abonelik tasarımında karar verilecek konular

Abonelik, mağazada tek bir ürün tanımlamaktan ibaret değildir. Kullanıcının yaşam döngüsündeki her durum için bir davranış belirlemeniz gerekir:

• Abonelik grupları ve seviyeler: Apple'da her abonelik bir gruba aittir ve kullanıcı bir grupta aynı anda tek aboneliğe sahip olabilir. "Standart" ve "Pro" planlarını aynı grupta sıralarsanız yükseltme ve düşürme yolları mağaza tarafından yönetilir. Çoğu uygulama için tek grup yeterlidir.
• Tanıtım teklifleri ve ücretsiz deneme: Deneme süresi, kullanıcının ürünün değerini görmesine yetecek kadar olmalı. Apple'da kullanıcı her abonelik grubunda yalnızca bir tanıtım teklifinden yararlanabilir; bunu kampanya planlarken hesaba katın.
• Ödeme sorunu ve ek süre: Kartı reddedilen kullanıcının erişimini hemen kesmek, kurtarılabilecek bir aboneliği kaybettirir. İki mağazada da ödeme yeniden denenirken erişimin bir süre devam etmesini sağlayan ek süre (grace period) ayarları var; Google Play'de ayrıca erişimin askıya alındığı hesap bekletme (account hold) durumu bulunur.
• İptal ve iade: Kullanıcı aboneliği mağaza ayarlarından iptal eder ve dönem sonuna kadar erişimi sürer. İadeleri mağaza yönetir; sunucunuzun bu olaylardan haberdar olması gerekir.
• Fiyat değişikliği: Mevcut abonelerin fiyatını artırdığınızda mağazalar kullanıcıları bilgilendirir ve bazı durumlarda onay ister. Yeni fiyatı mevcut abonelere ne zaman ve nasıl yansıtacağınızı önceden planlayın.

Abonelikler tüketici mevzuatı açısından da değerlendirilmelidir: kullanıcıya ön bilgilendirme, kolay iptal yolu ve yenileme koşullarının açık anlatımı önemlidir. Mesafeli satış ve ön bilgilendirme yükümlülüklerini e-ticaret yasal gereklilikler yazımızda genel hatlarıyla ele aldık. Bu bölüm genel bilgilendirme amaçlıdır, hukuki danışmanlık değildir; kendi modeliniz için bir hukukçuya danışmanızı öneririz.

Sunucu tarafı doğrulama: neden şart, nasıl kurulur?

Satın almayı yalnızca uygulamanın içinde kontrol etmek, cihazda değiştirilebilecek bir bilgiye güvenmek demektir. Ayrıca aboneliğin yenilenmesi, iptali, iadesi ve ödeme sorunları uygulama kapalıyken olur; bunları ancak sunucu öğrenebilir. Google da satın alma doğrulaması, abonelik özellikleri ve gerçek zamanlı bildirimler için güvenli bir arka uç kullanmayı öneriyor. Sağlam bir akış şu adımlardan oluşur:

1. Satın alma uygulamada başlar. Uygulama, mağazanın kütüphanesiyle (iOS'ta StoreKit, Android'de Play Billing Library; Flutter'da bu ikisini saran resmi in_app_purchase eklentisi) satın alma ekranını açar.
2. Kanıt sunucuya gönderilir. Başarılı işlemden sonra uygulama, mağazanın verdiği kanıtı sunucunuza iletir: Google Play'de satın alma jetonu (purchase token), App Store'da imzalı işlem bilgisi ve işlem kimliği.
3. Sunucu mağazaya sorar. Sunucunuz, Google Play Developer API ya da App Store Server API üzerinden işlemin gerçek, ödenmiş ve doğru ürüne ait olduğunu doğrular.
4. Yetki kaydı oluşturulur. Doğrulanan satın alma, kullanıcının hangi içeriğe ne zamana kadar erişeceğini gösteren bir yetki (entitlement) kaydına dönüşür.
5. Satın alma onaylanır. Google Play'de satın almanın üç gün içinde onaylanması (acknowledge) gerekir; aksi hâlde otomatik olarak iade edilir ve erişim geri alınır. Tüketilebilir ürünlerde tüketme işlemi bu onayı da içerir.
6. Mağaza bildirimleri dinlenir. App Store Server Notifications ve Google Play'in Pub/Sub üzerinden gelen gerçek zamanlı geliştirici bildirimleri (RTDN), yenileme, iptal, iade ve ödeme sorunlarını sunucunuza iletir. Bildirimi aldığınızda durumu yeniden mağaza API'sinden sorgulayıp yetki kaydını güncellemek en güvenli yoldur.

Yetki tablosu için örnek alanlar: kullanici_id, platform, urun_id, orijinal_islem_id, durum (aktif, ek_sure, iptal_edildi, suresi_doldu, iade), bitis_tarihi, son_dogrulama. Uygulama, premium özelliği açıp açmayacağına cihazdaki bir bayrağa değil, bu kayda bakarak karar verir. Aynı yapı, kullanıcı web'den abone olduğunda da çalışır; böylece tek bir yetki mantığı iki mağazayı ve web'i birlikte yönetir.

Bu altyapıyı sıfırdan kurmak yerine abonelik yönetimi sunan üçüncü taraf servisler de kullanılabilir. Bu servisler doğrulamayı ve bildirimleri sizin yerinize işler; karşılığında bir hizmet bedeli ve dış bağımlılık getirir. Kullanıcı sayısı, ekip kapasitesi ve verinin nerede tutulduğu bu kararın ölçütleridir.

Örnek senaryo: yoga uygulaması

Örnek olarak, ders videoları sunan bir yoga uygulaması düşünelim. Ekip şu kurguyu seçer: ücretsiz katmanda haftalık üç başlangıç dersi, ücretli abonelikte tüm kütüphane, çevrimdışı indirme ve kişisel program. Mağazalarda premium_aylik ve premium_yillik aynı abonelik grubunda tanımlanır; yıllık plana bir haftalık ücretsiz deneme eklenir. Satın alma ekranında iki planın dönemi, deneme bitince alınacak ücret ve iptal yolu açıkça yazılır.

Sunucuda her satın alma doğrulanır, yetki kaydı açılır ve mağaza bildirimleri dinlenir. Kartı reddedilen kullanıcıya ek süre boyunca erişim devam eder, uygulama içinde nazik bir uyarı gösterilir. Ölçüm tarafında deneme başlatma, denemeden ücretliye geçiş ve ilk yenileme olayları ayrı ayrı takip edilir; bu olayları web analitiğiyle birlikte okumak için GA4 kurulum rehberimizdeki olay ve dönüşüm mantığı mobil tarafta da işe yarar. Mağaza sayfasında premium özelliklerin ekran görüntüleri de gösterilir; bu kısmı ASO rehberimizde anlattık.

Yayın öncesi öncelik sırası

1. Modeli seçin ve ücretsiz ile ücretli katmanın sınırını yazılı hâle getirin.
2. Ürün kimliklerini iki mağazada aynı adlandırmayla tanımlayın.
3. Sunucu doğrulamasını ve yetki tablosunu kurun; istemciye güvenmeyin.
4. Mağaza bildirimlerini bağlayın ve yenileme, iptal, iade senaryolarını test ortamında deneyin.
5. Geri yükleme, ek süre ve abonelik yönetimi bağlantısını ekleyin.
6. Satın alma ekranındaki fiyat, dönem ve deneme metinlerini gözden geçirin.
7. Mağaza incelemesi için inceleme notlarına ödeme akışının nerede olduğunu yazın.

Sık Sorulan Sorular

Uygulamamda fiziksel ürün satıyorum, mağaza ödemesi kullanmak zorunda mıyım?

Hayır. Fiziksel ürünler ve uygulama dışında tüketilen hizmetler mağaza ödeme sistemi zorunluluğunun dışındadır. Bu tür satışlarda kendi sanal POS'unuzu veya bir ödeme kuruluşunu kullanırsınız.

Web sitemden satılan aboneliği uygulamada tanıyabilir miyim?

Evet. Kullanıcı hesabıyla giriş yaptığında sunucunuzdaki yetki kaydına bakarak erişim verebilirsiniz. Apple'ın kuralına göre aynı içeriğin uygulama içinde de satın alınabilir olması gerekir.

Satın almayı yalnızca uygulamada kontrol etmek yeterli değil mi?

Değil. Cihazdaki kontrol değiştirilebilir ve yenileme, iptal, iade gibi olaylar uygulama kapalıyken gerçekleşir. Güvenilir ve güncel durum bilgisi için sunucu doğrulaması ve mağaza bildirimleri gerekir.

Abonelikleri test ortamında nasıl deneyebilirim?

Apple sandbox test hesapları, Google Play ise lisans test kullanıcıları sunar. Bu ortamlarda abonelik dönemleri hızlandırılmış çalışır; böylece yenileme ve iptal senaryolarını kısa sürede deneyebilirsiniz.

Aynı kullanıcı iOS'ta aldığı aboneliği Android'de kullanabilir mi?

Mağazalar bunu kendiliğinden sağlamaz; ama kullanıcı hesabı ve sunucu tarafı yetki kaydı varsa, iOS'ta alınan aboneliği Android uygulamasında tanıyabilirsiniz. Bu yüzden ücretli özellik sunan uygulamalarda hesap sistemi önemlidir.

Fiyatları Türk lirası olarak belirleyebilir miyim?

Evet. İki mağaza da ülke bazında fiyat belirlemeye izin verir. Bir temel fiyattan diğer ülkeler için otomatik fiyat önerisi de alabilirsiniz; ancak yerel alım gücünü dikkate alarak fiyatları elle gözden geçirmek iyi bir pratiktir.

Ücretsiz deneme süresi ne kadar olmalı?

Ürünün değerini göstermek için gereken süre kadar. Günlük kullanılan bir uygulamada birkaç gün yeterli olabilir; haftalık kullanım ritmi olan bir üründe daha uzun deneme gerekir. Bunu tahmin etmek yerine denemeden ücretliye geçiş oranını ölçerek ayarlayın.

Gelir altyapınızı birlikte kuralım

Doğru para kazanma modeli ürününüzün kullanım ritmine uyar; doğru altyapı ise mağaza kurallarına uygun, sunucuda doğrulanan ve her durumu öngören bir yetki mantığına dayanır. Flutter ile geliştirdiğimiz uygulamalarda satın alma akışını, sunucu doğrulamasını ve mağaza bildirimlerini birlikte kuruyoruz. Mobil uygulama hizmetimizi inceleyebilir, modelinizi konuşmak için bizimle iletişime geçebilirsiniz.

Kaynaklar

• Apple: In-App Purchase
• Apple: Auto-renewable Subscriptions
• Apple: App Store Server API
• Android Developers: Google Play's billing system
• Play Console Yardım: Ödemeler politikası