Uygulama Ici Satin Alma (In-App Purchase) Nasil Kurgulanir

Bir mobil oyun ya da uygulamada \"satin al\" butonuna basildiginda arka planda sandiginizdan cok daha fazla kural devreye giriyor. Google ve Apple, dijital/sanal urun satisinda kendi odeme sistemlerinin kullanilmasini zorunlu tutuyor; bu da uygulama ici satin alma (in-app purchase, kisaca IAP) kurgusunu standart bir e-ticaret odeme akisindan farkli hale getiriyor.

Once model secimi: tuketilebilir mi, kalici mi

IAP urunleri temelde uc kategoriye ayriliyor. Tuketilebilir urunler (consumable) her satin alindiginda tekrar tekrar satin alinabilir, oyunlardaki jeton/elmas gibi. Tuketilemez urunler (non-consumable) bir kere satin alinir ve kalici olarak kullaniciya baglidir, reklamlarin kaldirilmasi gibi. Abonelik modeli ise ayri bir kategori, dolayisiyla bu yazinin kapsami disinda tutulan farkli bir mekanizmayla calisir. Hangi urununuzun hangi kategoriye girdigini net tanimlamadan gelistirmeye baslamak, magaza onayinda ret almanin en yaygin sebeplerinden biri.

Google ve Apple komisyon politikalari

Her iki magaza da dijital urun satislarindan komisyon aliyor; standart oran %30 olarak baslasa da, kucuk gelistiriciler icin (yillik belirli bir esigin altinda kalan gelirlerde) indirimli oranlar (%15 civari) uygulaniyor. Bu oranlar zaman icinde degisebildigi icin projeye baslarken guncel politikayi magazalarin kendi resmi sayfalarindan teyit etmek gerekiyor. Komisyon oraninin fiyatlandirma stratejisine dogrudan etkisi var; ornegin 100 TL'lik bir sanal urunde gelistiriciye net kalan miktar komisyon sonrasi degisiyor, bu da fiyatlandirmayi buna gore planlamayi gerektiriyor.

Odeme akisinin teknik tarafi

Kullanici satin alma butonuna bastiginda, magazanin kendi odeme arayuzu acilir (kendi gelistirdiginiz bir odeme ekrani degil). Odeme onaylandiktan sonra magazadan gelen \"makbuz\" (receipt/token) sunucu tarafinda dogrulanmali; sadece istemci tarafinda \"basarili\" mesaji gormek yeterli degil, cunku bu adim atlanirsa sahte satin alma bildirimleriyle sistem kandirilabilir. Sunucu tarafi dogrulama, hem dolandiriciligi onluyor hem de kullanicinin urunu farkli cihazlarda da gorebilmesini (restore purchase) saglayan alt yapiyi kuruyor.

Restore purchase unutulmamali

Kullanici telefon degistirdiginde ya da uygulamayi silip tekrar yukledigin de, daha once satin aldigi kalici urunleri (non-consumable) geri yukleyebilmesi gerekiyor. Bu ozellik magaza politikalari geregi zorunlu; eksik birakildiginda uygulama magaza incelemesinde reddedilebiliyor.

Fiyatlandirma testleri

Ayni sanal urunu farkli fiyat noktalarinda test etmek (A/B test) IAP gelirini optimize etmenin en etkili yollarindan biri. Ancak magazalarin fiyat degisikligi onay surecleri oldugu icin bu testler aninda degil, birkac gunluk gecikmeyle sonuc veriyor; bu da test planlamasinin sabirli yapilmasini gerektiriyor.

IAP entegrasyonu platforma gore farkli SDK'lar gerektiriyor; Android Uygulama Gelistirme tarafinda Google Play Billing, iOS Uygulama Gelistirme tarafinda StoreKit kullaniliyor. Iki platformu birlikte gelistiren projelerde Android + iOS Cift Platform Paketi ile bu iki farkli sistemin ayni urun kataloguyla senkronize calismasi planlanmali. Gelistirme maliyeti hakkinda fikir edinmek icin Mobil Uygulama Fiyatlari Rehberi sayfasina bakabilirsiniz.

App Store Google Play Store In-App Purchase Mobil Uygulama Uygulama İçi Satın Alma