Bir iade üzerine işlem yapmadan önce App Store sunucu bildirimlerini doğrulayın, çünkü webhook URL'nize herkes istek gönderebilir

Webhook URL'nizi öğrenen herkes ona bir iade gönderebilir. Her App Store sunucu bildiriminin ve her Google Play Real-time developer notification'ın ardındaki rahatsız edici gerçek budur: siz doğrulayana kadar mesaj, içinde biraz JSON bulunan bir HTTPS POST'tan ibarettir. Sunucunuz bir istek REFUND dediği için bir aboneliği iptal ediyor, kredileri geri alıyor ya da bir hesabı yasaklıyorsa, bu yetkiyi bir curl komutu yazabilen herkese vermişsiniz demektir.

İki mağaza da size bir kontrol yolu sunar. Apple bildirimin kendisini imzalar, bu yüzden App Store sunucu bildirimlerini yalnızca Apple'ın kök sertifikasıyla doğrulayabilirsiniz. Google Play farklı bir yol izler. Mesaj imzalı değildir, ancak Pub/Sub teslimatı imzalı olabilir ve Google zaten her değişikliği kendi API'siyle teyit etmenizi söyler. Aşağıda her birinin neyi kanıtladığını ve iki yönden birinde hata yaptığınızda bunun neye mal olduğunu bulacaksınız.

Her mağaza gerçekte neyi imzalar

App Store sunucu bildirimleri nasıl doğrulanır

Apple'ın belgeleri signedPayload'u noktalarla ayrılmış, Base64URL ile kodlanmış üç bileşenden oluşan bir dize olarak tanımlar: bir header, bir payload ve bir signature, JSON Web Signature spesifikasyonuna göre imzalanmış. Payload'u çözmek kolaydır. Ona güvenmek ise dört kontrol gerektirir.

• Çözülmüş header'dan x5c dizisini okuyun. Apple sırayı belgeler: önce imzalama anahtarını taşıyan sertifika, ardından bir Apple ara sertifikası, ardından bir Apple kök sertifikası.
• Bu zinciri, Apple'ın PKI sitesinden kendiniz indirdiğiniz bir Apple köküne, pratikte Apple Root CA - G3'e karşı doğrulayın. Mesajın içinde gelen köke asla güvenmeyin, çünkü sahtekâr oraya istediği sertifikayı koyabilir.
• Ara sertifikanın Apple Worldwide Developer Relations uzantısı 1.2.840.113635.100.6.2.1'i taşıdığını teyit edin, ardından JWS imzasını leaf sertifikanın açık anahtarıyla doğrulayın.
• Çözülmüş veriyi uygulamanızla karşılaştırın: bundleId, production'da appAppleId ve environment. Başka bir geliştiricinin uygulamasındaki ya da production uç noktanıza ulaşan bir sandbox satın alımındaki geçerli bir Apple imzası, yine de sizin iadeniz değildir.

Ardından aynısını içerideki için tekrarlayın. data nesnesi signedTransactionInfo ve signedRenewalInfo'yu barındırır ve her biri kendi x5c zinciri olan ayrı bir JWS'dir. Zarfı doğrulayıp işlemi doğrulamadan okuyan bir REFUND işleyicisi, ortada bir açık bırakmıştır.

Kendiniz yazmak yerine Apple'ın kütüphanesini kullanın

Apple, Swift, Java, Python ve Node için App Store Server Library'yi yayımlar. Kütüphanenin SignedDataVerifier'ı kök sertifikalarınızı, bir çevrimiçi kontrol bayrağını, ortamı, bundle ID'nizi ve production için appAppleId'nizi alır. Node kaynak kodu neyi zorunlu kıldığını gösterir: zincirde tam olarak üç sertifika, Apple leaf uzantısı 1.2.840.113635.100.6.11.1 ve ara sertifika uzantısı, sertifika geçerlilik tarihleri ve eşleşen bundle ID, app ID ve ortam. Çevrimiçi kontroller açıkken, leaf ve ara sertifikaların iptal edilip edilmediğini OCSP yanıtlayıcısına da sorar.

IP izin listesi yeterli mi?

Hayır. Apple, sunucunuzun bir izin listesine ihtiyacı varsa 17.0.0.0/8 alt ağını eklemeniz gerektiğini ve bunun hem sandbox hem production için geçerli olduğunu söyler. Bu, gürültüyü azaltır. Bir mesajın gerçek olduğunu kanıtlamaz ve Apple'ın ağı sizin haberiniz olmadan değiştiği anda bozulur. Gerçek kapı olarak imza kontrolünü koruyun.

Google Play iade bildirimleri nasıl doğrulanır

Google Play, RTDN mesajlarını size ait bir Pub/Sub konusuna yayımlar ve bu konuda Pub/Sub Publisher rolüne yalnızca google-play-developer-notifications@system.gserviceaccount.com hizmet hesabı sahip olmalıdır. Aboneliğiniz mesajları daha sonra iki yoldan biriyle teslim eder ve her birinin kendi kanıtı vardır.

• Pull aboneliği: sunucunuz Pub/Sub'a kimliği doğrulanmış bir bağlantı açar ve mesajları çeker. Herkese açık bir uç nokta yoktur, dolayısıyla bir yabancının istek gönderebileceği bir şey de yoktur.
• Kimlik doğrulaması açık push aboneliği: Pub/Sub bir JSON Web Token imzalar ve onu Authorization header'ında Bearer token olarak gönderir. Google'ın kılavuzu, token'ın imzasını doğrulamanızı ve email ile audience claim'lerinin yapılandırdığınız değerlerle eşleştiğini kontrol etmenizi söyler, örnek kodu da email_verified değerinin true olmasını şart koşar. Token en fazla bir saat eski olabilir.
• Kimlik doğrulaması olmayan push aboneliği: URL'ye ulaşabilen her şey RTDN biçiminde bir mesaj gönderebilir.

Google neden API ile teyit etmenizi istiyor

Kimliği kusursuz biçimde doğrulanmış bir RTDN bile hikâyenin tamamını taşımaz. Google'ın kurulum kılavuzu, bu bildirimlerin yalnızca bir satın alma durumunun değiştiğini söylediğini ve tam durumu almak için Google Play Developer API'yi çağırmanız gerektiğini açıkça belirtir. Bir voidedPurchaseNotification için bu, herhangi bir şeyi kaldırmadan önce satın alımı Voided Purchases API'de bulmak ya da güncel durumunu çekmek anlamına gelir. API çağrısı kendi hizmet hesabınızla kimlik doğrulamasından geçer, bu yüzden verdiği yanıtı bir sahtekâr taklit edemez.

Sahte veya reddedilen bir iadenin parasal maliyeti

Güvendiğiniz sahte bir iade bildirimi size ödeme yapan bir müşteriye mal olur. Parası hâlâ sizde olan birini dışarıda bırakırsınız, o kişi bir destek talebi açar ve bazıları mağazaya gidip sisteminizin zaten vermiş gibi yaptığı iadeyi ister. Sahte bir satın alma veya yenileme ise ters yönde maliyet çıkarır: hiç var olmamış bir gelir karşılığında GPU hesaplama gücü, ücretli üçüncü taraf API çağrıları, depolama ve içerik üreticisi ödemeleri sağlarsınız.

Ters yöndeki hata daha sessizdir ve çoğu zaman daha büyüktür. Yanlış bir appAppleId, production'da kalmış bir sandbox ayarı ya da güncelliğini yitirmiş bir kök sertifika yüzünden gerçek mesajları reddeden bir doğrulayıcı, kanıtlarınızın önemli olduğu iki iade akışını da düşürür. Apple, bir CONSUMPTION_REQUEST'ten sonraki 12 saat içinde tüketim verisi ister. Google, orders.reviewrefund üzerinden bir chargeback incelemesine yanıt vermeniz için 24 saat tanır ve August 3, 2026 sonrasında verilen siparişlerde kaybedilen bir Google Play chargeback'i size, Play'in hizmet ücreti düşülmüş satın alma fiyatına ek olarak alıcının bankasının kestiği ücrete mal olur.

Bir doğrulama hatasının süreyi yutmasına izin vermeyin

• Ham isteği doğrulamadan önce saklayın, böylece reddedilen bir mesaj hiçbir zaman gerçekten kaybolmaz.
• Her doğrulama hatasında uyarı verin. Tek bir sahte mesaj gürültüdür. Tüm mesajların aynı anda başarısız olması ise sizin kendi hatanızdır.
• Apple'da reddettiklerinizi yeniden oynatabilirsiniz. Get Notification History, son 180 güne ait orijinal signedPayload'u döndürür, bu yüzden doğrulayıcıyı düzeltin ve saklanan ya da kurtarılan payload'ları yeniden ondan geçirin.
• Google'da bekleyen bir chargeback incelemesi yalnızca kendi bildiriminde yaşar, dolayısıyla yanlış yapılandırılmış bir push audience kaçırılmış bir inceleme demektir. Her değişiklikten sonra Play Console'daki Send Test Message ile test edin.

RefundHalt her iki mağazanın bildirimlerini doğrular, herhangi bir şey değişmeden önce iadeleri mağaza API'leriyle teyit eder ve CONSUMPTION_REQUEST ile chargeback incelemelerini süreleri içinde yanıtlar. Böylece sahte bir mesaj size bir müşteriye mal olamaz, gerçek bir mesaj da gözden kaçamaz.