Bir müşterinin tüm App Store iade geçmişini döndüren tek bir uç nokta var ve işte size verdiği şey

Apple, uygulamanız için bir müşterinin hesabında onayladığı her iadenin sorgulanabilir bir kaydını tutar ve tek bir çağrı bunu döndürür. Bu uç nokta, App Store Server API'nin bir parçası olan Get Refund History'dir ve o müşterinin tüm App Store iade geçmişini imzalı işlemlerin bir listesi olarak size verir. Bir işlem kimliği iletirsiniz, Apple'ın neyi iade ettiğini geri alırsınız ve hâlâ açık tuttuğunuz şeyle bunu mutabık kılarsınız.

İşte neden zahmete değer. Hiç görmediğiniz bir iade, ödemeye devam ettiğiniz bir iadedir. Para çoktan gitti, ama hesap açık kalıyor ve açık kaldığı her saat işlem gücü, model API çağrıları, depolama ve o müşteriye bağlı her ödeme için harcamaya devam edersiniz. İade bildirimleriniz bunu tam olduğu anda yakalamak içindir. Get Refund History, bunu yakalayamadıklarında devreye giren yedeğinizdir: bir kesintiden, bir webhook'u düşüren bir dağıtımdan ya da tüm tabloya tek bir çağrıda ihtiyaç duyduğunuz bir destek vakasından sonra.

App Store iade geçmişi uç noktasının döndürdüğü şey

App Store Server API'ye karşı GET /inApps/v2/refund/lookup/{transactionId} çağrısı yaparsınız; buna yaptığınız her diğer çağrıda kullandığınız aynı JWT ile imzalanır. Yoldaki işlem kimliği, o müşteriye ait herhangi bir işlem olabilir. Apple bunu bir filtre olarak değil bir kimlik olarak okur ve o müşterinin iade edilmiş satın alımlarını uygulamanızın tamamında döndürür: tüketilebilir, tüketilemez, otomatik yenilenen ve yenilenmeyen abonelikler, hepsi. Bu uç noktanın daha eski V1 sürümü tek bir yanıtta en fazla 50 iade döndürüyordu ve kullanımdan kaldırıldı. Mevcut sürüm sayfalama yapar; böylece uzun geçmişi olan müşterileri devasa bir yük olmadan idare edersiniz.

Yanıt üç alandan oluşur

İade edilmiş bir işlemin size söylediği şey

signedTransactions içindeki her giriş bir JWS'tir. Apple'ın sertifika zincirine karşı doğrulayın, çözümleyin ve iade alanları doldurulmuş sıradan bir işlem yükünüz olur. Burada önemli olanlar bunlardır.

Tüm listeyi tekrar tekrar okumayı revision belirteci ile bırakırsınız

Bu uç noktayı kullanmanın saf yolu, bir müşteriyi arayıp her seferinde her sayfayı dolaşmaktır. Bu işe yarar ve elli iadesi olan bir müşteride bu, zaten bildiğiniz elli satır artı yeni olan tek satırdır. revision belirteci, bu israfı ortadan kaldırmak için vardır. Her yanıt bir revision taşır. hasMore doğru olduğunda, sonraki sayfayı almak için onu geri iletirsiniz. Sona ulaştığınızda gördüğünüz son revision'ı saklarsınız.

Bu uç noktanın yapmayacağı şey

Üzerine inşa etmeden önce bırakmanız gereken bir beklenti var. Get Refund History uygulama başına değil, müşteri başına çalışır. Ondan uygulamanızın geçen hafta aldığı her iadeyi isteyemezsiniz. Tek bir soruyu yanıtlar: bu hesabın hangi iadeleri var; ve sormak için o hesaba ait bir işlem kimliğiyle gelmeniz gerekir. Geliştiriciler sürekli bu duvara toslar ve var olmayan bir uygulama geneli iade uç noktası aramaya gider.

Uygulama genelindeki görünüm başka bir yerde yaşar. App Store Server Notifications akışınız, Apple her birini onayladığı anda bir REFUND bildirimi gönderir ve Get Notification History o akışı bir tarih aralığında iade türlerine filtrelenmiş olarak yeniden oynatmanızı sağlar. Yani ayrım net. Bildirimler ve geçmişleri size uygulama geneli akışı verir. Get Refund History ise size tek bir hesabın yetkili listesini talep üzerine verir; bir destek masasında ya da bir kesintiden sonra istediğiniz de tam budur.

Kaçırılan bir iadenin size parasal maliyeti

Uç nokta tesisattır. Fatura ise boruyu döşemenizin nedenidir. O listedeki her iade zaten geri verilmiş paradır ve kontrolünüzde kalan tek değişken, artık ödeme yapmayan bir hesap için ne kadar süre harcamaya devam edeceğinizdir.

İade edilmiş bir hesaba hizmet vermek için ödemeye devam edersiniz

Satın alma bedeli, Apple iadeyi onayladığı anda gider. Çalışmaya devam eden şey, teslimatın maliyetidir. Kullanıcı başına gerçek iş yapan bir uygulama için bu; işlem gücü, model API çağrıları, depolama ve kullanımlarına bağlı her içerik üreticisi veya iş ortağı ödemesidir. Erişimini hiç kesmediğiniz iade edilmiş bir müşteri, cebinizden finanse ettiğiniz bir aboneliktir. Get Refund History ile mutabakat yapıp bulduğunuz şey üzerinde iptal etmek, bir bildirim kaçtığında o sayacı kapatma yolunuzdur.

İade nedeni 1, kılık değiştirmiş bir kusur raporudur

revocationReason'ı görmezden gelirseniz size iki kez maliyet çıkarır. İlk maliyet iadenin kendisidir. İkincisi ise aynı nedenden kaynaklanan her gelecekteki iadedir. Bir ürün sürekli revocationReason 1 ile, yani uygulamanızdaki gerçek veya algılanan bir sorunla geri geldiğinde, Apple size müşterilerin paralarını geri istemesine neyin yol açtığına dair etiketli bir örnek veriyor demektir. Bunu ürün bazında eğilim olarak izleyin, o zaman sızıntıyı iade iade ödemek yerine onarabilirsiniz.

Geç yakalamak yine de hiç yakalamamaktan iyidir

Bir ters ibraz banka nezdinde kesindir ve diğer mağazada artık geliştiricinin üstlendiği bir ücret taşır. Bir App Store iadesi bu değildir. Kapanmıştır, ama yetkilendirme, öğrendiğiniz anda iptal etmeniz için sizindir. Yani bu uç nokta üzerinden günler geç bulduğunuz bir iade bile bulmaya değer. Parayı geri alamazsınız, ama arkasında hâlâ çalışan harcamayı durdurabilirsiniz.

Bunun bildirimlerle ve Google ile nasıl bağdaştığı

Parçaları tek bir sistem olarak düşünün. REFUND bildirimi, Apple karar verdikçe sunucunuza gönderilen canlı sinyaldir. Get Refund History ise tek bir müşteri için talep tabanlı doğruluk kaynağıdır; gönderim başarısız olduğunda ya da bir insanın tüm hesabı önünde görmesi gerektiğinde yaptığınız çağrıdır. Google Play tarafında biçim, farklı adlarla aynı fikirdir: bir VoidedPurchaseNotification gerçek zamanlı olarak gönderilir ve Voided Purchases API çektiğiniz listedir. Her iki mağaza da size bir akış ve bir defter verir. Hata, yalnızca akışa güvenmektir, çünkü akışlar düşer.

Bunu RefundHalt yöntemiyle kurmak

Her parça yerine oturduğunda döngü küçüktür. Bir REFUND bildirimini tetikleyici olarak alın. Get Refund History ile mutabık kılın ki düşen bir webhook iade edilmiş bir hesabı asla açık bırakmasın. Her işlemi çözümleyin, appAccountToken veya transactionId üzerinden kullanıcınıza geri anahtarlayın, revocationReason'ı okuyun ki bir kusur iadesi yalnızca arşivlenmek yerine işaretlensin ve tüm hesabı değil, tam olarak o yetkilendirmeyi iptal edin. revision belirteciyle sayfalayın ki eskilerini değil yeni iadeleri okuyun.

İşte bu, RefundHalt'ın sizin için çalıştırdığı kısımdır. İade bildirimlerini dinler, yetkili listeye ihtiyacı olduğunda Get Refund History'ye geri çekilir, her imzalı işlemi doğrular, tam o satın alımı iptal eder ve revision'ı saklar ki her geçiş yalnızca değişeni okusun. Erişimin saniyeler içinde kesilmesini ve kime, ne için ve neden iade edildiğine dair temiz bir kaydı, yoklama ile JWS doğrulamasını kendiniz kurmadan elde edersiniz.