Geri ödeme taleplerinin nasıl ele alınacağına dair çoğu kılavuz bildirimle başlar. Apple size bildirim gönderir, Google size bildirim gönderir, işte göndermeniz gereken yanıt budur. Mantıklı, ama bildirim geldiğinde yapılması gereken işin büyük kısmı ya zaten yapılmış ya da zaten kaçırılmıştır, çünkü bir satın alma hakkında söyleyebilecekleriniz, bu işlem gerçekleştiğinde kaydettiklerinize bağlıdır.
Bu yazı ise daha erken bir noktadan, ödeme aşamasından başlıyor. Bir geri ödeme talebi geldiğinde hangi satın alma verilerinin önemli olduğunu, bunların nerede saklanacağını ve bunların mağazanın gerçekten dikkate alacağı bir yanıta nasıl dönüştüğünü ele alıyoruz. Eğer bir satın almaya hiçbir zaman bir tanımlayıcı eklemediyseniz, önce appAccountToken ve geri ödeme savunması başlıklı yazımızı okuyun, çünkü aşağıdaki her şey bir işlem kimliğini bir kişiyle eşleştirebildiğinizi varsayıyor.
Önemli noktalar
Apple ve Google geri ödemelere kendileri karar verir ve her ikisi de artık önce sizden satın alma verisi ister. Apple 12 saat, Google ise 24 saat süre verir.
Mağazalar ayrıntılı kayıtlar değil, kaba hatlarıyla gerçekleri ister. Teslim edildi mi, ne kadarı kullanıldı, bir örnek verildi mi ve siz ne tercih edersiniz.
Her satın alma için saklamanız gereken dört şey vardır: kim, ne zaman teslim edildiği, ne zaman kullanıldığı ve bu hesaba daha önce geri ödeme yapıp yapmadığınız.
Apple, geri ödeme taleplerinin büyük çoğunluğunun satın almadan sonraki 30 gün içinde geldiğini söylüyor. Verileri en az bu kadar süre, gerçekçi olarak 90 gün saklayın.
Yanıt vermeye başlayan uygulamalarda geri ödeme oranları yaklaşık üçte bir oranında düşüyor, ama bunun için kayıtlı olarak söyleyecek bir şeyin olması gerekiyor.
Mağazalar sizden gerçekte ne istiyor
Apple'ın isteği küçük. Bir müşteri uygulama içi bir satın alma için geri ödeme talep ettiğinde CONSUMPTION_REQUEST bildirimi alırsınız ve Send Consumption Information uç noktası üzerinden beş alanla yanıt verirsiniz. Müşterinin veri paylaşmanıza izin verip vermediği, satın almanın teslim edilip edilmediği, ne kadarının tüketildiği (milliunit cinsinden, yani 100,000 tamamı demek), önce ücretsiz bir örnek veya deneme sürümü alıp almadıkları ve geri ödeme tercihiniz. Apple eskiden bir düzine alan isterdi ve bunların çoğunu kaldırdı; bunu Apple'ın müşterinin geçmişini sizden daha iyi bildiğine zaten karar verdiği şeklinde yorumluyorum.
Google'ın sürümü ise ters ibrazlar (chargeback) içindir ve biraz daha zengindir. Bekleyen bir geri ödeme inceleme bildirimi, Real-time Developer Notifications üzerinden bir token ile gelir. Bu token'ı, aynı örnek içerik işaretini, DECLINE, APPROVE veya NEUTRAL tercihini, isteğe bağlı bir tüketim yüzdesini ve zaman damgalı en fazla 1,000 kullanım olayını orders.reviewrefund uç noktasına gönderirsiniz. Bu, Google'ın 3 Ağustos 2026'dan sonraki siparişler için ters ibrazlar konusunda geliştiricilerden ücret almaya başlamasıyla artık daha da önemli hale geliyor.
Hiçbir mağaza analiz verilerinizin dışa aktarımını istemez. İstedikleri teslimat, tüketim, örnekleme ve tercih bilgisidir; sakladığınız diğer her şey bunları doğru ve hızlı bir şekilde doldurmak için vardır.
Geri ödemeler için satın alma geçmişi: ne saklanmalı ve ne kadar süreyle
Minimum gereken şunlar:
Ödeme aşamasında bir tanımlayıcı. Apple'da appAccountToken, Google'da obfuscatedAccountId. Bu olmadan, bir geri ödeme talebi bir işlemi belirtir ama bunun kime ait olduğu hakkında hiçbir fikriniz olmaz. Apple'ın mühendisleri de kullanıcı başına en az bir originalTransactionId saklamanızı önerir, çünkü bunlardan herhangi biriyle Get Transaction History'yi çağırabilir ve o müşterinin uygulamanızdaki tüm satın alma geçmişini, uygulamayı hâlâ yüklü tutup tutmadığına bakılmaksızın alabilirsiniz.
Bir teslimat kaydı. Jetonları verdiğiniz veya seviyeyi açtığınız an, bir zaman damgası ve bir sonuçla birlikte. Teslimat başarısız olduysa, bunu açıkça belirtin. Bu, geri ödemenin onaylanmasını istemeniz gereken tek durumdur; aksini öne sürmek, daha sonra ihtiyaç duyacağınız güvenilirliği zedeler.
Tüketim olayları. Her dokunuşu değil, sadece satın almanın kullanıldığını gösterenleri: harcanan jetonlar, açılan bölüm, çalıştırılan dışa aktarma. Google bunlardan bine kadarını kabul eder. Apple sadece bir yüzde ister, ama hiç kaydetmediğiniz bir yüzdeyi hesaplayamazsınız.
Ürün başına bir örnek işareti. Bu müşteri bir deneme sürümü, bir önizleme veya ücretsiz bir katman mı aldı? Her iki mağazada da evet veya hayır şeklinde bir cevap gerekir ve insanlar bunu sürekli unutur.
Hesaptaki önceki geri ödemeler. Apple geri ödeme geçmişini zaten kendisi değerlendiriyor, ama kendi kurallarınız için bu bilgiye yine de ihtiyacınız olacak.
Saklama süresi konusunda Apple, geri ödeme taleplerinin çoğunun 30 gün içinde geldiğini ve tüketim verilerinin buna göre saklanması gerektiğini belirtiyor. Biz 90 gün saklıyoruz; bunun bir nedeni Google ters ibrazlarının daha geriden gelebilmesi, diğer nedeni ise saklamanın ucuz olması, hafızaya dayanarak tartışmanın ise öyle olmaması.
Satın alma geçmişi geri ödemelerde nasıl yardımcı olur
Bu altyapı kurulduğunda, talep artık bir öznel değerlendirme olmaktan çıkar ve basit bir sorgulamaya dönüşür.
Teslim edilmiş, tamamen tüketilmiş, örnek sunulmamış, önceki geri ödeme yok: bu DECLINE için uygun bir durumdur. Teslim edilmiş, zar zor kullanılmış, bir gün içinde talep edilmiş: GRANT_FULL çok az maliyet getirir ve alternatifi küçücük görünür. Teslimat sizin tarafınızda başarısız olmuş: onaylayın ve hatayı düzeltin. Birkaç hafta boyunca kısmen kullanılmış: Apple bunun için GRANT_PRORATED seçeneğine sahiptir, Google'da ise tüketim yüzdesi aynı işi görür.
Sayılar bunu doğruluyor. Bir abonelik sesli içerik uygulaması olan Dipsea, 2024'ün sonunda Apple'ın taleplerine yanıt vermeye başladı ve geri ödeme oranı yaklaşık iki hafta içinde yüzde 3'ten yüzde 1.9'a düştü. Ters ibrazlar konusunda Appcharge, PocketGamer'a destekli olmayan anlaşmazlıkların yüzde 20 ila 30 oranında kazanıldığını, kanıta dayalı olanların ise yüzde 80'in üzerinde kazanıldığını söyledi. Refund Sensor'daki 800'den fazla uygulama genelinde, uygun taleplerin yüzde 77'si başarıyla savunuldu ve kaybedilenlerin çoğunda kayıtlı hiçbir şey yoktu.
Satın alma geçmişinin yapmadığı şey, kazanmamanız gereken tartışmaları kazanmanızı sağlamaktır. Müşterinin verileri uygulamayı sadece bir kez açtığını gösteriyorsa, dürüst cevap geri ödemedir.
Geri ödeme taleplerini süre içinde nasıl işleme koyarsınız
Her iki mağazadaki geri ödeme talebi süreci de süreyle sınırlıdır, bu yüzden bu iş değerlendirmeden çok altyapı meselesidir. Bildirim, kayıtlı bir uç noktanıza gelir. İmzayı doğrularsınız, işlem kimliğini alırsınız, kullanıcının teslimat ve tüketim kayıtlarına bakarsınız, yüzdeyi hesaplarsınız, önceden yazdığınız bir kurala göre tercihi seçersiniz ve gönderirsiniz. Ne gönderdiğinizi ve ne zaman gönderdiğinizi kaydedin, sonra sonucu bekleyin; bu, Apple'da bir REFUND veya REFUND_DECLINED bildirimidir. Bir REFUND durumunda erişimi aynı saat içinde iptal edin, çünkü geri ödeme alıp içeriği elinde tutan bir müşteri genellikle daha fazlasını almak için geri gelir.
İki şey insanları takılmaya iter. Onay: Apple, customerConsented true olmadıkça gönderimi kabul etmez, dolayısıyla kullanım verilerini paylaşma izninin ilk talep gelmeden önce koşullarınızda yer alması gerekir. Ve zamanlama: saatler hafta sonları için durmaz ve taleplerin şaşırtıcı bir kısmı gece yarısı gelir. Geri ödeme talebi yönetimi büyük ölçüde her an birinin uyanık olmasını sağlamaktan ibarettir. Apple geri ödeme talebi yönetimi kılavuzumuz operasyonel tarafa daha derinlemesine iniyor.
Geliştiriciler için geri ödeme işleme yazılımı, ya da kendi kodunuz
Bir backend ekibiyle, yukarıdaki iş akışı bir haftalık bir çalışma ve ardından sürekli bir görevdir; pahalı olan kısım da bu süregelen görevdir.
RevenueCat veya Adapty kullanıyorsanız, her ikisi de SDK'larının zaten topladığı kullanım verilerinden Apple'ın tüketim taleplerini yanıtlar ve Adapty, Google'ın incelemesini de kapsar. SDK zaten uygulamanızdaysa mantıklı bir varsayılan seçenektir.
Refund Sensor da aynı şeyi bir SDK olmadan yapar. Bir App Store Connect API anahtarı ve bir bildirim URL'si bağlarsınız; o da talepleri alır, yanıtı süre içinde gönderir ve her vaka için bir zaman çizelgesi tutar. Kurulum birkaç dakika sürer ve fiyatlandırma sabittir. Ayrıntılar Refund Sensor sitesinde yer alıyor.
Hiçbir şey seçmemek dahil, hangisini seçerseniz seçin, veri katmanı size aittir. Geliştiriciler için hiçbir geri ödeme işleme yazılımı, sizin tutmadığınız bir teslimat kaydını icat edemez.
Sonuç
Geri ödeme savunması genellikle bir yanıt verme sorunu olarak konuşulur, ama aslında bir kayıt tutma sorununun sonucudur. Mağazalar dört dar kapsamlı soru sorar ve bunları yanıtlayıp yanıtlayamayacağınız, kimse henüz parasını geri istemeden çok önce, ödeme ve teslimat aşamasında verdiğiniz kararlara bağlıdır.
Bir tanımlayıcı ekleyin, teslimat ve tüketimi zaman damgalarıyla kaydedin, örnekleri işaretleyin ve bunların hepsini 90 gün boyunca saklayın. Bu altyapı kurulduğunda, geri ödeme taleplerinin nasıl işleneceği bir kurala ve bir cron işine dönüşür, geri ödeme oranı da kendiliğinden düzelme eğilimi gösterir.
Sık sorulan sorular
Apple, CONSUMPTION_REQUEST bildiriminden itibaren size 12 saat süre verir. Google, bir ters ibraz için bekleyen geri ödeme inceleme bildiriminden itibaren 24 saat süre verir. Süreyi kaçırırsanız her ikisi de sizsiz karar verir.
Beş alan: müşteri onayı, teslimat durumu, milliunit cinsinden tüketim yüzdesi, bir örnek sunulup sunulmadığı ve geri ödeme tercihiniz. Hesap yaşı ve ömür boyu harcama gibi eski alanlar kaldırıldı.
Büyük ölçüde evet, ayrıca elinizdeyse daha fazla ayrıntı da ister. Google bir tüketim yüzdesi ve zaman damgalı en fazla 1,000 kullanım olayı alır; tercih seçenekleri DECLINE, APPROVE veya NEUTRAL'dır.
Apple'da, evet. customerConsented true olmadıkça gönderim reddedilir, bu yüzden iznin talep gelmeden önce koşullarınızda yer alması gerekir.
Hayır. Her iki mağaza da tercihinizi tek bir girdi olarak değerlendirir ve her ikisi de müşterinin tüm geçmişini görür. Kendi verileriniz teslimatın başarısız olduğunu veya kullanımın neredeyse sıfır olduğunu gösterirken reddetmek, önemli olan durumlarda güvenilirliğinize zarar verir.
