Kaçırılan iade bildirimleri, itiraz edebildiğiniz tek iadeleri size kaybettirebilir. Zamanında bakarsanız iki mağaza da onları geri almanıza izin verir

Kaçırılan iade bildirimleri, bir geliştiricinin söz hakkı olduğu yalnızca iki iade kararını sessizce kaybetmesinin yoludur. Apple'ın CONSUMPTION_REQUEST'i de Google Play'in ters ibraz incelemesi de bir bildirimle başlar ve ikisi de kısa bir sürede kapanır: Apple'da 12 saat, Google'da 24 saat. Bu mesaj geldiğinde sunucunuz kapalı, yavaş ya da yanlış yapılandırılmışsa mağaza sizi beklemez. Elinde ne varsa onunla karar verir.

İyi haber şu: iki mağaza da mesajı ilk başarısızlıkta çöpe atmaz. Apple yeniden dener ve sorgulayabileceğiniz 180 günlük bir geçmiş tutar. Google, onaylanmamış mesajları günlerce saklayan Pub/Sub üzerinden yayınlar. Kötü haber ise yeniden deneme zamanlamasının yanıt süreleriyle örtüşmemesi ve iki akıştan birinin hiçbir kurtarma API'sine sahip olmamasıdır.

Her mağaza iade bildirimlerini nasıl iletir

Apple, App Store Server Notifications'ı doğrudan App Store Connect'te belirlediğiniz HTTPS URL'sine gönderir. Google ise sunucunuzu doğrudan çağırmaz. Real-time developer notifications'ı bir Google Cloud Pub/Sub topic'ine yayınlar ve bu topic üzerindeki aboneliğiniz bildirimleri ya uç noktanıza push eder ya da sunucunuzun pull etmesini bekler.

Apple neyi başarısızlık sayar

Apple'ın belgeleri net. 200 ile 206 arasında herhangi bir durum kodu döndürürseniz teslimat tamamlanır. 40x veya 50x döndürürseniz Apple yeniden dener. Apple diğer tüm kodları da başarısız sayar. Her deneme bir sendAttemptResult ile kaydedilir ve değerleri gerçek kesintilerin kontrol listesi gibidir: TIMED_OUT, TLS_ISSUE, CIRCULAR_REDIRECT, NO_RESPONSE, PREMATURE_CLOSE, UNSUCCESSFUL_HTTP_RESPONSE_CODE ve birkaç tane daha. TIMED_OUT için Apple'ın kendi tavsiyesi, sunucunuzun mesajları yanıt vermeden önce satır içinde işlemediğini kontrol etmektir.

Google neyi başarısızlık sayar

Push aboneliğinde, uç noktanızdan dönen başarı kodu onay yerine geçer. Pull aboneliğinde ise sunucunuz çektiği her mesajı onaylamak zorundadır, aksi halde Pub/Sub onu yeniden teslim eder. Varsayılan onay süresi 10 saniye, en fazlası 600 saniyedir. Google'ın RTDN kılavuzu tekrar etmeye değer bir kural daha ekler: bildirim yalnızca bir şeyin değiştiğini söyler, satın almanın tam durumunu öğrenmek için yine de Google Play Developer API'yi çağırırsınız.

Apple'ın yeniden deneme takvimi neden 12 saatlik süreye uymaz

Apple'ın yeniden deneme aralıkları ilk denemeden değil, bir önceki denemeden itibaren ölçülür. Bunları topladığınızda, sunucunuzun sürekli başarısız olduğu tek bir V2 bildirimi için şu zaman çizelgesi çıkar.

Apple, CONSUMPTION_REQUEST'i aldıktan sonraki 12 saat içinde yanıt vermenizi ister. Sunucunuz ilk teslimatta ve bir saat sonraki yeniden denemede kapalıysa, bir sonraki deneme ilkinden 13 saat sonra gelir. Apple, ilk kez bir yeniden denemede alınan bir isteğin yeni bir 12 saat alıp almadığını söylemez. Temkinli yorum, süreyi ilk denemeyle başlamış saymaktır. Bu da bir saatten fazla geciktirdiğiniz bir isteği yalnızca yeniden denemelerin kurtaramayacağı anlamına gelir.

Apple, HTTP 400'den sonra yeniden dener mi?

Belgelere göre evet. Apple, yeniden denemeyi tetikleyen kodlar olarak 40x ve 50x'i listeler. Mart 2026'da bir geliştirici Apple'ın forumlarında 400 yanıtlarından sonra yeniden denemelerin durmuş göründüğünü bildirdi, ardından teslimatların bir iki gün sonra yeniden başladığını yazdı ve Apple bir Feedback Assistant raporu istedi. Belgelenen davranışı kural, kendi izlemenizi ise kanıt olarak görün.

Kaçırılan App Store bildirimlerini Get Notification History ile kurtarın

Get Notification History, Apple'ın seçtiğiniz zaman aralığında sunucunuza göndermeye çalıştığı sürüm 2 bildirimlerini döndürür. Her kayıt imzalı yükün tamamını taşır, böylece onu canlı bir bildirimle aynı işleyiciye verebilirsiniz. Her kayıtta ayrıca en fazla altı girdilik bir sendAttempts dizisi bulunur: biri ilk deneme için, birer tane de beş yeniden denemenin her biri için.

• startDate ve endDate zorunludur ve startDate üretimde son 180 gün, sandbox'ta son 30 gün içinde olmalıdır.
• Yalnızca sunucunuza ulaşmamış bildirimleri ve Apple'ın hâlâ yeniden denediklerini almak için onlyFailures'ı true yapın.
• CONSUMPTION_REQUEST veya REFUND gibi tek bir notificationType'a ya da tek bir müşteri için bir transactionId'ye göre filtreleyin, ancak ikisini aynı istekte kullanmayın.
• Her çağrı en fazla 20 kayıt döndürür. hasMore true olduğu sürece paginationToken ile çağırmaya devam edin ve her seferinde aynı istek gövdesini gönderin.

İadeler için önemli bir çekince var. Apple, geçmiş kayıtlarının satın almanın şimdiki değil, bildirimin ilk gönderildiği andaki durumunu yansıttığını söyler. Yani kurtarılan bir REFUND geçmişe ait bir gerçektir. Erişimi kaldırmadan önce işlem veya abonelik durumu uç noktalarıyla güncel durumu kontrol edin.

V1 bildirimleri bu yolla kurtarılamaz

Get Notification History yalnızca sürüm 2'yi kapsar. Apple, V1 bildirimlerini önceki denemeden 6, 24 ve 48 saat sonra olmak üzere üç kez yeniden dener ve hepsi başarısız olursa yeniden oynatılacak bir geçmiş kalmaz. Hâlâ V1 kullanan her uygulamayı V2'ye taşımak için bir neden daha.

Kaçırılan Google Play iade bildirimlerini kurtarın

Google'ın güvenlik ağı Pub/Sub'ın kendisidir. Aboneliğiniz var olduğu sürece, kimsenin onaylamadığı bir mesaj saklama süresi boyunca orada kalır: varsayılan olarak 7 gün, artırırsanız 31 güne kadar. Uç noktanız geri geldiğinde teslimat sürer. İki ayar bunu sessizce boşa çıkarabilir.

• Bir dead-letter topic, belirli sayıda başarısız teslimat denemesinden sonra mesajı aboneliğinizden çıkarır. Varsayılan sayı 5'tir ve anında yeniden teslim eden varsayılan yeniden deneme politikasıyla beş deneme hızla geçebilir. Kullanıyorsanız dead-letter topic'i ikinci bir gelen kutusu gibi izleyin.
• Açık bağlantılar, etkin pull'lar veya başarılı push'lar gibi abone etkinliği olmayan bir abonelik, varsayılan olarak 31 gün sonra sona erer. Bir ay boyunca bozuk kalan bir uç nokta, içinde bekleyen her şeyle birlikte aboneliğin kendisini kaybedebilir.

İptal edilen iadelerin 30 günlük yedeği var

Zaten gerçekleşmiş iadeler için pull tabanlı yedek Voided Purchases API'dir. Son 30 günün iptal edilen satın almalarını sayfa başına en fazla 1.000 kayıtla listeler. Her uygulama için kota günde 6.000 sorgu ve herhangi bir 30 saniyelik dilimde 30 sorgudur. Tek seferlik ürünlerin yanına abonelikleri de eklemek için type 1 gönderin. Bunu her gün çalıştırmak, bildirim hattınızın kaçırdığı her iadeyi yakalar ve hak tanımlarıyla gelir rakamlarını doğru tutar.

Ters ibraz incelemelerinin yedeği yok

PendingRefundReviewNotification farklıdır. orders.reviewrefund'a iletmeniz gereken pendingRefundToken'ı taşır ve iade tercihinizi ve kullanım kanıtınızı göndermek için onu aldığınız andan itibaren 24 saatiniz vardır. Google ilk çağrınızı kaydeder, sonrakileri yok sayar. Google'ın belgeleri bekleyen incelemeleri listeleyen bir uç nokta tanımlamaz. Bu yüzden o Pub/Sub mesajı kaybolursa, o ters ibraz için kanıtınız da onunla birlikte kaybolur.

Kaçırılan bir iade bildiriminin parasal maliyeti

Zaten kesinleşmiş bir iadenin kaçırılan bildirimi size yalnızca muhasebe işi çıkarır. Onu daha sonra Voided Purchases API'de veya Get Notification History'de bulursunuz, politikanız gerektiriyorsa erişimi kaldırırsınız ve raporlarınız güncellenir. Can sıkıcı, ama ucuz.

İtiraz edilebilen iki akıştan birindeki kaçırılmış bildirim ise gerçek para kaybettirir, çünkü mağaza kanıtınız olmadan karar verir. Apple'da bu, iade kararının tüketim verileriniz olmadan alınması demektir. Google Play'de, 3 Ağustos 2026'dan sonra verilen siparişlerde, kaybedilen bir ters ibraz size satın alma fiyatından Play'in hizmet bedeli düşülmüş tutara, artı alıcının bankasının kestiği ters ibraz ücretine mal olur. Google yalnızca kendi hizmet bedelini üstlenir.

Satın almayı sunmak için harcadığınız para ise anlaşmazlık başlamadan önce zaten gitmişti.

• İşlem gücü: Alıcının zaten kullandığı her üretimin, render'ın veya model yanıtının arkasındaki GPU ve sunucu süresi.
• API çağrıları: Çalıştıkları anda faturalanan, çoğu zaman çağrı başına ücretlendirilen üçüncü taraf istekleri.
• Depolama: Alıcının oluşturduğu ve hâlâ barındırma faturanızda duran dosyalar ve medya.
• Ödemeler: O satıştan içerik üreticilerine, ortaklık pazarlamacılarına veya iş ortaklarına zaten ödenmiş gelir payları.

Bir iade gerçekleştiğinde bunların hiçbiri geri gelmez. O 12 ya da 24 saat içinde gönderdiğiniz kanıt elinizdeki tek kozdur ve kaçırılan bir bildirim onu elinizden alır.

Ayakta kalan bir kurtarma rutini

• Önce onaylayın. Ham yükü saklayın, bir başarı kodu döndürün, ardından bir kuyrukta işleyin.
• CONSUMPTION_REQUEST için her birkaç dakikada bir Apple'ın Get Notification History'sini onlyFailures ile yoklayın, böylece bir kesinti 12 saatlik sürenin yalnızca birkaç dakikasını alır.
• Her gün, tüm türler için son birkaç günü onlyFailures ile tarayan bir Get Notification History çalıştırın ve bulduklarınızı yeniden işleyin.
• Her Google Play uygulaması için her gün type 1 ile bir Voided Purchases API çağrısı yapın ve sonucu zaten kaydettiğiniz iadelerle karşılaştırın.
• Pub/Sub'da mesaj saklama süresini 7 gün veya daha fazla tutun, varsa dead-letter topic için uyarı kurun ve teslim edilmemiş mesajlar biriktiğinde uyarı alın.
• Tüm yolu üretimde de test edin. Apple'ın sandbox'ı her bildirimi yeniden deneme olmadan bir kez gönderir. Request a Test Notification ile Get Test Notification Status ise sunucunuzun tam olarak nasıl yanıt verdiğini gösterir.

RefundHalt iki mağazanın bildirimlerini sizin için alır, CONSUMPTION_REQUEST'leri ve ters ibraz incelemelerini süreleri içinde otomatik olarak yanıtlar. Böylece saati izleyen siz olmazsınız.