Uygulama içi Satın Alma mı, Sanal POS mu? Ödeme Rehberi

Uygulama içi satın alma, dijital içerik veya abonelik satan her mobil uygulama için zorunludur ve Apple ile Google bu satışlardan %15-30 komisyon alır. Fiziksel ürün ya da uygulama dışında tüketilen hizmet satıyorsanız store komisyonu %0'dır; uygulama ödeme entegrasyonunu iyzico veya PayTR gibi yerel sanal POS ile kurarsınız.

Bu ayrımı kaçıran ekipler iki şekilde bedel ödüyor: ya dijital abonelik için kurdukları sanal POS yüzünden uygulama mağaza incelemesinden geri dönüyor, ya da fiziksel ürün satan bir e-ticaret uygulamasına gereksiz yere uygulama içi satın alma kurup cirosunun üçte birini masada bırakıyor.

Türkiye'de pazar hızla büyüyor. Ticaret Bakanlığı'nın ETBİS verilerine göre 2025'te e-ticaret hacmi %52,2 artışla 4,57 trilyon TL'ye ulaştı; perakende e-ticaret ise %51,8 artışla 2,46 trilyon TL oldu (Türkiye'de E-Ticaretin Görünümü Raporu 2025). Bu hacmin %62,5'i kart ile ödeniyor.

Bu rehberde store kurallarını Apple ve Google'ın kendi dokümanlarından, mevzuatı Resmî Gazete metninden ve komisyonları resmi fiyat sayfalarından derledik. Rakamların tamamı Eylül 2026 itibarıyladır.

İçindekiler

• Store Ödemesi mi, Sanal POS mu? Önce Bu Ayrımı Yapın
• Apple ve Google Kuralı: Hangi Satışta IAP Zorunlu?
• Komisyon Tablosu: Store mu, Yerel Sanal POS mu?
• Türkiye Gerçeği: iyzico, PayTR ve Stripe
• Mevzuat: 3D Secure Zorunluluğu ve PCI DSS
• Teknik Entegrasyon: Ödeme Formu, WebView ve Native SDK
• Abonelik Satıyorsanız: IAP mı, Web Üzerinden Satış mı?
• Değişen Kurallar: ABD, Avrupa Birliği ve Türkiye
• Ödeme Entegrasyonunda En Sık Yapılan 7 Hata
• Maliyet ve Süre: Entegrasyon Ne Kadar Tutar?
• Sıkça Sorulan Sorular

Store Ödemesi mi, Sanal POS mu? Önce Bu Ayrımı Yapın

Mobil uygulamada para tahsil etmenin iki ayrı yolu var ve bunlar birbirinin alternatifi değil. Hangisini kullanacağınıza siz değil, sattığınız şeyin cinsi karar veriyor.

Uygulama içi satın alma (IAP / In-App Purchase): Ödemeyi Apple veya Google alır. Kullanıcı kartını mağaza hesabına bir kez tanımlar, sonraki satın almalarda tek dokunuşla öder. Para size komisyon düşülmüş halde, mağazanın ödeme takvimine göre ulaşır. Faturalandırmayı ve çoğu ülkede vergiyi mağaza üstlenir.

Sanal POS (ödeme kuruluşu veya banka): Ödemeyi siz alırsınız. Kart bilgisi iyzico, PayTR veya bankanızın altyapısı üzerinden geçer, para doğrudan sizin ticari hesabınıza iner. Taksit, iade, kapıda ödeme ve fatura akışı sizin kontrolünüzdedir.

Aradaki fark sadece komisyon değil. IAP'de taksit yoktur — Türkiye'de e-ticaretin can damarı olan 3, 6, 9 taksitli satışı uygulama içi satın almayla yapamazsınız. Buna karşılık IAP'de dönüşüm oranı yüksektir, çünkü kullanıcı kart bilgisi girmez.

Karar ağacı tek cümleye sığıyor: ürün telefonun içinde tüketiliyorsa IAP, telefonun dışında tüketiliyorsa sanal POS.

Apple ve Google Kuralı: Hangi Satışta IAP Zorunlu?

Bu, tahmin yürütülecek bir konu değil; iki şirket de kuralı yazılı olarak yayımlıyor.

Apple'ın App Review Guidelines 3.1.1 maddesi net: "Uygulamanız içinde özellik veya işlevsellik açmak istiyorsanız (abonelikler, oyun içi para birimleri, oyun seviyeleri, premium içeriğe erişim veya tam sürümün açılması gibi) uygulama içi satın alma kullanmalısınız." Aynı madde lisans anahtarı, QR kod, kripto para gibi alternatif açma mekanizmalarını da yasaklıyor. Dijital hediye kartları da yalnızca IAP ile satılabiliyor.

Buna karşılık 3.1.3(e) maddesi tersini emrediyor: "Uygulamanız, uygulama dışında tüketilecek fiziksel ürün veya hizmet satın almaya imkân veriyorsa, bu ödemeleri tahsil etmek için uygulama içi satın alma dışındaki yöntemleri kullanmalısınız." Yani fiziksel ürün satan bir uygulamaya IAP koymak sadece gereksiz değil, kural ihlalidir.

Google tarafında Play Ödemeler politikası aynı mantığı izliyor. Play faturalandırmasının zorunlu olduğu kalemler: uygulama içi satın almalar (sanal para, ek can, ek oynanış süresi, karakterler), abonelik hizmetleri (fitness, oyun, flört, eğitim, müzik, video), uygulama işlevi veya içeriği (reklamsız sürüm, yeni özellikler) ve bulut yazılım hizmetleri (veri depolama, iş verimliliği yazılımı).

Google'ın açık muafiyet listesi ise şöyle: fiziksel ürün alım veya kiralaması (market, giyim, ev eşyası, elektronik), fiziksel hizmet alımı (ulaşım, temizlik, uçak bileti), kredi kartı veya fatura ödemesi, kişiden kişiye ödemeler, çevrim içi müzayedeler ve vergiden muaf bağışlar.

Apple'ın daha az bilinen istisnaları çoğu Türk işletmesi için kritik:

3.1.3(d) maddesindeki "gerçek zamanlı" ve "iki kişi arasında" şartları kelimesi kelimesine uygulanıyor. Birebir online ders veren bir uygulama dış ödeme kullanabilir; aynı içeriği kayıttan izleten bir kurs uygulaması kullanamaz. Apple bunu da yazmış: "Bire-az ve bire-çok gerçek zamanlı hizmetler uygulama içi satın alma kullanmalıdır."

Komisyon Tablosu: Store mu, Yerel Sanal POS mu?

Türkiye mağazalarında (ABD ve AB dışındaki tüm pazarlarda olduğu gibi) Eylül 2026 itibarıyla geçerli oranlar:

Apple'ın Small Business Program eşiği bir önceki takvim yılında 1 milyon dolar net gelir. Eşik aşılırsa yıl içinde standart orana dönülüyor; gelir tekrar eşiğin altına inerse izleyen yıl yeniden başvurulabiliyor. Abonelikte Apple'ın kendi ifadesi şöyle: ilk yıl abonelik bedelinin %70'ini alırsınız, abone bir yıl ücretli hizmet biriktirdikten sonra bu oran %85'e çıkar.

Google Play tarafında hizmet ücreti tablosu, Türkiye'nin de içinde olduğu "diğer pazarlar" için yıllık ilk 1 milyon dolarda %15, üzerinde %30 diyor; abonelikler ise ciro seviyesinden bağımsız %15.

Yerel sanal POS tarafında oranlar çok daha düşük ama hizmet farklı: parayı siz tahsil eder, faturayı siz keser, iadeyi siz yönetirsiniz. Ayrıntılı kıyaslama ve TCMB tavanları için sanal POS komisyon oranları rehberimize bakın.

Rakamın anlamını bir örnekle netleştirelim. Aylık 500.000 TL'lik dijital abonelik satan bir uygulama, Apple'da Small Business Program'daysa 75.000 TL komisyon öder. Aynı 500.000 TL fiziksel ürün satışı olsaydı, %2,5'lik bir sanal POS oranıyla maliyet 12.500 TL olurdu. Altı kat fark, ürün cinsinden kaynaklanıyor — pazarlıktan değil.

Türkiye Gerçeği: iyzico, PayTR ve Stripe

Sanal POS tarafına geçtiğinizde Türkiye'ye özgü üç gerçekle karşılaşırsınız.

Stripe Türkiye'de yok. Stripe'ın desteklenen ülkeler listesinde Eylül 2026 itibarıyla Türkiye yer almıyor. Türkiye'de kurulu bir şirketle doğrudan Stripe hesabı açamazsınız. Yurt dışı müşteriye satış yapacaksanız yerli bankaların dövizli sanal POS ürünleri ya da yabancı kart tarifesi olan ödeme kuruluşları çalışan seçenekler. Yurt dışında şirket kurup Stripe kullanma yolu ayrı vergi ve mevzuat yükümlülükleri doğurur; bu kararı mali müşavirinizle alın.

Apple Pay Türkiye'de yok, Google Pay var. Apple'ın kendi özellik kullanılabilirlik sayfasında Apple Pay'in desteklendiği ülkeler listesinde Türkiye bulunmuyor. Buna karşılık Google, Google Pay'in kullanılabildiği ülkeler listesinde Türkiye'yi sayıyor. Pratik sonuç: iOS uygulamanızda fiziksel ürün satışında tek dokunuşlu cüzdan ödemesi sunamazsınız, kullanıcı kart bilgisini girmek zorunda kalır. Android'de ise ödeme kuruluşunuz destekliyorsa Google Pay düğmesi koyabilirsiniz. Bu asimetri iOS tarafında sepet terk oranını doğrudan etkiler; kart saklama özelliğini iOS'ta öncelikli geliştirmenizin sebebi budur.

Ödeme hizmetini kendiniz sunamazsınız. 6493 sayılı Kanun uyarınca ödeme hizmeti sunmak TCMB'den faaliyet izni gerektirir; izinsiz faaliyet gösterenler hakkında adli süreç işletilir. Uygulamanızda kullanıcıdan kullanıcıya para aktarımı, cüzdan bakiyesi veya bayi adına tahsilat gibi bir akış kurguluyorsanız — bu bir yazılım kararı değil, lisans konusudur. TCMB'nin yetkili kuruluşlar listesi üzerinden çalışacağınız kuruluşun izninin güncel olduğunu doğrulayın.

Mevzuat: 3D Secure Zorunluluğu ve PCI DSS

Türkiye'de internet üzerinden kart kabul eden her işletme için 3D Secure altyapısı mevzuat gereği zorunludur. Banka Kartları ve Kredi Kartları Hakkında Yönetmelik'in 27/A maddesinin yedinci fıkrası (Değişik: RG-21/11/2013-28828) şöyle diyor:

"Üye işyeri anlaşması yapan kuruluşlar ve üye işyerleri, harcama ve alacak belgesi düzenleme imkânı olmayan, kart hamili tarafından başlatılan ve internet kullanılarak gerçekleştirilen işlemler için diğer önlemlerle birlikte 3-D Secure veya asgari olarak 3-D Secure protokolünün güvenlik önlemlerini karşılayan kart hamili kimlik doğrulama teknolojisini içerecek şekilde kart kullanım alt yapısı tesis ederler. Veri işleme, kaydetme veya iletişiminde asgari seviyede Ödeme Kartı Endüstrisi Veri Güvenliği Standardının (Payment Card Industry -PCI- Data Security Standard -DSS-) hükümlerini dikkate alırlar."

Altyapıyı kurmak zorunlu; her işlemde kullanımı zorunlu kılmak ise üye işyerinin tercihine bırakılmış. Pratikte piyasa bu esnekliği kullanıyor: ETBİS raporuna göre 2025'te kartlı e-ticaret işlemlerinin %64,1'inde 3D Secure devredeydi. Kalan üçte birlik kısımda chargeback riski tamamen üye işyerinin üzerinde.

Yönetmeliğin ikinci cümlesi de en az ilki kadar önemli: PCI DSS. Kart numarasını kendi sunucunuzda saklamaya kalkarsanız denetim kapsamınız devasa büyür. Doğru yaklaşım kart verisini hiç görmemektir — ödeme kuruluşunun tokenizasyon servisini kullanır, uygulamanızda yalnızca token tutarsınız. iyzico gibi kuruluşlar bunun için Kart Saklama servisi sunuyor.

Kart verisini işlerken KVKK yükümlülükleriniz de devam eder. Aydınlatma metni, açık rıza ve saklama süreleri tarafında ne yapmanız gerektiğini mobil uygulama güvenliği ve KVKK rehberimizde ayrıntılı anlattık.

Teknik Entegrasyon: Ödeme Formu, WebView ve Native SDK

Yerel ödeme kuruluşlarıyla mobil entegrasyonda beklentiyle gerçek arasında fark var ve bunu proje başlamadan bilmek gerekir.

iyzico'nun resmi dokümantasyonunda ürünler şöyle listeleniyor: Ödeme Formu (CheckoutForm), 3DS API, Abonelik, Pazaryeri, Kart Saklama, Ön Provizyon. "Platformlar" başlığı altında ise WooCommerce, OpenCart, PrestaShop, Magento, IdeaSoft, Ticimax, ikas, T-Soft, Shopify, WIX ve nopCommerce entegrasyonları var — yani hepsi e-ticaret altyapısı eklentisi. Dokümantasyon indeksinde iOS veya Android için native SDK bulunmuyor. PayTR tarafında da yaygın yöntem iFrame API: sunucunuz PayTR'den iframe_token alır, uygulama bu token ile gömülü bir ödeme formu açar.

Bu yüzden Türkiye'de mobil ödeme entegrasyonunun fiili mimarisi şöyle kuruluyor:

1. Sunucu tarafı istek. Uygulama değil, kendi backend'iniz ödeme kuruluşuna istek atar ve token/oturum alır. API anahtarları hiçbir koşulda uygulama paketine gömülmez — APK ve IPA dosyaları kolayca açılır.
2. Gömülü ödeme ekranı. Alınan token ile uygulama içinde bir WebView (iOS'ta SFSafariViewController veya WKWebView, Android'de Custom Tabs) açılır ve kart formu orada gösterilir. Kart verisi uygulamanızın belleğine hiç girmez.
3. 3D Secure yönlendirmesi. Banka doğrulama sayfası aynı WebView içinde açılır, doğrulama sonrası dönüş adresi uygulamaya deep link ile geri döner.
4. Sunucudan sunucuya doğrulama. Ödemenin başarılı olduğuna uygulamadan gelen mesajla değil, ödeme kuruluşunun sunucunuza gönderdiği bildirimle (callback/webhook) karar verirsiniz. Bu adımı atlayan her entegrasyon manipülasyona açıktır.
5. İdempotent sipariş kaydı. Aynı bildirim iki kez gelebilir. Sipariş numarası üzerinden tekrarlı işlemi yutan bir kontrol yazılmazsa çift tahsilat ve çift sipariş kaçınılmazdır.

IAP tarafında da aynı prensip geçerli: satın almanın geçerliliğini cihazda değil sunucuda doğrularsınız. Apple için App Store Server API, Google için Play Developer API bu iş içindir. Android'de ayrıca sürüm takvimini kaçırmayın — Google'ın açıklamasına göre 31 Ağustos 2026'dan itibaren tüm yeni uygulamalar ve güncellemeler Play Faturalandırma Kitaplığı sürüm 8 veya üzerini kullanmak zorunda; ek süreye ihtiyacı olanlar 1 Kasım 2026'ya kadar uzatma talep edebiliyor. Halihazırda yayında olan uygulamalar çalışmaya devam ediyor, ancak eski kitaplıkla güncelleme yayımlayamıyorsunuz.

Ödeme akışını tasarlarken arayüz tarafını da hafife almayın; sepet ve ödeme ekranı bir uygulamanın en kırılgan noktasıdır. Mobil uygulama tasarımı sürecine dair yazımızda bu ekranların nasıl kurgulanması gerektiğini anlattık.

Abonelik Satıyorsanız: IAP mı, Web Üzerinden Satış mı?

Türkiye'den dijital abonelik satan bir SaaS veya içerik uygulaması için en pahalı karar burada veriliyor.

Uygulama içinden abonelik satarsanız IAP zorunludur ve ilk yıl %30 komisyon ödersiniz. Alternatif, aboneliği web sitenizden satmak ve uygulamayı yalnızca giriş yapılan bir istemci olarak konumlandırmaktır. Bu yasal bir yoldur, ancak kritik bir sınırı vardır.

Apple'ın 3.1.1(a) maddesi şunu söylüyor: ABD mağazası dışındaki tüm mağazalarda "uygulamalar ve meta verileri, müşterileri uygulama içi satın alma dışındaki satın alma mekanizmalarına yönlendiren düğmeler, harici bağlantılar veya eyleme çağrılar içeremez." Türkiye mağazası bu kapsamda. Yani uygulamanızın içinde "web sitemizden daha ucuza abone olun" yazamaz, oraya bir bağlantı koyamazsınız.

Yapabilecekleriniz ise şunlar:

• Web sitenizde abonelik satmak ve uygulamada sadece giriş ekranı sunmak (3.1.3(f) mantığı).
• Uygulama dışında, kendi e-posta listenize veya mevcut müşteri tabanınıza alternatif satın alma yollarını duyurmak. Apple bunu açıkça serbest bırakıyor: "Geliştiriciler, uygulama dışında kullanıcı tabanlarına uygulama içi satın alma dışındaki satın alma yöntemleri hakkında iletişim kurabilir."
• Kurumsal müşterilere doğrudan satış yapmak (3.1.3(c)).

Yapamayacağınız şey, uygulamanın içinde kullanıcıyı web ödemesine itmektir. Bu kuralın ihlali uygulamanın reddedilme sebeplerinin başında geliyor; diğer sık red sebeplerini App Store uygulama reddi yazımızda topladık.

Uygulamanızdan gelir elde etmenin IAP dışındaki modellerini (reklam, freemium, işlem komisyonu) değerlendiriyorsanız mobil uygulamadan para kazanma rehberimiz karşılaştırmalı bir çerçeve sunuyor.

Değişen Kurallar: ABD, Avrupa Birliği ve Türkiye

Store komisyonları dünya genelinde hareketli bir dönemden geçiyor ama bu hareketin Türkiye'ye yansıması sınırlı. Doğru beklenti kurmak için üç bölgeyi ayırmak gerekiyor.

ABD mağazası. Apple'ın kendi kuralı, ABD mağazasındaki uygulamalar için harici bağlantı koymanın ayrı bir yetkilendirme (entitlement) gerektirmediğini söylüyor. Komisyon tarafı ise henüz kapanmadı: Apple'ın temyiz başvurusunu ABD Yüksek Mahkemesi 30 Haziran 2026'da kabul etti (Apple Inc. v. Epic Games, No. 25-1311) ve dosya Eylül 2026 itibarıyla hâlâ dilekçe aşamasında, duruşma günü verilmedi (Yüksek Mahkeme dosya kaydı).

Avrupa Birliği. Apple, Dijital Piyasalar Yasası kapsamında 18 Ağustos 2026'da güncellediği geliştirici sözleşmesiyle AB'de 1 Ekim 2026'dan itibaren geçerli yeni bir yapıya geçiyor (Apple'ın DMA sayfası): Apple IAP ile yapılan satışlarda %26, indirimli programlarda ve birinci yılını dolduran aboneliklerde %15; uygulama içi alternatif ödeme yöntemiyle yapılan satışlarda %20 ve %10; uygulama dışı tekliflerde (bağlantıya tıklandıktan sonraki 7 gün içindeki satışlar için) %15 ve %10. Kurulum başına alınan Core Technology Fee kaldırılıp yerine %5'lik Core Technology Commission getiriliyor; Initial Acquisition Fee ve Store Services Fee tamamen kalkıyor. Google tarafında da AEA, Birleşik Krallık ve ABD için 30 Haziran 2026'dan geçerli ayrı bir tarife var.

Türkiye. Bu değişikliklerin hiçbiri Türkiye mağazasını kapsamıyor. Türkiye'de kural hâlâ klasik haliyle işliyor: dijital satışta IAP zorunlu, komisyon %30 veya %15, uygulama içinden harici ödemeye yönlendirme yasak. Bu yüzden yabancı bloglarda okuduğunuz "artık %0 komisyonla dışarı link verebilirsiniz" başlıklarını Türkiye'deki uygulamanıza uygulamayın.

Ödeme Entegrasyonunda En Sık Yapılan 7 Hata

1. Dijital aboneliği sanal POS ile satmak. İncelemeden döner. Ürün cinsini önce netleştirin.
2. Fiziksel ürüne IAP kurmak. Hem kural ihlali hem gereksiz %30 maliyet.
3. Ödeme onayına uygulamadan gelen cevapla karar vermek. Doğrulama her zaman sunucu tarafında yapılmalı.
4. API anahtarını uygulamaya gömmek. Paket dosyaları tersine mühendislikle açılır; anahtar backend'de durur.
5. Webhook'u idempotent yazmamak. Tekrar gelen bildirim çift tahsilat üretir.
6. İade akışını sonraya bırakmak. İade, mesafeli satış mevzuatının konusudur ve lansman günü hazır olmalıdır.
7. Tek ödeme kuruluşuna bağlı kalmak. Kuruluş kaynaklı kesintide satış tamamen durur; ikinci bir kanal mimaride baştan düşünülmelidir.

Maliyet ve Süre: Entegrasyon Ne Kadar Tutar?

Ödeme entegrasyonu ayrı satılan bir modül değil, uygulama projesinin bir kalemidir. Kabaca ayrışma şöyle:

Bu kalemler uygulamanın toplam bütçesi içinde genellikle %8-15 bandına denk gelir. Kendi projeniz için hızlı bir tahmin çıkarmak isterseniz mobil uygulama maliyet hesaplayıcımızı kullanabilir, yayın öncesi kontrolleri uygulama yayın kontrol listesiyle gözden geçirebilirsiniz.

Rakamların dünya ölçeğindeki karşılığını da not edelim: Business of Apps verilerine göre 2025'te iOS ve Android'de toplam uygulama harcaması 166,8 milyar dolara ulaştı, bu harcamanın %70'i iOS tarafında gerçekleşti ve abonelik gelirleri 79,5 milyar dolara çıktı (App Revenue Data). Aynı veri setinde 2025, uygulamaların ilk kez oyunları geçtiği yıl olarak kayda geçti: uygulamalar 83,6 milyar dolar, oyunlar 83,2 milyar dolar.

Sıkça Sorulan Sorular

Uygulama içi satın alma komisyonu ne kadar?

Türkiye mağazalarında Apple ve Google standart oranı %30'dur. Yıllık net geliri 1 milyon doların altındaki geliştiriciler her iki platformda da %15 öder. Aboneliklerde Google %15, Apple ise ilk yıl %30, abonenin bir yılı dolmasından sonra %15 uygular.

Mobil uygulamada iyzico veya PayTR kullanabilir miyim?

Evet, ancak yalnızca fiziksel ürün ve uygulama dışında tüketilen hizmet satışlarında. Dijital içerik, abonelik veya uygulama içi özellik satıyorsanız Apple ve Google kendi ödeme sistemlerini zorunlu tutar; bu satışlarda yerel sanal POS kullanmak uygulamanın reddedilmesine yol açar.

E-ticaret uygulamamda uygulama içi satın alma kullanmak zorunda mıyım?

Hayır, tam tersi. Apple'ın 3.1.3(e) maddesi fiziksel ürün ve uygulama dışında tüketilen hizmet satışlarında IAP dışındaki yöntemleri kullanmanızı zorunlu kılar. Google da fiziksel ürün ve hizmetleri Play faturalandırma zorunluluğundan muaf tutar.

Uygulama içinden web sitemize ödeme linki verebilir miyim?

Türkiye mağazasında veremezsiniz. Apple'ın 3.1.1(a) maddesi, ABD mağazası dışındaki tüm mağazalarda uygulama içinden alternatif satın alma yöntemlerine yönlendiren bağlantı, düğme ve eyleme çağrıları yasaklar. Uygulama dışında, örneğin e-posta ile mevcut kullanıcılarınıza duyuru yapmak serbesttir.

Türkiye'de Stripe ile mobil uygulamada ödeme alabilir miyim?

Stripe'ın desteklenen ülkeler listesinde Eylül 2026 itibarıyla Türkiye bulunmuyor, dolayısıyla Türkiye'de kurulu bir şirketle doğrudan Stripe hesabı açamazsınız. Yurt dışına satış için yerli bankaların dövizli sanal POS ürünleri veya yabancı kart tarifesi sunan ödeme kuruluşları kullanılır.

Mobil uygulamada 3D Secure zorunlu mu?

Banka Kartları ve Kredi Kartları Hakkında Yönetmelik'in 27/A maddesi, internet üzerinden yapılan kart işlemleri için 3-D Secure altyapısının kurulmasını zorunlu tutar. Her işlemde kullanımını zorunlu kılmak üye iş yerinin tercihine bırakılmıştır, ancak 3D Secure'suz işlemlerde chargeback riski tamamen iş yerinin üzerindedir.

Uygulamamda Apple Pay kullanabilir miyim?

Apple'ın özellik kullanılabilirlik sayfasındaki Apple Pay ülke listesinde Türkiye yer almıyor, dolayısıyla Türkiye'deki kullanıcılara Apple Pay ile ödeme sunamazsınız. Google Pay ise Türkiye'de kullanılabiliyor; ödeme kuruluşunuz destekliyorsa Android tarafında tek dokunuşlu ödeme ekleyebilirsiniz.

Ödeme entegrasyonu ne kadar sürer?

Tek ödeme kuruluşuyla tek seferlik ödeme entegrasyonu tipik olarak 3-6 iş günü sürer. Kart saklama, taksit yönetimi ve abonelik akışları eklendiğinde süre 2-4 haftaya çıkar. Pazaryeri modelinde alt üye iş yeri ve hak ediş akışlarıyla birlikte 10-20 iş gününü bulur.

Uygulama içi satın almada taksit yapabilir miyim?

Hayır. Apple ve Google'ın uygulama içi satın alma sistemlerinde Türkiye'ye özgü kredi kartı taksitlendirmesi bulunmuyor. Taksitli satış yalnızca yerel sanal POS üzerinden mümkündür; bu da taksitin satış için kritik olduğu sektörlerde ürün cinsinin doğru sınıflandırılmasını daha da önemli kılar.

Ödeme entegrasyonu, uygulamanın en son yazılan ama en erken kararlaştırılması gereken parçasıdır. Sattığınız şeyin cinsini ilk gün netleştirin: dijitalse store komisyonunu bütçeye koyun ve fiyatlandırmanızı ona göre kurun; fiziksel ürün veya uygulama dışı hizmetse yerel sanal POS'u, 3D Secure'u ve taksit tablosunu mimarinin merkezine alın. Bu kararı sonraya bırakan projeler, kodu yazıldıktan sonra baştan yazmak zorunda kalıyor.

Uygulamanızın ödeme mimarisini konuşmak isterseniz mobil uygulama geliştirme hizmetimizi inceleyebilir, projenizin kapsamını paylaşarak ücretsiz teklif alabilirsiniz.