In-App Purchase Sistemi Nasıl Kurulur?

Dijital ürünlerin ve mobil servislerin gelir modelini oluştururken uygulama içi satın alma altyapısının doğru kurgulanması, operasyonel sürdürülebilirlik ve finansal güvenlik açısından temel adımdır.

Mobil uygulama ekosisteminde gelir yaratma stratejilerinin merkezinde yer alan In-App Purchase Sistemi Nasıl Kurulur? sorusu; teknik mimariden yasal mevzuatlara, mağaza komisyonlarından ters ibraz (chargeback) risklerine kadar çok boyutlu bir hazırlık gerektirir. Dijital varlıklarını iOS ve Android platformlarında ticarileştirmek isteyen işletmeler; StoreKit ve Google Play Billing API entegrasyonlarını yaparken hem platform politikalarına uyum sağlamak hem de sunucu tabanlı makbuz doğrulama mekanizmalarını kurmak zorundadır. Bu rehber; ürün tanımlama, hesap konfigürasyonu, API mimarisi, test senaryoları ve gelir optimizasyonuna dair tüm teknik ve operasyonel aşamaları ele almaktadır.

In-App Purchase (IAP) Sisteminin Ticari ve Teknik Temelleri

Uygulama İçi Satın Alma (In-App Purchase - IAP), kullanıcıların bir mobil uygulama içerisinden dijital ürün, hizmet, ek özellik veya abonelik satın almasını sağlayan platforma entegre ödeme altyapısıdır. Apple (iOS) ve Google (Android), kendi işletim sistemleri üzerinde çalışan uygulamalarda dijital içerik satışının yalnızca kendi denetimlerindeki ödeme sistemleri üzerinden yapılmasını zorunlu tutar. Bu zorunluluk, platform güvenliğini ve kullanıcı deneyimini standartlaştırmayı amaçlarken, geliştiriciler için belirli teknik standartlara ve komisyon yapılarına uyma gerekliliğini beraberinde getirir.

Fiziki ürün satışları (örneğin e-ticaret uygulamalarında fiziksel bir ayakkabı veya elbise satışı), yemek siparişleri veya araç çağırma gibi gerçek dünyada teslim edilen hizmetler IAP kapsamı dışındadır. Bu tür fiziki mal ve hizmet satışlarında işletmeler Stripe, iyzico, PayTR veya Adyen gibi geleneksel ödeme geçitlerini (Payment Gateway) kredi kartı formlarıyla entegre edebilir. Ancak dijital bir kitap okuma hakkı, oyun içi para birimi, bulut depolama alanı, premium üyelik veya SaaS erişim yetkisi satılıyorsa, platform kuralları gereği doğrudan Apple App Store veya Google Play Store IAP mekanizmaları kullanılmalıdır.

Teknik açıdan IAP sistemi; istemci (mobil cihaz), platform mağazası (App Store / Google Play Store) ve uygulama geliştiricisinin arka uç sunucusu (backend server) arasında çalışan üç katmanlı bir protokoldür. İstemci tarafında başlatılan satın alma isteği, mağaza ödeme arayüzünü tetikler; mağaza ödemeyi tahsil ettikten sonra şifrelenmiş bir makbuz (receipt / token) üretir. Bu makbuzun güvenilirliği backend sunucusu üzerinden ilgili mağazanın doğrulama API'lerine sorularak teyit edilir ve ardından kullanıcı hesabına dijital hak (entitlement) tanımlanır.

IAP Ürün Kategorilerinin Doğru Belirlenmesi

Uygulama içi satın alma altyapısı kurulurken yapılacak ilk mimari tercih, satılacak dijital ürünün kategorisini doğru seçmektir. Apple ve Google platformlarında ürün tipleri temelde dört ana kategoriye ayrılır:

• Tüketilebilir Ürünler (Consumables): Satın alındıktan sonra uygulama içinde kullanılan ve tükenen ürünlerdir. Oyun içi altın, sanal elmas, canlı yayın hediyeleri veya tek seferlik analiz hakları bu gruba girer. Kullanıcı bu ürünü tükettikçe tekrar tekrar satın alabilir. Bu ürünler cihazlar arasında otomatik olarak "Satın Alımları Geri Yükle" (Restore Purchases) mekanizmasıyla geri getirilemez; bakiye yönetimi geliştiricinin kendi veritabanında tutulmalıdır.

• Tüketilmeyen Ürünler (Non-Consumables): Kullanıcının bir kez satın aldığı ve kullanım hakkının kalıcı olduğu ürünlerdir. Reklamları kaldırma özelliği, profesyonel fotoğraf filtresi paketi, kalıcı bir oyun seviyesi kilidinin açılması veya ömür boyu erişim (lifetime access) lisansları bu kategoriye girer. Kullanıcı cihaz değiştirdiğinde veya uygulamayı silip yüklediğinde bu hakları ücretsiz geri yükleyebilmelidir.

• Otomatik Yenilenen Abonelikler (Auto-Renewable Subscriptions): Belirli periyotlarla (haftalık, aylık, yıllık) kullanıcının hesabından otomatik olarak ücret tahsil edilen modeldir. SaaS mobil uygulamaları, dijital dergiler, streaming servisleri (müzik/video) ve fitness uygulamaları bu modeli kullanır. Platformlar, abonelik yükseltme (upgrade), düşürme (downgrade), duraklatma (pause) ve faturalandırma sorunları (billing retry) gibi durumları yönetmek için gelişmiş durum makineleri sunar.

• Yenilenmeyen Abonelikler (Non-Renewing Subscriptions): Belirli bir süre (örneğin 3 aylık sezonluk spor ligi paketi) için geçerli olan ancak süre bitiminde otomatik olarak yenilenmeyen erişim haklarıdır. Kullanıcı süreyi uzatmak isterse manuel olarak yeni bir satın alma işlemi yapmalıdır.

Platformların (Apple ve Google) Temel Kuralları ve İhlal Riskleri

Apple App Store İnceleme Kılavuzu (Madde 3.1.1) ve Google Play Geliştirici Program Politikaları, dijital içeriklerde üçüncü taraf ödeme yönlendirmelerini katı kurallarla sınırlar. Uygulama içine harici bir web sitesine yönlendiren doğrudan ödeme linki koymak, "Web sitemizden %20 daha ucuza satın alın" şeklinde buton veya yönlendirici metinler eklemek uygulamanın mağazadan doğrudan reddedilmesine (rejection) veya geliştirici hesabının askıya alınmasına (account termination) neden olur.

Platform kurallarına göre kullanıcıya sunulan her satın alma seçeneğinin fiyatı, periyodu ve şartları satın alma butonunun hemen yanında açık ve şeffaf şekilde listelenmelidir. Özellikle abonelik modellerinde gizli maliyet algısı yaratmak veya yanıltıcı "ücretsiz deneme" (free trial) sayaçları kullanmak, Apple'ın "Human Interface Guidelines" ve Google'ın "Deceptive Behavior" kuralları çerçevesinde doğrudan engellenir. Kullanıcının satın alma işleminden önce kullanım koşullarını (Terms of Service) ve gizlilik politikasını (Privacy Policy) görebileceği aktif bağlantılar arayüzde yer almalıdır.

---

Kurulum Öncesi Hazırlıklar ve Kurumsal Gereksinimler

Uygulama içi satın alma mekanizmalarını teknik olarak kodlamaya başlamadan önce, Apple ve Google'ın yasal, finansal ve kurumsal şart koştuğu hesap yapılandırmalarının eksiksiz yerine getirilmesi gerekir. Bireysel geliştirici hesapları ile ticari şirket hesapları arasında yetkilendirme, ödeme alma limitleri ve tüzel kişilik doğrulamaları açısından kritik farklar bulunur. Gelir elde etmeyi hedefleyen işletmelerin kurumsal (Organization) hesap türünü tercih etmesi önerilir.

Kurumsal hesap oluşturma adımları, şirket yetkilisinin kimlik kontrolünden şirketin uluslararası ticaret sicil kaydının doğrulanmasına kadar uzanan bir inceleme sürecine tabidir. Bu süreçlerin tamamlanması ortalama 3 ila 10 iş günü sürebilir. Bu nedenle finansal altyapı ve hesap sözleşmeleri, yazılım geliştirme sprintlerinin başında tamamlanmalıdır.

Apple Developer ve Google Play Console Hesap Aktivasyonları

Apple ekosisteminde IAP kullanabilmek için aktif bir Apple Developer Program üyeliği gereklidir. Bu üyeliğin yıllık maliyeti 99 USD'dir (büyük kurumsal iç dağıtımlar için Enterprise programı 299 USD'dir). Hesap açıldıktan sonra App Store Connect paneline erişim sağlanır. App Store Connect üzerinde "Agreements, Tax, and Banking" (Sözleşmeler, Vergi ve Bankacılık) sekmesindeki "Paid Applications Agreement" (Ücretli Uygulamalar Sözleşmesi) elektronik olarak imzalanmadan IAP ürünleri oluşturulamaz ve test edilemez.

Google ekosisteminde ise Google Play Console geliştirici hesabı açılmalıdır. Bu hesap için tek seferlik 25 USD kayıt ücreti ödenir. Ancak Google Play üzerinde ücretli uygulama veya IAP satışı yapabilmek için yalnızca geliştirici hesabı yeterli değildir; Play Console içerisinden bir Google Ödeme Profili (Merchant Account / Satıcı Hesabı) oluşturulması ve banka hesap bilgilerinin tanımlanarak küçük tutarlı mikro ödeme doğrulamasıyla (test depozitosu) onaylanması şarttır.

Finansal Bilgiler, Vergi Formları ve D-U-N-S Numarası

Kurumsal hesap başvurularında Apple, şirketin küresel mevcudiyetini doğrulamak için Dun & Bradstreet tarafından sağlanan 9 haneli D-U-N-S Numarası talep eder. Şirket unvanı, resmi adresi ve imza yetkilisinin bilgileri D-U-N-S veritabanındaki kayıtlarla birebir örtüşmelidir. Bilgilerde yapılacak en ufak bir harf veya adres uyumsuzluğu, Apple Developer hesap onayının haftalarca gecikmesine yol açabilir.

Finansal bilgilerin tanımlanması aşamasında ise uluslararası çifte vergilendirmeyi önleme anlaşmaları çerçevesinde vergi formlarının doldurulması zorunludur:

• W-8BEN / W-8BEN-E Formları: ABD dışındaki bireysel geliştiriciler W-8BEN, tüzel kişilikler (şirketler) ise W-8BEN-E formunu elektronik ortamda doldurmalıdır. Bu form, ABD kaynaklı gelirlerde stopaj oranının (withholding tax) düşürülmesini veya sıfırlanmasını sağlar.

• Banka Hesap Tanımlamaları (IBAN & SWIFT): Gelirlerin geliştiriciye aktarılabilmesi için döviz transferlerini (USD/EUR) kabul edebilen ticari bir banka hesabı tanımlanmalıdır. Banka adı, şube kodu ve SWIFT/BIC kodları sisteme girilir.

• KDV ve Yerel Vergi Beyanları: Avrupa Birliği, İngiltere ve Türkiye gibi ülkelerde Apple ve Google, pazar yeri modeli gereği nihai tüketiciden yerel vergileri (KDV / VAT) doğrudan tahsil edip ilgili devlet kurumlarına öder. Geliştiriciye kalan net tutar üzerinden yerel muhasebe kayıtlarının nasıl tutulacağı mali müşavir eşliğinde planlanmalıdır.

---

App Store Connect Üzerinden iOS IAP Kurulum Adımları

iOS platformunda uygulama içi satın alma mekanizmasının kurulması, App Store Connect konsolundaki ürün konfigürasyonlarının yapılması ve Xcode projesine StoreKit framework entegrasyonunun gerçekleştirilmesiyle sağlanır. Apple, modern iOS sürümleri (iOS 15 ve sonrası) için Swift dilinin modern concurrency (async/await) yapısına tam uyumlu olan StoreKit 2 mimarisini önermektedir. StoreKit 2, geçmişteki StoreKit 1 karmaşasını (StoreKit receipt parse etme zorunlulukları gibi) büyük oranda sadeleştirerek güvenliği artırmıştır.

Geliştiricilerin IAP sürecini başarıyla yönetebilmesi için ürün tanımlamalarından StoreKit transaction listener (işlem dinleyicisi) mekanizmalarına kadar tüm aşamaları titizlikle kodlaması gerekir. Eksik yapılandırılmış bir transaction tamamlama çağrısı (finish()), kullanıcının parasının kesilmesine rağmen ürünün teslim edilememesine veya sürekli yinelenen satın alma pencerelerine neden olur.

App Store Connect Üzerinde Ürün Tanımlama

App Store Connect paneline giriş yaptıktan sonra "My Apps" bölümünden ilgili uygulama seçilir ve "Features" > "In-App Purchases" veya "Subscriptions" sekmesine gidilir:

1. Product ID (Ürün Kimliği) Belirleme: Her ürün için benzersiz bir ters alan adı formatında ID tanımlanır (Örn: is_premium veya subscription_status). Bu ID daha sonra Swift kodunda ürün sorgulaması yaparken kullanılacaktır.

2. Fiyat Kademesi (Price Tier): Apple, sabit para birimi yerine "Price Tier" sistemi kullanır. Örneğin Tier 1 seçildiğinde ürün ABD'de 0.99 USD, Türkiye'de ve Avrupa'da Apple'ın belirlediği güncel yerel kur karşılığı üzerinden otomatik fiyatlandırılır. İstenirse belirli ülkeler için manuel taban fiyat ayarı yapılabilir.

3. Yerelleştirme (Localization): Ürünün App Store üzerinde ve satın alma diyalog kutularında görünecek adı ve açıklaması desteklenen tüm dillerde girilmelidir.

4. İnceleme Ekran Görüntüsü ve Notları: Apple inceleme ekibinin (App Review) ürünü test edebilmesi için ürünün uygulama içinde nasıl göründüğünü gösteren bir ekran görüntüsü ve test giriş bilgileri yüklenmelidir.

StoreKit API Entegrasyonu ve Makbuz Doğrulama (Receipt Validation)

StoreKit 2 entegrasyonunda temel akış şu aşamalardan oluşur:

• Ürünleri Listeleme: Uygulama açıldığında veya ödeme ekranına girildiğinde Product.products(for: [productIDs]) asenkron metodu çağrılarak App Store'dan güncel fiyat ve para birimi bilgileri çekilir.

• Satın Almayı Başlatma: Kullanıcı bir ürünü seçtiğinde product.purchase() fonksiyonu çalıştırılır. Bu işlem kullanıcıya Face ID / Touch ID onay ekranını açar.

• İşlem Doğrulama (Transaction Verification): İşlem tamamlandığında dönen com.sirket.uygulama.premium objesi kontrol edilir. StoreKit 2, Apple tarafından imzalanmış JWS (JSON Web Signature) formatında bir veri döndürür. İmza doğrulaması başarılıysa (com.sirket.uygulama.abonelik) kullanıcıya dijital hak atanır.

• İşlemi Tamamlama (transaction.finish()): Satın alma teslim edildikten sonra işlemin tamamlandığı Apple sunucularına bildirilmelidir. Bu adım atlanırsa Apple, işlemin yarım kaldığını varsayar ve kullanıcı uygulamayı her açtığında işlemi tekrar tetikler.

Sandbox Ortamında Test Süreçleri

IAP sistemleri canlıya alınmadan önce mutlaka Apple Sandbox ortamında test edilmelidir. App Store Connect > Users and Access > Sandbox Testers sekmesinden sahte bir Apple ID oluşturulur. Fiziksel bir test cihazının Ayarlar > App Store > Sandbox Account bölümüne bu hesap girilir.

Sandbox ortamında zaman hızlandırılmış olarak çalışır. Örneğin 1 aylık bir otomatik yenilenen abonelik, sandbox ortamında yaklaşık 5 dakikada bir yenilenir ve en fazla 5-6 yenilemeden sonra otomatik olarak iptal edilir. Bu durum geliştiricilere yenileme (renewal), süresi dolma (expiration) ve ödeme hatası (billing error) senaryolarını saatler içinde test etme imkanı sunar.

---

Google Play Console Üzerinden Android IAP Kurulum Adımları

Android tarafında uygulama içi satın alma altyapısı, Google Play Console üzerindeki yapılandırmalar ve istemci uygulamasında Google Play Billing Library (güncel v6 veya v7 sürümleri) kullanımı ile hayata geçirilir. Google, geliştiricilerin en güncel Billing Library sürümlerine geçişini belirli periyotlarla zorunlu tutar; eski kütüphane sürümlerini kullanan uygulamaların mağaza güncellemesi yapmasına izin verilmez.

Google Play ekosisteminde IAP akışı, Apple'a kıyasla daha esnek abonelik taban planları (Base Plans) ve teklifler (Offers) sunar. Ancak bu esneklik, Play Console konfigürasyonu ve istemci tarafındaki veri modellerinin yönetiminde daha fazla parametrenin kontrol edilmesini gerektirir.

Play Console'da Ürün ve Fiyatlandırma Şablonu Oluşturma

Google Play Console üzerinde sol menüde yer alan "Monetize" (Gelir Elde Etme) > "Products" bölümü kullanılır:

• Uygulama İçi Ürünler (In-App Products): Tüketilebilir ve tüketilmeyen ürünler burada tanımlanır. Benzersiz bir Ürün Kimliği (Product ID), ad, açıklama ve varsayılan fiyat girilir. Google, hedef ülkelerin yerel para birimlerine göre vergiler dahil fiyatları otomatik hesaplar veya geliştiriciye ülke bazlı özel fiyat girme imkanı tanır.

• Abonelikler (Subscriptions): Google'ın modern abonelik yapısında tek bir Abonelik ID'si altında birden fazla Base Plan (Temel Plan) oluşturulabilir (Örn: Aylık plan, Yıllık plan). Her temel planın altında ise "İlk 1 ay %50 indirimli" veya "7 gün ücretsiz deneme" gibi Offers (Teklifler) tanımlanabilir. Bu mimari, tek bir ürün kimliği üzerinden farklı pazarlama kampanyaları yürütmeyi sağlar.

Google Play Billing API Entegrasyonu

Kotlin veya Java ile Android uygulamasına Play Billing entegrasyonu yapılırken BillingClient yaşam döngüsü titizlikle kurgulanmalıdır:

• BillingClient Başlatma: VerificationResult şeklinde istemci oluşturulur ve .verified ile Google Play servisine bağlanılır.

• Ürün Detaylarını Sorgulama: BillingClient.newBuilder() çağrısı ile konsolda tanımlanan ürünlerin güncel fiyat, para birimi ve teklif token'ları (startConnection()) alınır.

• Satın Alma Akışını Başlatma: Kullanıcı ödeme yapmak istediğinde queryProductDetailsAsync() nesnesi oluşturulur ve offerToken ile Google Play alt çekmece (bottom sheet) satın alma ekranı açılır.

• Tüketme ve Onaylama (Acknowledge & Consume): Satın alma başarılı olduğunda BillingFlowParams tetiklenir. Eğer ürün bir tüketilebilir ürünse launchBillingFlow() metodu çağrılarak ürün envanterden düşürülür ve tekrar satın alınabilir hale getirilir. Tüketilmeyen veya abonelik ürünü ise 3 gün içinde acknowledgePurchase çağrısı ile onaylanmalıdır. Onaylanmayan satın almalar Google tarafından otomatik olarak iptal edilir ve kullanıcının parası iade edilir.

Kapalı Test (Closed Track) ve Lisanslı Kullanıcı Tanımlamaları

Google Play Store üzerinde IAP ürünlerinin istemci tarafından sorgulanabilmesi için uygulamanın en az bir kez Google Play Console'a yüklenmiş ve "Internal Testing" (Dahili Test) veya "Closed Testing" (Kapalı Test) kanallarında onaylanmış olması gerekir. Canlıya çıkmamış taslak uygulamalarda IAP API'leri ürün listesini döndürmez.

Geliştiricilerin gerçek kredi kartı kullanmadan ödeme testleri yapabilmesi için Google Play Console > Setup > License Testing (Lisans Testi) bölümüne test kullanıcılarının Gmail adresleri eklenmelidir. Bu kullanıcılara "RESPONDNORMALLY" (başarılı ödeme) veya "ITEMUNAVAILABLE" gibi farklı yanıt simülasyonları atanabilir. Test kullanıcıları satın alma yaptığında gerçek bir tahsilat gerçekleşmez ancak sistem tam teşekküllü bir satın alma makbuzu üretir.

---

Finansal Yönetim: Komisyon Oranları ve Kesintiler

Uygulama içi satın alma sistemleri kurulurken yapılan en büyük hatalardan biri, brüt satış rakamları üzerinden gelir hesabı yapmaktır. Hem Apple hem de Google, sağladıkları pazar yeri, küresel ödeme altyapısı, faturalandırma ve güvenlik hizmetleri karşılığında geliştiricilerin brüt satış gelirleri üzerinden belirli oranlarda komisyon kesintisi uygular. Bu kesintiler, işletmenin net kârlılık marjını ve fiyatlandırma stratejisini doğrudan etkiler.

Platformların standart komisyon oranı geçmişten bu yana %30 olarak uygulanmakla birlikte, son yıllarda devreye giren düzenlemeler ve geliştirici teşvik programları sayesinde küçük ölçekli işletmeler ve uzun vadeli abonelikler için bu oran %15 seviyesine çekilmiştir.

Apple ve Google'ın %15 - %30 Kesinti Politikaları

Standart koşullarda bir kullanıcı 100 TL'lik bir IAP harcaması yaptığında, platform bu tutarın %30'unu (30 TL) komisyon olarak keser ve kalan 70 TL'yi geliştiriciye aktarır. Ancak otomatik yenilenen aboneliklerde her iki platform da geliştirici lehine bir kural uygular: Bir kullanıcı aynı abonelikte kesintisiz olarak 1 tam yılı (12 ayı) doldurursa, o kullanıcıdan 13. aydan itibaren kesilen komisyon oranı otomatik olarak %30'dan %15'e düşer.

Google Play, 2021 yılında yaptığı küresel politika güncellemesiyle abonelik ürünlerinde ilk günden itibaren tüm geliştiriciler için komisyon oranını doğrudan %15 olarak sabitlemiştir. Yani Android ekosisteminde abonelik gelirlerinde 1 yıl bekleme şartı olmaksızın %15 komisyon uygulanır; tekil ürün satışlarında ise kademeli model geçerlidir.

Küçük İşletme Programları (Small Business Programs) ile Avantaj Sağlama

Apple ve Google, yıllık geliri belirli bir eşiğin altında kalan geliştiricileri desteklemek amacıyla özel programlar yürütmektedir:

• Apple App Store Small Business Program: Bir takvim yılı içerisinde tüm uygulamalarından elde ettiği toplam net gelir (komisyon sonrası) 1 milyon ABD dolarının altında olan geliştiriciler bu programa başvurabilir. Onaylanan geliştiricilerin tüm IAP satışlarındaki (tüketilebilir, tüketilmeyen ve abonelikler) komisyon oranı %30'dan %15'e iner. Gelir 1 milyon doları aştığı anda standart %30 oranı devreye girer.

• Google Play %15 Hizmet Ücreti Kademesi: Google Play'de geliştiricilerin her yıl kazandığı ilk 1 milyon ABD doları tutarındaki gelir için komisyon oranı otomatik olarak %15 olarak uygulanır. Apple'ın aksine bu bir başvuru programı değil, her geliştirici hesabına yıllık tanımlanan bir haktır. 1 milyon dolar aşıldığında sadece aşan kısım %30 üzerinden ücretlendirilir.

Vergilendirme ve Yerel Para Birimi Dalgalanmalarına Karşı Alınacak Önlemler

Mağaza gelirlerinde brüt fiyattan önce yerel vergiler düşülür. Örneğin Türkiye'de uygulanan %20 KDV, son kullanıcı fiyatının içerisinden pazar yeri tarafından kesilerek doğrudan vergi dairesine aktarılır. Kalan tutar üzerinden mağaza komisyonu kesilir ve geliştiriciye net ödeme yapılır:

Geliştiricilerin döviz kurlarındaki aşırı dalgalanmalara karşı App Store Connect ve Google Play Console üzerindeki para birimi otomatik eşitleme (Price equalization) ayarlarını düzenli olarak takip etmesi gerekir. Platformlar belirli dönemlerde yerel kur güncellemeleri yayınlayarak taban fiyatları revize eder; bu güncellemeler işletmenin bölgesel kârlılık hedefleri doğrultusunda kontrol edilmelidir.

---

Güvenlik ve Sahtekarlık (Fraud) Önleme Stratejileri

Uygulama içi satın alma sistemlerinin yalnızca mobil cihaz üzerinde (client-side) doğrulanarak kullanıcılara hak tanımlanması, uygulamayı jailbreak/root edilmiş cihazlarda çalışan "LocalIAPStore" veya "Lucky Patcher" gibi sahte makbuz üreten araçlara karşı tamamen savunmasız bırakır. Bu tür araçlar, işletim sisteminin ödeme API'lerini manipüle ederek uygulamanın "satın alma başarılı" yanıtı almasını sağlar ve geliştirici hiçbir ödeme almadan kullanıcıya premium hakları teslim eder.

Finansal kayıpları ve veri tutarsızlıklarını önlemenin tek yolu, Sunucu Tabanlı Doğrulama (Server-Side Receipt Validation) ve mağaza sunucularından gelen anlık bildirimleri (Server-to-Server Notifications) dinleyen bir backend mimarisi kurmaktır.

Sunucu Tabanlı (Server-Side) Doğrulamanın Önemi

Güvenli bir IAP mimarisinde mobil uygulama, mağazadan aldığı satın alma token'ını veya JWS makbuzunu asla kendi içinde işleyip yetkilendirme yapmaz. Bunun yerine token doğrudan geliştiricinin kendi güvenli backend sunucusuna iletilir:

• App Store Server API: Apple, eski onPurchasesUpdated() uç noktasını kullanımdan kaldırmış olup yerine modern REST tabanlı App Store Server API'yi getirmiştir. Geliştirici sunucusu, Apple API'sine JWT (JSON Web Token) ile kimlik doğrulaması yaparak işlem kimliğini (consumeAsync()) sorgular ve işlemin Apple sunucularında gerçekten var olduğunu ve geçerli olduğunu doğrular.

• Google Play Developer API: Android makbuzları için backend sunucusu Google Cloud Console üzerinden oluşturulan bir Hizmet Hesabı (Service Account) aracılığıyla verifyReceipt veya transactionId API uç noktalarını çağırır. Google sunucusu, işlemin PurchaseState değerinin 0 (Purchased / Satın Alındı) olduğunu ve ödemenin provizyondan geçtiğini teyit eder.

Backend sunucusu makbuzu doğruladıktan sonra veritabanında ilgili kullanıcının purchases.products.get veya purchases.subscriptions.get alanını günceller ve mobil uygulamaya başarı yanıtı döner. Böylece mobil istemci manipüle edilse bile veritabanına yetkisiz müdahale engellenmiş olur.

Geri Ödeme (Refund) Suistimallerine Karşı Korunma

Kullanıcılar, Apple veya Google destek ekiplerine başvurarak satın aldıkları ürünler için iade (refund) talep edebilir. Kötü niyetli kullanıcılar oyun içi paraları harcadıktan veya dijital içerikten faydalandıktan sonra iade alarak sistemi suistimal edebilir. Bu durumu tespit etmek ve yönetmek için mağazaların gerçek zamanlı sunucu bildirimleri entegre edilmelidir:

• App Store Server Notifications V2: Apple sunucuları; iade gerçekleştiğinde (REFUND, REVOKE), abonelik yenilendiğinde (DID_RENEW) veya süresi dolduğunda (EXPIRED) geliştiricinin webhook adresine anlık bildirim gönderir. Geliştirici iade bildirimini aldığı anda kullanıcının hesabındaki sanal bakiyeyi eksiye düşürebilir veya premium erişimini sonlandırabilir.

• Google Play Real-Time Developer Notifications (RTDN): Google Cloud Pub/Sub altyapısını kullanan bu mekanizma, abonelik iptalleri, duraklatmaları ve iadeleri milisaniyeler içinde backend sistemine aktarır.

---