Uygulama İçi Satın Alma (In-App Purchase) Nasıl Kurulur?

Mobil uygulamalarda sürdürülebilir bir gelir akışı oluşturmanın en temel yöntemlerinden biri olan uygulama içi satın alma entegrasyonu, hem teknik yazılım mimarisi hem de finansal güvenlik katmanları açısından hassasiyet gerektiren bir süreçtir. In-app purchase kurulum adımları, sadece istemci tarafında basit bir API çağrısı yapmaktan ibaret olmayıp, Apple App Store Connect IAP ayarları, Google Play Console faturalandırma API konfigürasyonları, güvenli sunucu doğrulamaları ve yasal uyumluluk standartlarını bir arada barındırır. Bu kapsamlı rehberde, uygulamanıza abonelik ve dijital ürün yönetimi kazandırarak monetizasyon stratejileri doğrultusunda güvenli bir ödeme altyapısı kurmanın tüm teknik aşamalarını inceliyoruz.

Mobil Uygulamalarda IAP Modelleri ve Teknik Ön Hazırlık

IAP Türleri: Tüketilebilir, Tüketilemez ve Abonelikler

Uygulama içi satın alma kurulum süreçlerine başlamadan önce, uygulamanızın iş modeline en uygun ürün türünü belirlemek kritik bir adımdır. Apple ve Google platformlarında dijital ürünler dört ana grupta sınıflandırılır. Tüketilebilir (consumable) ürünler, kullanıcı tarafından satın alındıktan sonra tüketilen ve tekrar tekrar satın alınabilen ögelerdir. Mobil oyunlardaki sanal paralar, ekstra canlar veya içerik üretim uygulamalarındaki tek kullanımlık kredi paketleri bu sınıfa girer. Teknik mimaride bu ürünlerin bakiye takibi yerel istemcide değil, tamamen güvenli sunucu veritabanlarında tutulmalıdır.

Tüketilemez (non-consumable) ürünler ise kullanıcının bir kez satın alıp uygulamanın ömrü boyunca kalıcı olarak sahip olduğu dijital varlıklardır. Reklamları kaldırma seçeneği, kalıcı premium özellik kilitlerinin açılması veya ek seviye paketleri bu modele örnek gösterilebilir. Bu ürünlerin en önemli teknik zorunluluğu, kullanıcının cihaz değiştirmesi veya uygulamayı yeniden yüklemesi durumunda satın alımın "Geri Yükleme" (Restore Purchases) mekanizmasıyla kullanıcının hesabına tekrar tanımlanması gerekliliğidir.

Abonelikler (subscriptions) ise otomatik yenilenen (auto-renewable) ve yenilenmeyen (non-renewing) olmak üzere ikiye ayrılır. Otomatik yenilenen abonelikler, modern yazılım (SaaS) ürünlerinin temelini oluşturur. Belirli periyotlarla (haftalık, aylık, yıllık) kullanıcıdan otomatik olarak tahsilat yapılır. Bu modelde "ödeme askıya alma" (account hold), "ücretsiz deneme" (free trial), "indirimli başlangıç fiyatı" (introductory price) ve "cayma süresi" (grace period) gibi karmaşık finansal durumların yönetilmesi teknik olarak zorunludur. Yenilenmeyen abonelikler ise genellikle belirli bir süreyle (örneğin 3 aylık bir sezon biletinde) sınırlı olan ve süresi bittiğinde kullanıcının manuel olarak tekrar satın alması gereken paketlerdir.

Mağaza Hesabı Yetkileri ve API Yapılandırması

Entegrasyon çalışmalarına başlamadan önce idari ve yasal süreçlerin tamamlanması gerekir. Apple Developer Program kurumsal üyeliği (yıllık 99 USD) veya Google Play Console geliştirici hesabı (tek seferlik 25 USD) aktif edilmelidir. İlgili platformlarda ödeme alabilmek için banka hesabı (IBAN), vergi kimlik numaraları ve uluslararası W-8BEN / W-8BEN-E gibi vergi beyanname formlarının eksiksiz doldurulması şarttır. Bu adımlar tamamlanmadığı takdirde, sandbox test ortamları dahi tam işlevsel çalışmayacaktır.

Teknik ekiplerin mağaza panellerine erişimi için rol tabanlı yetkilendirme yapılmalıdır. Apple tarafında App Store Connect üzerinde "Geliştirici" (Developer), "Finans" (Finance) veya "Yönetici" (Admin) yetkileri tanımlanmalıdır. Google Play Console tarafında ise finansal verileri yönetme ve finansal raporları görme yetkilerinin verilmesi gerekir. Sunucu taraflı iletişim için Apple App Store Connect API üzerinden bir .p8 özel anahtarı (private key) üretilmeli; Google tarafında ise Google Cloud Console üzerinden bir Hizmet Hesabı (Service Account) oluşturularak gerekli JSON anahtar dosyası güvenli bir şekilde sunucuya entegre edilmelidir.

Dijital Ürünlerin Tanımlanması

Mağaza panellerinde oluşturulacak her ürünün benzersiz bir kimliği (SKU - Stock Keeping Unit) olmalıdır. Sektörel olarak kabul görmüş en güvenilir yöntem, ters alan adı (reverse domain) yapısını kullanmaktır. Örneğin: @@CODE0@@ veya @@CODE1@@. Bu isimlendirme standardı, gelecekte uygulamanıza yeni ürünler eklediğinizde veya platformlar arası veri senkronizasyonu sağladığınızda karmaşayı önler.

Ürün tanımlanırken yerelleştirme (localization) süreçlerine de dikkat edilmelidir. Hedef pazarınız TR, US, UK veya AE ise, ürün başlıkları ve açıklamaları her dile uygun olarak çevrilmelidir. Fiyatlandırma matrisinde ise her ülkenin para birimi ve yerel vergilendirme politikaları (örneğin Türkiye'de %20 KDV, Birleşik Arap Emirlikleri'nde %5 VAT, İngiltere'de %20 VAT) dikkate alınarak fiyatlandırma grupları belirlenmelidir. Apple ve Google, döviz kurlarındaki dalgalanmalara göre fiyat listelerini otomatik güncelleyebilse de bölgesel stratejiler doğrultusunda manuel fiyat sabitlemesi yapmak da mümkündür.

Apple App Store (iOS) İçin Adım Adım IAP Kurulumu

App Store Connect Üzerinden Ürün Yapılandırma

Apple ekosisteminde uygulama içi satın alma kurulum adımları App Store Connect paneli üzerinden yönetilir. Uygulamanızın "Uygulama İçi Satın Alımlar" veya "Abonelikler" bölümüne giderek yeni bir öge eklemeniz gerekir. Abonelik oluştururken, kullanıcıların aynı anda yalnızca bir pakete abone olabilmesini sağlamak amacıyla bir "Abonelik Grubu" (Subscription Group) oluşturulması zorunludur. Bu grup yapısı, kullanıcının aylık plandan yıllık plana geçiş (upgrade) yaparken veya tam tersi durumda (downgrade) sistemin geçişleri otomatik yönetmesine imkan tanır.

Ürünlerin mağazaya gönderilip onaylanabilmesi için her bir ürün için en az bir ekran görüntüsü (screenshot) ve açıklama metni yüklenmesi zorunludur. Bu ekran görüntüsü, uygulamanın içindeki satın alma ekranının (paywall) çalışır halini göstermelidir. Aksi takdirde Apple inceleme ekibi (App Review), uygulamanızı "Eksik Meta Veri" (Missing Metadata) gerekçesiyle reddedecektir. İnceleme notları kısmına test sürecinde kullanılabilecek aktif bir test kullanıcısı hesabı eklemek süreci hızlandırır.

StoreKit 2 SDK Entegrasyonu ve Kod Yapısı

Apple, modern iOS uygulamalarında satın alma işlemlerini yönetmek için Swift dilinin modern asenkron (async/await) yapısını kullanan StoreKit 2 SDK entegrasyonunu standart haline getirmiştir. Eski StoreKit API'lerine kıyasla StoreKit 2, işlem doğrulamasını şifrelenmiş JWS (JSON Web Signature) formatında sunarak istemci tarafında veri manipülasyonu riskini minimize eder.

Aşağıdaki Swift kod bloğu, StoreKit 2 kullanarak ürünleri listeleme ve satın alma işlemini tetikleme adımlarını göstermektedir:

import StoreKit

@MainActor
class StoreKitManager: ObservableObject {
    @Published private(set) var products: [Product] = []
    @Published private(set) var purchasedProductIDs = Set<String>()
    
    private var transactionListener: Task<Void, Error>?

    init() {
        // Satın alma işlemlerini arka planda dinleyen listener'ı başlatıyoruz
        transactionListener = listenForTransactions()
    }

    deinit {
        transactionListener?.cancel()
    }

    // App Store Connect üzerindeki ürünleri çekme
    func fetchProducts(identifiers: [String]) async {
        do {
            let storeProducts = try await Product.products(for: identifiers)
            self.products = storeProducts.sorted(by: { $0.price < $1.price })
        } catch {
            // Hata yönetimi mekanizması buraya eklenmelidir
        }
    }

    // Satın alma işlemini tetikleme
    func purchase(product: Product) async throws -> Transaction? {
        let result = try await product.purchase()
        
        switch result {
        case .success(let verificationResult):
            // JWS imzasını doğruluyoruz
            let transaction = try checkVerified(verificationResult)
            
            // Kullanıcıya haklarını tanımlıyoruz
            await updatePurchasedState(productID: transaction.productID)
            
            // İşlemi sonlandırarak Apple sunucularına onay gönderiyoruz
            await transaction.finish()
            return transaction
            
        case .userCancelled:
            return nil
            
        case .pending:
            // Ebeveyn onayı veya bekleyen ödemeler durumu
            return nil
            
        @unknown default:
            return nil
        }
    }

    // JWS Doğrulama Yardımcı Fonksiyonu
    func checkVerified<T>(_ result: VerificationResult<T>) throws -> T {
        switch result {
        case .unverified(_, let error):
            throw error
        case .verified(let verifiedSafe):
            return verifiedSafe
        }
    }

    private func updatePurchasedState(productID: String) async {
        purchasedProductIDs.insert(productID)
    }

    // Arka planda harici işlemleri (örneğin yenilemeleri veya App Store dışı güncellemeleri) dinleme
    private func listenForTransactions() -> Task<Void, Error> {
        Task.detached {
            for await result in Transaction.updates {
                do {
                    let transaction = try self.checkVerified(result)
                    await self.updatePurchasedState(productID: transaction.productID)
                    await transaction.finish()
                } catch {
                    // Loglama süreçleri
                }
            }
        }
    }
}

Bu kod yapısında yer alan transaction.finish() metodu kritik öneme sahiptir. Eğer işlem başarılı olduktan sonra bu metot çağrılmazsa, Apple satın alma işleminin tamamlanmadığını varsayar ve belirli bir süre sonra işlemi iptal ederek kullanıcıya para iadesi yapar.

iOS Sandbox Ortamında Test Süreçleri

StoreKit 2 entegrasyonunun test edilebilmesi için App Store Connect paneli üzerinde "Kullanıcılar ve Erişim" altındaki "Sandbox" sekmesinden özel test hesapları (Sandbox Testers) oluşturulmalıdır. Bu hesaplar için gerçekte var olmayan e-posta adresleri kullanılabilir. Test cihazınızda kişisel Apple ID oturumunuzu kapatmadan, "Ayarlar > App Store > Sandbox Hesabı" bölümünden bu oluşturduğunuz test hesabı ile giriş yapabilirsiniz.

Sandbox test ortamı yapılandırması kapsamında abonelik süreleri hızlandırılmış olarak simüle edilir. Gerçek hayattaki 1 aylık abonelik süresi sandbox ortamında 5 dakikaya, 1 yıllık abonelik ise 1 saate sıkıştırılır. Böylece aboneliğin otomatik yenilenme (renewal), iptal edilme veya ödeme alamama gibi senaryoları çok kısa sürede gözlemlenebilir. Xcode 13 ile birlikte gelen lokal StoreKit test ortamı (StoreKit Configuration) sayesinde ise internet bağlantısı veya mağaza paneline ihtiyaç duymadan, doğrudan Mac bilgisayarınız üzerinde lokal simülasyonlar gerçekleştirebilirsiniz.

Google Play Store (Android) ve Billing Library Entegrasyonu

Google Play Console ve Google Cloud API Bağlantısı

Android ekosisteminde süreç, Google Play Console ile Google Cloud Console platformlarının birbirine bağlanmasıyla başlar. Google Play Developer API'sine erişim sağlamak için öncelikle bir Google Cloud projesi oluşturulmalı ve bu proje Google Play Console paneline bağlanmalıdır. Cloud Console üzerinde bir Hizmet Hesabı (Service Account) açılıp buna "Finansal Verileri Yönetme" ve "Uygulamaları Yönetme" yetkileri atandıktan sonra bir özel JSON anahtarı bilgisayara indirilmelidir. Bu JSON dosyası, uygulamanızın kendi sunucusunun Google Play API'leri ile kimlik doğrulaması yapabilmesini sağlar.

Gerçek zamanlı abonelik durum değişikliklerini (iptaller, yenilemeler, duraklatmalar) anlık yakalamak için Google Cloud Pub/Sub (Publish/Subscribe) servisi yapılandırılmalıdır. Google Play Console üzerindeki "Gerçek Zamanlı Geliştirici Bildirimleri" (RTDN - Real-Time Developer Notifications) bölümüne, Cloud Pub/Sub üzerinde oluşturduğunuz "Topic" (Konu) adresi girilmelidir. Böylece Google, bir kullanıcının abonelik durumunda değişiklik olduğunda anında sizin sunucunuza güvenli bir webhook bildirimi gönderir.

Google Play Billing Library Kurulum Adımları

Google, Android uygulamalarında satın alma işlemlerini gerçekleştirmek için Google Play Billing Library kütüphanesini zorunlu kılar. Entegrasyon için öncelikle uygulamanızın build.gradle (Module: app) dosyasına ilgili bağımlılık eklenmelidir:

dependencies {
    def billing_version = "7.0.0" // 2026 yılı itibarıyla güncel ana sürüm
    implementation "com.android.billingclient:billing:$billing_version"
    implementation "com.android.billingclient:billing-ktx:$billing_version" // Kotlin coroutines desteği için
}

Billing Library entegrasyonunun kalbi BillingClient sınıfıdır. Bu sınıf, uygulamanın yaşam döngüsüyle uyumlu bir şekilde başlatılmalı ve Google Play servislerine olan bağlantıyı yönetmelidir:

import android.content.Context
import com.android.billingclient.api.*
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext

class BillingManager(context: Context) {

    private val purchasesUpdatedListener = PurchasesUpdatedListener { billingResult, purchases ->
        if (billingResult.responseCode == BillingClient.BillingResponseCode.OK && purchases != null) {
            for (purchase in purchases) {
                // Satın alma işlemini doğrula ve kullanıcı hakkını tanımla
                handlePurchase(purchase)
            }
        } else if (billingResult.responseCode == BillingClient.BillingResponseCode.USER_CANCELED) {
            // Kullanıcı satın alma ekranını kapattı
        }
    }

    private var billingClient = BillingClient.newBuilder(context)
        .setListener(purchasesUpdatedListener)
        .enablePendingPurchases() // Bekleyen ödemeleri zorunlu olarak desteklemek gerekir
        .build()

    fun startConnection(onSuccess: () -> Unit) {
        billingClient.startConnection(object : BillingClientStateListener {
            override fun onBillingSetupFinished(billingResult: BillingResult) {
                if (billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
                    onSuccess()
                }
            }

            override fun onBillingServiceDisconnected() {
                // Bağlantı koptuğunda yeniden bağlanma stratejisi (Exponential Backoff) uygulanmalıdır
            }
        })
    }

    // Google Play üzerindeki ürün detaylarını çekme
    suspend fun queryProductDetails(productIds: List<String>) {
        val productList = productIds.map { id ->
            QueryProductDetailsParams.Product.newBuilder()
                .setProductId(id)
                .setProductType(BillingClient.ProductType.SUBS) // Veya INAPP
                .build()
        }

        val params = QueryProductDetailsParams.newBuilder()
            .setProductList(productList)
            .build()

        val productDetailsResult = withContext(Dispatchers.IO) {
            billingClient.queryProductDetails(params)
        }

        if (productDetailsResult.billingResult.responseCode == BillingClient.BillingResponseCode.OK) {
            val detailsList = productDetailsResult.productDetailsList
            // UI tarafına ürün detaylarını gönder
        }
    }
}

Google Play faturalandırma standartlarına göre, başarılı satın alımlardan sonra @@CODE0@@ (abonelikler için) veya @@CODE1@@ (tüketilebilir ürünler için) metodunun çağrılması zorunludur. Eğer 3 gün içinde satın alma işlemi doğrulanıp (acknowledged) onaylanmazsa, Google Play işlemi iptal eder ve ücreti kullanıcının kartına iade eder.

Android Test Hesapları ile Satış Simülasyonu

Google Play Console panelinde "Kurulum > Lisans Testi" sekmesine giderek test işlemlerinde kullanılacak Gmail adresleri tanımlanmalıdır. Bu hesapların avantajı, test kartlarıyla (gerçek ödeme çekmeden) anında satın alma simülasyonu gerçekleştirebilmeleridir. Lisans test kullanıcıları, "Her Zaman Onayla" veya "Her Zaman Reddet" gibi sanal ödeme yöntemlerini seçerek uygulamanızın hata yönetim senaryolarını test edebilir.

Testlerin yapılabilmesi için uygulamanın imzalı bir paketinin (AAB - Android App Bundle) Google Play Console üzerinde "Dahili Test Grubu" (Internal Testing) veya "Kapalı Test Grubu" (Closed Testing) kanallarından birine yüklenmiş olması gerekir. Lokal emülatörler yerine fiziksel bir Android cihaz üzerinde ve Google Play Store uygulamasında test kullanıcısının aktif oturumu açıkken test süreçlerinin yürütülmesi en sağlıklı sonucu verecektir.

Sunucu Tarafı Makbuz Doğrulama (Receipt Verification) ve Güvenlik

Server-to-Server (S2S) Validation Neden Şarttır?

Mobil uygulamalarda güvenlik açığı oluşturabilecek en zayıf halka her zaman istemci (client-side) tarafıdır. Yalnızca mobil uygulama koduna güvenerek kullanıcıya premium yetki tanımlamak, uygulamanızı hileli yazılımlara (örneğin jailbreak'li cihazlardaki yerel makbuz taklit araçlarına) karşı tamamen savunmasız bırakır. Bu araçlar, App Store veya Google Play API yanıtlarını manipüle ederek satın alma işlemini "başarılı" gibi gösterebilir.

Bu riskin önüne geçmek için Server-to-Server (S2S) doğrulama mimarisi kurulmalıdır. İstemci, satın alma işlemini tamamladıktan sonra mağazadan aldığı şifrelenmiş ham makbuz verisini (receipt token/payload) doğrudan kendi sunucunuza gönderir. Sunucunuz ise bu veriyi arkada HTTPS protokolü üzerinden doğrudan Apple App Store Server API veya Google Play Developer API uç noktalarına (endpoint) göndererek doğrulatır. Bu doğrulama işlemi tamamen sunucular arasında gerçekleştiği için istemci müdahalesine kapalıdır.

Aşağıdaki şemada, uçtan uca güvenli bir S2S doğrulama akışı ve veritabanı kayıt modeli gösterilmiştir:

Kendi sunucunuzda tutacağınız veritabanı şemasında her satın alma işlemini benzersiz bir @@CODE0@@ (Apple) veya @@CODE1@@ (Google) ile tekil (unique) olarak kaydetmeniz gerekir. Bu sayede aynı makbuzun mükerrer olarak farklı kullanıcı hesaplarına tanımlanması (replay attack) engellenir.

Finansal Güvenlik ve Dolandırıcılık (Fraud) Önlemleri

Ödeme sistemlerinin entegrasyonunda karşılaşılan en büyük problemlerden biri de kötü niyetli iade süreçleridir (refund fraud). Kullanıcılar, dijital bir ürünü satın aldıktan hemen sonra uygulama içindeki avantajı tüketip ardından Apple veya Google üzerinden para iadesi talep edebilirler. Eğer sisteminiz bu iadelerden haberdar olmazsa, kullanıcı haksız yere premium özellikleri kullanmaya devam eder.

Bu durumun önüne geçmek için App Store Server Notifications V2 ve Google Play Real-Time Developer Notifications (RTDN) altyapılarını kurmak şarttır. Mağaza sistemleri, bir iade gerçekleştiğinde (veya abonelik iptal edildiğinde) sunucunuzda tanımladığınız webhook URL'ine anlık bir payload gönderir. Sunucunuz bu bildirimi aldığında, ilgili işleme ait original_transaction_id değerini veritabanında sorgular ve kullanıcının premium yetkilerini otomatik olarak askıya alır veya sonlandırır.

Veri gizliliği standartları açısından (KVKK ve GDPR uyumluluğu kapsamında), sunucunuzda kullanıcıların kredi kartı veya ödeme yöntemi bilgilerini asla barındırmamalısınız. Tüm finansal işlemler mağaza altyapısında gerçekleştiği için uygulamanız PCI-DSS standartlarından muaf kalır. Sunucunuzda sadece mağazaların size döndüğü şifreli işlem kimliklerini ve işlem geçmişi loglarını tutmanız hem yasal hem de güvenlik açısından en doğru yaklaşımdır.

IAP Sürecinde Sık Karşılaşılan Hatalar ve Çözüm Yolları

Yaygın API Yanıt Hataları ve Zaman Aşımı Problemleri

Teknik entegrasyon süreçlerinde en sık karşılaşılan hatalardan biri, mağaza sunucularıyla iletişim kurarken yaşanan zaman aşımı veya geçici kesinti durumlarıdır. Özellikle iOS tarafında @@CODE0@@ veya Android tarafında @@CODE1@@ gibi genel hata kodları alındığında, uygulamanın çökmesini (crash) önleyecek bir hata yakalama (error handling) mimarisi bulunmalıdır. Ağ tabanlı kesintilerde, kullanıcıya anlaşılır bir hata mesajı gösterilmeli ve işlem arka planda "Üstel Geri Çekilme" (Exponential Backoff) algoritmasıyla belirli aralıklarla yeniden denenmelidir.

Bir diğer yaygın teknik hata ise ITEM_ALREADY_OWNED (ürün zaten satın alınmış) durumudur. Bu durum genellikle kullanıcı bir aboneliği satın aldıktan sonra, istemci veritabanı veya yerel saklama alanı (cache) güncellenmediğinde meydana gelir. Çözüm olarak, uygulama her açıldığında ve ödeme tetiklendiğinde mağazadan güncel "aktif satın alımlar" listesi çekilmeli ve yerel durum (state) sunucu verileriyle senkronize edilmelidir.

Uygulama Reddedilme Nedenleri ve Alınacak Tedbirler

Apple ve Google, mağaza politikalarına uyumluluk konusunda son derece katıdır. Apple App Store İnceleme Kılavuzunun ünlü Guideline 3.1.1 (In-App Purchase) maddesi, dijital içerik, özellik veya abonelik satan her uygulamanın istisnasız olarak Apple'ın kendi satın alma altyapısını kullanmasını zorunlu kılar. Stripe, PayPal gibi üçüncü taraf ödeme yöntemlerini dijital ürünler için uygulamanın içine entegre etmek uygulamanızın mağazadan kalıcı olarak menedilmesine yol açabilir. Sadece fiziksel ürün veya hizmet satan (e-ticaret, araç kiralama vb.) uygulamalarda harici ödeme ağ geçitleri kullanılabilir.

Bir diğer yaygın ret sebebi ise satın alma ekranında (paywall) kullanıcıya yeterli şeffaflığın sunulmamasıdır. Apple, abonelik ekranlarında aşağıdaki bilgilerin açıkça yer almasını talep eder:

• Abonelik süresi (örneğin haftalık, aylık veya yıllık).

• Dönem başına düşen net ücret ve para birimi.

• Varsa ücretsiz deneme süresi ve deneme sonrasında tahsil edilecek tutar.

• Kullanım Koşulları (EULA) ve Gizlilik Politikası (Privacy Policy) sözleşmelerine doğrudan yönlendiren aktif linkler.

• Satın alımları geri yükleme (Restore Purchases) butonunun ekranın görünür bir yerinde bulunması.

Bu unsurlardan herhangi birinin eksik olması durumunda uygulamanız inceleme aşamasında reddedilecektir. Bu nedenle, kullanıcı arayüzü tasarlanırken bu yasal metinlerin ve butonların yerleşimi titizlikle planlanmalıdır.

Alternatif Entegrasyon Yöntemleri ve Üçüncü Parti SDK Karşılaştırması

RevenueCat, Adapty ve Superwall Değerlendirmesi

Uygulama içi satın alma sistemlerini sıfırdan yerel kodlarla inşa etmek, özellikle çoklu platform (cross-platform - React Native, Flutter) kullanan takımlar için yüksek bakım ve geliştirme maliyeti yaratabilir. Bu noktada devreye giren RevenueCat, Adapty veya Superwall gibi üçüncü parti abonelik yönetim platformları, süreci büyük oranda kolaylaştırır. Bu platformlar, hem StoreKit hem de Google Play Billing kütüphanelerini tek bir ortak SDK altında sararak (wrapper) tek bir kod tabanından iki platformu da yönetmenizi sağlar.

Ayrıca bu servisler, kendi güvenli sunucuları üzerinden S2S makbuz doğrulamalarını kutudan çıktığı gibi (out-of-the-box) sunar. Gerçek zamanlı analiz panelleri sayesinde MRR (Aylık Tekrarlayan Gelir), LTV (Yaşam Boyu Değer), Churn Rate (Abonelik İptal Oranı) ve Cohort analizlerini ek kod yazmadan takip edebilirsiniz. Superwall gibi araçlar ise uygulama içindeki satın alma ekranlarını (paywall) uygulama güncellemesi yapmaya gerek kalmadan, uzaktan (remote config) dinamik olarak değiştirmenize ve A/B testleri uygulamanıza imkan tanır.

Yerel Entegrasyon ve Üçüncü Parti SDK Karşılaştırma Matrisi

Hangi yöntemin seçileceği, işletmenin bütçesi, teknik ekibin büyüklüğü ve veri egemenliği politikalarına göre değişir. Aşağıdaki karşılaştırma tablosu, her iki yaklaşımın avantaj ve dezavantajlarını detaylı bir şekilde ortaya koymaktadır:

Eğer küçük veya orta ölçekli bir ekibe sahipseniz ve uygulamanızı pazara en hızlı şekilde (Go-To-Market) sunmak istiyorsanız, üçüncü parti hazır SDK'ları kullanmak zaman ve iş gücü açısından oldukça avantajlıdır. Ancak finansal verilerin kesinlikle dışarı çıkmaması gereken büyük ölçekli bir kurumsal yapı veya fintech uygulaması geliştiriyorsanız ya da aylık işlem hacminiz çok yüksekse ve üçüncü partilere ek komisyon ödemek istemiyorsanız, kendi yerel sunucu entegrasyonunuzu kurmanız uzun vadede daha rasyonel bir karar olacaktır.