Uygulama İçi Satın Alma mı Web Ödemesi mi? Komisyon Nasıl İşler?

Dijital içerik veya abonelik satan bir mobil uygulamanız varsa, ödeme akışını kurarken karşınıza iki seçenek çıkar. Birincisi uygulama içi satın alma ile ödeme almak, ikincisi kullanıcıyı web üzerinden ödemeye yönlendirmektir. Bu seçim sadece teknik bir ayrıntı değildir, komisyon maliyetinizi ve kullanıcı deneyiminizi doğrudan etkiler. Talha Aslan ve ekibi olarak bu karar noktasıyla mobil uygulama projelerinde sık karşılaşırız. Apple ve Google'ın resmi kurallarına dayanarak konuyu işletme sahibi bakış açısıyla açıklıyoruz. Yazının sonunda kısa bir karar rehberiyle kendi uygulamanız için doğru yolu belirlemenize yardımcı oluyoruz.

Oyun içi para birimi, premium içerik kilidi, dijital hediye kartı ve çoğu abonelik modeli bu kategoriye girer. Kullanıcı tek dokunuşla öder, kayıtlı kart bilgisini tekrar girmesi gerekmez. Örneğin bir oyun uygulamasında ekstra can satın alan kullanıcı, parmak izi veya yüz tanımayla saniyeler içinde ödemesini tamamlar. Bu akıcılık dönüşüm oranını artırır, ancak komisyon maliyetini de doğrudan fiyatlandırmanıza yansıtmanız gerekir.

Bu yöntemi seçtiğinizde kullanıcı güveni de artar, çünkü kart bilgisi hiçbir zaman sizin sunucunuza ulaşmaz, tamamen platformun güvenli altyapısında kalır. Buna karşılık siz, tahsilat üzerindeki doğrudan kontrolü platforma bırakmış olursunuz. Bu yüzden nakit akışı planlamanızı platformun ödeme takvimine göre ayarlamanız gerekir.

Ödemeler genellikle aylık bir takvimle size aktarılır. Bu takvim platformdan platforma değişir. Nakit akışı planı yaparken bu gecikmeyi hesaba katmanız gerekir. Küçük bir ekip yönetiyorsanız bu detay bütçenizi doğrudan etkiler. Fatura ve raporlama takvimini de bu döngüye göre kurmanız, ay sonu kapanışlarınızı kolaylaştırır. Muhasebe ekibiniz bu takvimi önceden bilmelidir.

Web Üzerinden Ödeme Nasıl Çalışır?

Web üzerinden ödemede kullanıcıyı tarayıcıya yönlendirirsiniz, kullanıcı kendi ödeme altyapınız üzerinden (örneğin bir sanal pos sağlayıcısı ile) kart bilgisini girer. Bu akışta Apple ve Google'ın komisyonu devreye girmez, ödemeyi doğrudan siz tahsil edersiniz. Buna karşılık kullanıcıyı uygulamadan çıkarırsınız, bu adım bazı kullanıcıları ödemeyi tamamlamadan vazgeçirebilir.

Fiziksel ürün satan bir e-ticaret uygulaması veya rezervasyon alan bir hizmet uygulaması genellikle bu yolu seçer. Dijital içerik satan bir uygulama için web ödemesi her zaman serbest değildir; bir sonraki başlıkta Apple ve Google'ın bu ayrımı nasıl çizdiğini netleştiriyoruz. Kullanıcı deneyimi açısından bu geçiş bir sürtünme noktası oluşturur, bu yüzden ödeme sayfanızı hızlı ve güven verici tasarlamanız dönüşümünüzü korur.

Ayrıca kendi ödeme sağlayıcınızı seçerken işlem ücretini, para iadesi sürecini ve dolandırıcılık koruma özelliklerini karşılaştırmanız gerekir; bu seçim komisyon avantajının gerçek net kazanca dönüşüp dönüşmeyeceğini belirler. Sağlayıcınızı seçerken üçüncü taraf koruma araçlarının güncel ve güvenilir olmasına da dikkat etmeniz gerekir.

Ödeme sayfanızı kendi markanızla tasarlayabilirsiniz. Bu durum güven hissini artırabilir. Ancak her adımda SSL sertifikası ve güvenli ödeme rozetleri göstermeniz gerekir. Kullanıcı, tanımadığı bir sayfada kart bilgisini paylaşmaktan çekinebilir. Sayfanızda müşteri hizmetleri iletişim bilgisini görünür tutmanız da güveni artırır.

Apple ve Google Uygulama İçi Satın Almayı Neden Zorunlu Kılar?

Apple'ın resmi App Store İnceleme Kuralları (şu an 3.1.1 numaralı madde), uygulama içinde bir özelliği veya içeriği açan satın almalarda uygulama içi satın alma kullanmanızı ister. Oyun seviyesi, premium özellik, dijital hediye kartı ve benzer örnekler bu kapsama girer. Apple bu zorunluluğun gerekçesini platformun sunduğu güvenli ödeme altyapısı, iade yönetimi ve tek hesap üzerinden abonelik kontrolüyle açıklar.

Google Play da benzer bir mantıkla çalışır: dijital ürün ve hizmet satan uygulamalar Google Play Faturalandırma sistemini kullanır, bu kullanım bir hizmet ücretine tabidir. Madde numaraları ve politika metinleri zaman içinde değişebilir, bu yüzden güncel kuralı her zaman resmi geliştirici sayfasından kontrol etmenizi öneririz.

İki platform da bu zorunluluğu kullanıcı güvenliği ve ödeme bütünlüğü gerekçesiyle savunur, ancak uygulama kategorisine göre istisnalar da tanımlar. Dolayısıyla kuralı okurken sadece genel ilkeye değil, kendi uygulama kategorinize özel maddelere de bakmanız gerekir. Aksi halde yanlış bir varsayımla ödeme akışınızı kurma riskiyle karşılaşırsınız.

Kural metinleri uzun ve teknik görünebilir. Yine de her geliştiricinin bu metni en az bir kez baştan sona okuması gerekir. Ekibinizde bu görevi sahiplenecek bir kişi belirleyin. Bu kişi, politika güncellemelerini de düzenli olarak takip etsin.

Hangi Uygulamalar Uygulama İçi Satın Alma Kullanmak Zorunda?

Kural, esasen uygulamanın kendi içinde tüketilen dijital içerik ve özellikler için geçerlidir. İşletme sahibi olarak kendi uygulamanızı bu listeyle karşılaştırmanız karar sürecini hızlandırır.

• Oyun içi para birimi, ekstra seviye veya karakter satın alma.
• Premium özellik kilidi açan uygulama içi yükseltmeler.
• Çoğu abonelik tabanlı dijital hizmet (içerik, araç, kişiselleştirme).
• Dijital hediye kartı, kupon ve sertifika satışı.

Bu listedeki kullanım alanlarının dışında kalan, uygulama dışında tüketilen ürün ve hizmetler ayrı bir kategoriye girer; bu farkı bir sonraki başlıkta ele alıyoruz. Kendi uygulamanızın hangi tarafta durduğunu netleştirmek, ödeme mimarinizi doğru kurmanın ilk adımıdır. Belirsiz kaldığınız kategoriler için resmi kurallardaki örnekleri kendi özelliklerinizle tek tek karşılaştırmanız en güvenli yoldur.

Bu listeyi ürün ekibinizle birlikte gözden geçirin. Her özelliği tek tek işaretleyin. Hangi özelliğin zorunlu kapsamda olduğunu net yazın. Bu kısa çalışma, geliştirme başlamadan önce büyük bir karışıklığı önler.

Fiziksel Ürün ve Hizmetler Bu Kuraldan Neden Muaf?

Apple'ın kuralları (3.1.3(e) numaralı madde), uygulama dışında tüketilecek fiziksel ürün veya hizmet satışında uygulama içi satın alma yerine Apple Pay veya geleneksel kart girişi gibi yöntemleri kullanmanızı ister. Mantık basittir: kullanıcı ürünü veya hizmeti telefon ekranında değil gerçek dünyada tüketir, dolayısıyla platformun dijital altyapısına bağımlı kalmaz.

Örneğin bir e-ticaret uygulaması üzerinden kıyafet satıyorsanız veya bir hizmet uygulamasıyla kuaför randevusu alıyorsanız, ödemeyi kendi sanal pos altyapınızla tahsil edebilirsiniz. Apple, birebir gerçekleşen kişiler arası hizmetler için de benzer bir istisna tanımlar. Ancak birden fazla katılımcıyla yürütülen hizmetlerde kural farklılaşabilir, güncel ayrımı resmi kaynaktan doğrulamanız gerekir.

Bu örnekleri kendi iş modelinizle karşılaştırırken, hizmetin uygulama ekranında mı yoksa fiziksel dünyada mı tamamlandığını sorgulayın; cevap genellikle doğru yolu kendiliğinden gösterir. Karışık modellerde (örneğin hem dijital içerik hem fiziksel ürün satan bir uygulama) iki akışı ayrı ayrı kurmanız gerekebilir, bu durumda her kategori için kuralı tek tek kontrol etmeniz gerekir.

Ürün kataloğunuzu iki sütuna ayırın. Bir sütuna dijital kalemleri yazın. Diğerine fiziksel kalemleri yazın. Bu basit tablo, hangi ödeme yolunu nerede kuracağınızı hemen gösterir.

Uygulama İçi Satın Alma ile Web Ödemesi Arasında Komisyon Farkı Nedir?

Uygulama içi satın almada platform, tahsil ettiği tutardan bir komisyon keser ve kalanını size aktarır; web üzerinden ödemede komisyon bu şekilde işlemez, bunun yerine kendi ödeme sağlayıcınızın işlem ücretini ödersiniz. Güncel komisyon oranını Apple ve Google'ın resmi geliştirici sayfalarından kontrol etmenizi öneririz, çünkü oran geliştiriciye, gelir seviyesine ve programa göre değişir.

Bu tablodaki her satırı kendi uygulamanızın ürün tipine göre tekrar değerlendirmeniz, karar sürecinizi hızlandırır. Komisyon farkını yalnızca yüzde üzerinden değil, kullanıcı deneyimi ve işletme yükü üzerinden de tartmanız, daha dengeli bir karar vermenizi sağlar.

Bu tabloyu yazdırıp duvara asabilirsiniz. Her yeni özellik eklerken tekrar bakın. Komisyon hesaplamanızı çeyrek dönemde bir güncel oranla kontrol edin. Küçük bir sapma, yıl sonunda büyük bir farka dönüşebilir.

Küçük İşletme Programları Komisyon Oranını Nasıl Etkiler?

Apple'ın küçük işletme programı, belirli bir yıllık gelir eşiğinin altında kalan ya da platforma yeni katılan geliştiricilere indirimli bir komisyon kademesi sunar. Eşik ve indirimli oran zaman içinde değişebildiği için kesin sayı yerine, uygunluk şartlarını ve güncel oranı resmi sayfadan kontrol etmenizi öneririz.

Google Play tarafında da kademeli bir yapı vardır; belirli programlara katılım veya gelir seviyesine göre hizmet ücreti kademesi değişebilir. Her iki platformda da bu programlara kaydı genellikle siz geliştirici hesabınızdan yaparsınız, sistem bunu otomatik uygulamaz.

Başvurunuz onaylandıktan sonra indirimli kademe genellikle bir sonraki faturalandırma döneminde yürürlüğe girer, bu yüzden geçiş sürecini erkenden planlamanız gerekir. Gelir eşiğini aştığınız yıl standart komisyon oranına döneceğinizi de hesabınıza eklemeniz, bütçe sürprizlerini önler.

Google Play'in Hizmet Ücreti Kademeleri Nasıl İşler?

Google Play'in resmi yardım sayfasına göre, Google Play Faturalandırma veya Alternatif Faturalandırma Sistemi üzerinden satılan uygulama içi ürünler bir hizmet ücretine tabidir. Google, bazı programlara katılan geliştiriciler için daha düşük bir ücret kademesine geçiş imkânı tanır.

Fiziksel ürün ve hizmetler bu hizmet ücretinin kapsamı dışında kalır. Ancak bu ayrımın sınırlarını kendi uygulamanız için netleştirmek üzere Google'ın ödemeler politikasını okumanızı öneririz. Google bu kapsamı düzenli olarak güncelleyebilir, bu yüzden hizmet ücretine tabi olup olmadığınızı her yeni ürün kategorisi eklediğinizde yeniden kontrol etmeniz akıllıca olur.

Google Play konsolunda faturalandırma raporlarınızı düzenli inceleyin. Hizmet ücreti kesintisini aylık olarak gözden geçirin. Beklenmedik bir sapma görürseniz, önce resmi politika sayfasını kontrol edin. Sonra gerekirse destek ekibine ulaşın.

Mali müşavirinize de danışarak komisyonun muhasebe ve vergi yansımalarını netleştirebilirsiniz; bu yazı vergi veya hukuki danışmanlık niteliği taşımaz, yalnızca genel bir rehber sunar.

Harici Ödeme Bağlantılarına Hangi Durumlarda İzin Var?

Bazı ülke ve bölgelerde düzenleyici kararlar, uygulamaların kullanıcıyı uygulama dışındaki bir ödeme sayfasına yönlendirmesine kısmen izin verir. Bu izin her bölgede aynı şekilde işlemez, bazı durumlarda platformdan özel bir yetki (entitlement) almanız gerekir.

Bölgeden bölgeye değişen bu kuralı kendi uygulamanız için kullanmadan önce resmi geliştirici sayfasından güncel durumu doğrulamanız gerekir. Yanıltıcı yönlendirme veya kullanıcıyı aldatan bir harici bağlantı kurgusu, uygulamanızın mağazadan kaldırılmasına kadar gidebilecek bir risk taşır.

Birden fazla ülkede yayındaysanız, her bölge için ayrı bir uyumluluk kontrolü yapmanız gerekir; tek bir bölgede onaylanan bir akışı otomatik olarak diğer tüm mağazalara uygulayamazsınız. Bu nedenle uluslararası büyüme planınızı yaparken hukuk ve geliştirici ilişkileri ekibinizle bu konuyu erkenden gözden geçirmeniz gerekir.

Bölgesel kuralları bir tablo halinde takip edin. Hangi pazarda hangi akışın geçerli olduğunu yazılı tutun. Bu kayıt, yeni bir ülkeye açılırken size zaman kazandırır. Ekibiniz değişse bile bilgi kaybolmaz.

Pazarlama ekibiniz yeni bir ülkeye kampanya açmadan önce bu tabloyu kontrol etsin. Reklam metninde yanlış bir ödeme vaadi vermemek için bu adım önemlidir. Kullanıcıya sunduğunuz seçenek, o bölgede geçerli olan kuralla uyuşmalıdır.

Abonelik Modelinde Komisyon Zamanla Değişir mi?

Evet, çoğu abonelik modelinde kullanıcı aboneliğini belirli bir süre kesintisiz sürdürdüğünde komisyon oranı düşebilir. Bu indirim otomatik işler, ayrı bir başvuru gerektirmez. Ancak tam süre ve oran platformdan platforma farklılaşabilir.

Abonelik fiyatlandırmanızı kurarken bu zamana bağlı değişimi de hesaba katmanız, uzun vadeli kârlılık projeksiyonunuzu daha gerçekçi kılar. Örnek senaryo: yıllardır aktif olan bir abone için net geliriniz, yeni kaydolan bir aboneye göre daha yüksek olabilir, güncel eşiği ve oranı resmi sayfadan teyit edin.

Kullanıcı aboneliğini iptal edip belirli bir süre sonra yeniden başlatırsa, komisyon kademesi sıfırlanabilir; bu döngüyü anlamak, müşteri elde tutma stratejinizi ve fiyatlandırma modelinizi birlikte kurmanıza yardımcı olur.

Abonelikte sadakat önemlidir. Uzun süreli aboneler genellikle daha değerlidir. İptal oranınızı düzenli takip edin. Bu rakam, komisyon planınızın doğruluğunu da etkiler.

Abonelik panelinizde kohort bazlı bir rapor tutun. Her kayıt ayını ayrı bir satırda izleyin. Bu rapor, hangi kampanyanın daha sadık abone getirdiğini gösterir. Böylece pazarlama bütçenizi daha isabetli yönlendirirsiniz.

Reader (Okuyucu) Uygulaması İstisnası Kimler İçin Geçerli?

Apple, kitap, dergi, gazete, müzik, ses ve video gibi kullanıcının önceden satın aldığı içeriğe erişim sağlayan "reader" uygulamaları için ayrı bir istisna tanımlar. Bu uygulamalar, hesap oluşturma veya yönetimi için kendi web sitenize bilgilendirici bir bağlantı verebilir.

İstisna kapsamı dardır, her içerik türü otomatik olarak bu kategoriye girmez. Uygulamanızın bu istisnaya uyup uymadığını netleştirmek için Apple'ın resmi inceleme kurallarını satın alma akışınızı tasarlamadan önce okumanızı öneririz.

Haber, medya veya içerik odaklı bir platform işletiyorsanız, bu istisnanın sınırlarını yanlış yorumlamak, uygulamanızın inceleme sürecinde reddedilmesine yol açabilir. Bu yüzden akışınızı kurmadan önce benzer kategorideki onaylanmış uygulamaların genel yaklaşımını da incelemeniz faydalı olur.

İçerik türünüz net değilse önce küçük bir test sürümü hazırlayın. İnceleme ekibinin geri dönüşünü gözlemleyin. Bu geri dönüş, akışınızı büyük ölçekte yayınlamadan önce size değerli bir sinyal verir.

Uygulama İçi Satın Alma mı Web Ödemesi mi: Hangisini Seçmelisiniz?

Doğru seçim, sattığınız şeyin türüne, hedef kitlenizin ödeme alışkanlığına ve büyüme hedefinize bağlıdır. Aşağıdaki tablo, iki yolu iş modeli açısından karşılaştırır.

Kuralın sizi zorunlu kılmadığı durumlarda bile, kullanıcı deneyimindeki akıcılık bazen komisyon maliyetinden daha değerli olabilir. Bu yüzden kararı yalnızca maliyet üzerinden değil, dönüşüm oranı üzerinden de değerlendirmenizi öneririz. İş modeliniz zamanla değişirse, ödeme stratejinizi de aynı tabloyla yeniden gözden geçirmeniz gerekir.

Kararınızı tek başınıza vermeyin. Ürün, finans ve hukuk temsilcilerini aynı masaya oturtun. Her taraf kendi bakış açısını paylaşsın. Ortak bir karara vardığınızda uygulama çok daha tutarlı ilerler.

Kuralı İhlal Etmenin Riskleri Nelerdir?

Platform kurallarını ihlal eden bir ödeme akışı, inceleme sürecinde reddedilme veya yayındaki uygulamanın mağazadan kaldırılmasıyla sonuçlanabilir. Bu durum hem gelir kaybına hem de kullanıcı güveninin sarsılmasına yol açar.

• Uygulama içinde satılması gereken içeriği web'e gizlice yönlendirmek.
• Yanıltıcı ya da gizlenmiş harici ödeme bağlantıları kurmak.
• Entitlement gerektiren bir yönlendirmeyi izinsiz uygulamak.

Kurallara aykırı bir yöntemle sistemi atlatmaya çalışmak, kısa vadede komisyon tasarrufu sağlasa bile uzun vadede hesabınızın veya uygulamanızın tamamen kapanma riskini taşır. Bu nedenle belirsiz kaldığınız her noktayı yayına almadan önce resmi kaynaktan doğrulamanız gerekir.

Ekibiniz büyüdükçe ve ödeme akışınız karmaşıklaştıkça, her güncellemeden önce ilgili kuralları yeniden kontrol etmeyi süreçinize sabit bir adım olarak eklemeniz, benzer riskleri erken aşamada yakalamanızı sağlar.

Küçük bir ihlal bile ciddi sonuç doğurabilir. Bu yüzden şüpheli bir akışı asla tek başınıza yayınlamayın. Ekip içi bir onay adımı ekleyin. Bu adım, hem sizi hem kullanıcılarınızı korur ve ekip içi güveni pekiştirir.

Komisyon Maliyetini Fiyatlandırmanıza Nasıl Yansıtırsınız?

Komisyonu net kârınızdan düşmek yerine, ürün fiyatınızı belirlerken baştan hesaba katmanız daha sağlıklı bir yaklaşımdır. Güncel oranı resmi sayfadan alıp kendi finansal modelinize işlemeniz, fiyatlandırma kararınızı gerçekçi kılar.

Web ödemesine geçerek komisyonu azaltmayı planlıyorsanız, bunun karşılığında kullanıcı deneyiminde oluşacak sürtünmeyi ve olası dönüşüm düşüşünü de modelinize eklemeniz gerekir. Böylece iki yolu da aynı tabloda, aynı varsayımlarla kıyaslayabilirsiniz.

Örnek senaryo: dijital içerik satan bir uygulamada aylık tekrarlayan geliriniz varsa, komisyon sonrası net rakamı kampanya bütçenizle birlikte izlemeniz, pazarlama yatırımınızın gerçek geri dönüşünü görmenizi sağlar. Bu hesaplamayı düzenli aralıklarla güncel oranlarla tekrar yapmanız, bütçe planlamanızı sağlam tutar.

Fiyatlandırma kararınızı tek seferlik bir işlem olarak görmeyin. Piyasa koşulları değişir. Rakip fiyatları da izleyin. Bu üç veriyi birlikte okuduğunuzda fiyatınız gerçekten doğru olur.

Hibrit Model: Uygulama İçinde Bilgilendirme, Web'de Satış Mümkün mü?

Bazı durumlarda uygulama içinde fiyatı göstermek ama tahsilatı web üzerinden yapmak mümkündür. Ancak bu akışın platform kurallarına uygun kurulması gerekir, aksi halde yanıltıcı yönlendirme olarak değerlendirilebilir. Reader istisnası veya izin verilen bölgesel yetkiler bu hibrit modelin yasal çatısını oluşturur.

Hibrit model kurmadan önce hem Apple hem Google'ın güncel kurallarını birlikte okumanız, iki platformda da uyumlu bir akış tasarlamanız gerekir. Aksi takdirde bir platformda onaylanan yöntem diğerinde reddedilebilir.

Hibrit modeli test ederken küçük bir kullanıcı grubuyla başlamanız, akışın hem teknik hem politik açıdan sorunsuz çalıştığını görmeden tüm kullanıcı tabanınıza açmamanız riski azaltır.

Testi en az bir inceleme döngüsü boyunca sürdürün. Geri bildirimleri not alın. Akışı buna göre düzeltin. Ancak bu adımı atlarsanız, sorunu çok daha büyük bir kullanıcı grubunda fark edersiniz.

Mobil Uygulama Geliştirme Sürecinde Ödeme Modeli Ne Zaman Planlanmalı?

Ödeme modelini uygulamanın mimarisi belirlenmeden önce, proje planlama aşamasında netleştirmeniz gerekir. Aksi halde geliştirme ortasında yapılan bir ödeme değişikliği zaman ve bütçe kaybına yol açar. Bu konu, mobil uygulama geliştirme maliyetini belirleyen kalemlerden biridir.

Ödeme modeli kararını netleştirirken uygulama mağazası optimizasyonu, kullanıcı edinme maliyeti ve uzun vadeli büyüme hedefinizi birlikte değerlendirmeniz gerekir; bu konuyu uygulama mağazası optimizasyonu (ASO) rehberimizde ayrıca ele aldık. İhtiyaç halinde mobil uygulama geliştirme hizmetimiz üzerinden ödeme akışınızı platform kurallarına uygun şekilde kurmanıza destek oluruz.

Planlama belgenize bir "ödeme modeli" başlığı açın. Burada hangi ürünün hangi yolla satılacağını yazın. Geliştirici ekibinize bu belgeyi erkenden paylaşın. Böylece kod yazımı başlamadan önce herkes aynı sayfada olur.

Erken planlama, sadece teknik riski değil ticari riski de azaltır. Çünkü yanlış bir ödeme modeliyle yayına çıkan bir uygulama, kullanıcı tabanı büyüdükten sonra model değiştirmek zorunda kalırsa hem gelir hem itibar kaybı yaşayabilir.

Planlama toplantısında bu konuyu ayrı bir gündem maddesi yapın. Karar vericileri toplantıya davet edin. Teknik ekip de görüşünü paylaşsın. Böylece herkes aynı plana göre ilerler.

Native mi Cross-Platform mu Seçimi Ödeme Entegrasyonunu Etkiler mi?

Evet, kısmen etkiler. Ödeme kütüphanelerinin entegrasyon kolaylığı platforma göre değişebilir, bu konuyu native mi cross-platform mu kararı rehberimizde karşılaştırdık. Uygulamanız Progressive Web App (PWA) olarak da kurulabiliyorsa, ödeme modeli denklemi tamamen değişir; bu alternatifi mobil uygulama mı PWA mı karşılaştırmamızda inceledik.

Uygulamanız mağazadan reddedilir veya kaldırılırsa ödeme akışı da devre dışı kalır; bu riskleri uygulamanın mağazadan kaldırılması ve itiraz süreci yazımızda ayrıntılı ele aldık. Komisyon sonrası net gelirinizi ve pazarlama bütçenizi karşılaştırırken ROAS hesaplama aracımızı kullanabilirsiniz, fiyatınıza KDV eklemeniz gerekiyorsa KDV hesaplama aracımızdan da destek alabilirsiniz.

Teknoloji seçiminizi yalnızca geliştirme hızına göre yapmayın. Ödeme entegrasyonunun uzun vadeli bakımını da düşünün. Her platform güncellemesinde kütüphanelerinizi de güncellemeniz gerekir. Bu bakım yükünü baştan planlamanız size zaman kazandırır.

Kısa Karar Rehberi: Hangi Ödeme Yöntemini Seçmelisiniz?

Kesin bir kazanan ilan etmek doğru olmaz, çünkü doğru yol sattığınız şeye bağlıdır. Aşağıdaki kısa adımları sırayla uygulayarak kendi kararınızı verebilirsiniz.

1. Sattığınız şeyin uygulama içinde mi yoksa dışında mı tüketildiğini belirleyin.
2. Dijital içerikse, Apple ve Google'ın güncel zorunluluk kurallarını resmi sayfadan kontrol edin.
3. Güncel komisyon oranını ve varsa küçük işletme kademesini resmi geliştirici sayfasından alın.
4. Komisyon maliyetini fiyatlandırmanıza ve ROAS hesabınıza işleyin.
5. Hedef bölgelerinizde harici ödeme bağlantısına izin verilip verilmediğini ayrıca doğrulayın.
6. Kararınızı hem maliyet hem kullanıcı deneyimi açısından tekrar gözden geçirin.

Bu adımları her bütçe döngüsünde tekrar gözden geçirmeniz, kuralların ve oranların güncel kalmasını sağlar. Belirsiz kaldığınız noktalarda resmi kaynağa dönmeniz, uzun vadede en güvenli yoldur. Ekibimiz, mobil uygulama projelerinde bu kararı müşterilerimizle birlikte baştan planlayarak hem teknik hem ticari riski azaltmaya çalışır.

Bu rehberi tek seferlik bir okuma olarak değil, sürekli başvurduğunuz bir kontrol listesi olarak kullanın. Her yeni özellik veya yeni pazar kararında aynı adımları tekrar edin. Kurallar güncellendiğinde listenizi de güncelleyin. Böylece karar verme sürecinizi her zaman güncel ve sağlam tutarsınız.

Son olarak, aldığınız kararı yazılı bir belgeye dökün. Hangi ürünün hangi yöntemle satıldığını, hangi kaynaktan doğruladığınızı ve kontrol tarihinizi not edin. Bu küçük alışkanlık, hem ekip içi iletişimi kolaylaştırır hem de ileride bir denetim ya da ortak sorusu geldiğinde size hazır bir cevap sunar. Talha Aslan ve ekibi olarak biz de kendi projelerimizde bu kayıt alışkanlığını standart bir adım olarak uyguluyoruz.