Hem Apple hem de Google aynı iadeyi sunucunuza birden fazla kez teslim edebilir ve her birine göre işlem yaparsanız yinelenen iade bildirimleri size pahalıya patlar

Sunucunuz aynı iade olayını birden fazla kez alacak ve her iki mağaza da bunu bilerek böyle tasarladı. Uç noktanız düzgün yanıt vermediğinde Apple bir App Store Server Notification bildirimini beş kereye kadar yeniden dener. Google Play, Real-time Developer Notifications bildirimlerini, en az bir kez teslimat vaat eden ve sıralama hakkında hiçbir şey vaat etmeyen Cloud Pub/Sub üzerinden teslim eder. Yani soru asla bir yinelemenin gelip gelmeyeceği değildir. Aynı iadeyi ikinci kez gördüğünde kodunuzun ne yaptığıdır. Bunu yanlış yapın, bakiyeyi iki kez düşürürsünüz, bir ödemeyi iki kez geri alırsınız ya da zaten kapattığınız bir iadeyi yeniden kontrol ederek ücretli API kotasını harcarsınız. Yinelenen iade bildirimlerinin size gerçekte nasıl ulaştığı, hangi tekrarların gerçek yineleme olduğu ve hangilerinin yalnızca öyle göründüğü ve ikinci teslimatın bedava olması için bunları nasıl ele alacağınız burada.

Bir iade bildirimi en az bir kez teslim edilir, bu tam olarak bir kez ile aynı şey değildir

Her iki mağaza da teslim edilmiş bir bildirimi, ateşleyip unuttukları tek bir atış olarak değil, yerine getirmeye çalışmaya devam ettikleri bir söz olarak görür. Bu güvenilirlik açısından iyidir, çünkü bir dağıtım sırasında kaçırdığınız bir bildirim size daha sonra yine de ulaşır. Doğruluk açısından bir tuzaktır, çünkü olayı eninde sonunda almanızı garanti eden mekanizma, bazen onu iki kez almanızı da garanti eder. İşleyicinizin idempotent olması gerekir, yani bir iadenin ikinci ve üçüncü teslimatları, ilkinin zaten değiştirmediği hiçbir şeyi değiştirmez.

Apple üç gün boyunca beş kez yeniden dener

Apple bir App Store Server Notification V2 gönderdiğinde, sunucunuzun 200 ile 206 arasında bir HTTP durumuyla yanıt vermesini bekler. Bunun dışında herhangi bir şey, bir 4xx ya da bir 5xx, Apple'a teslimatın başarısız olduğunu söyler ve Apple yeniden dener. Program sabittir: beş yeniden deneme, önceki denemeden 1, 12, 24, 48 ve 72 saat sonra. İlk deneme dahil, bir iade olayı yaklaşık bir haftaya yayılarak altı kereye kadar gelebilir. Bu yeniden denemelerin her biri aynı notificationUUID değerini taşır. O alan sizin yineleme giderme anahtarınızdır. Bir notificationUUID değerini zaten kaydettiyseniz, elinizde tuttuğunuz teslimat bir tekrardır ve doğru yanıt yeni hiçbir şey kaydetmemek ve yine de 200 döndürmektir.

Google Play, en az bir kez vaat eden ve sıralama hakkında hiçbir şey söylemeyen Pub/Sub üzerinde çalışır

Google Play'in Real-time Developer Notifications bildirimleri bir Cloud Pub/Sub konusuna yayınlanır. Pub/Sub'ın teslimat garantisi en az bir kezdir ve hiçbir sıralama garantisi vermez. Bu, aynı mesajın uç noktanıza birden fazla kez teslim edilebileceği ve aynı satın alma için iki mesajın sırasız gelebileceği anlamına gelir. Google'ın kendi rehberliği açıktır: base64 data alanını açın, messageId değerini okuyun ve herhangi bir şeyi işlemeden önce bunu daha önce görmediğinizi kontrol edin. Yinelenen bir messageId atladığınız bir tekrardır. Tek bir satın alma hakkındaki iki farklı bildirim yine de aynı kayda inmelidir, bu yüzden saklanan durumunuzu purchaseToken üzerine de anahtarlayın ve daha sonraki bir olayın, daha erken birinin oluşturduğu satırı güncellemesine izin verin.

Yineleme olmayan tekrarlar

Gördüğünüz birine benzeyen her bildirim bir yeniden deneme değildir. İki Apple davranışı, bir satın almayı paylaşan ama her biri işlenmesi gereken gerçekten yeni olaylar gönderir ve bunları saf bir yineleme gidermeyle birleştirmek ihtiyacınız olan bilgiyi atar.

Apple yeni CONSUMPTION_REQUEST gönderir, yeniden deneme değil

Bir tüketilebilir üzerinde açık bir iade talebi sırasında Apple tek bir CONSUMPTION_REQUEST gönderip beklemez. İade kapanana kadar tüm açık iade penceresi boyunca periyodik olarak yenilerini gönderir. Apple çalışanları bunların yeniden deneme olmadığını doğruladı ve ipucu, yineleme gidermek için kullandığınız alandadır: her yeni CONSUMPTION_REQUEST farklı bir notificationUUID taşır. Yani notificationUUID üzerine anahtarlanmış bir yineleme giderme doğru şeyi otomatik olarak yapar. Gerçek yeniden denemeleri birleştirir ve her ayrı istemi korur. Yapmamanız gereken şey, işlem kimliği ve bildirim türü üzerinden yineleme gidermektir, çünkü bu ilkinden sonraki her CONSUMPTION_REQUEST bildirimini susturur ve atladıklarınızda size 12 saatlik kanıt penceresine mal olur.

Bir işlem birden fazla karar taşıyabilir

Tek bir transactionId, ömrü boyunca birden fazla iade sonucu üretebilir. Apple aynı işlem için bir REFUND_DECLINED ve ardından daha sonra bir REFUND gönderebilir ve geliştiriciler tek bir işlem kimliği için üç ya da daha fazla iade ile ilgili bildirim aldıklarını bildiriyor. Her biri kendi notificationUUID değerine sahip ayrı bir olaydır. Yineleme giderme anahtarınız işlem kimliğiyse, ikinci karar birincinin bir yinelemesi gibi görünür ve iadenin sonunda verildiğini asla öğrenemezsiniz. İşlem kimliği olayları gruplar. Onları tanımlamaz.

Bir yinelemenin size gerçekte neye mal olduğu

Bir iade bildirimi bir durum ışığı değildir. Gerçek eylemleri tetikler: erişimi iptal edersiniz, bir tüketilebilir bakiyeyi düşürürsünüz, bir içerik üreticisi ödemesini geri alırsınız, durumu onaylamak için App Store Server API ya da Play Developer API'yi çağırırsınız. Bunlardan herhangi birini bir yineleme üzerinde ikinci kez çalıştırın ve maliyet gerçektir.

Parayı takip edin. Erişimi iki kez iptal etmek zararsızdır, çünkü erişim zaten gitti. Bir bakiyeyi iki kez düşürmek zararsız değildir: bir madeni para paketi satın alıp iade eden bir kullanıcı, destek ekibinizin daha sonra elle çözmesi gereken negatif bir bakiyeye sürüklenebilir. Bir ödemeyi iki kez geri almak, zaten bir kez iade ettiğiniz parayı geri çeker ve artık bir içerik üreticisine bir özür ve bir düzeltme borçlusunuz. Ve bir mağaza API'sine karşı yeniden işlediğiniz her yineleme, Google'ın açıkça korumanız için uyardığı kotayı harcar, bu yüzden bir kesinti sırasında bir Pub/Sub yeniden teslimat patlaması, sizi tam da en az kaldırabileceğiniz gün oran sınırlamasına itebilir.

İade kanıt pencereleri Apple tarafında riski yükseltir. Saf bir yineleme giderme, Apple'ın açık iade penceresi boyunca gönderdiği tekrarlanan CONSUMPTION_REQUEST bildirimlerini susturursa, yanıt vermeniz gerekeni kaçırabilirsiniz ve 12 saat içinde yanıt vermediğiniz bir CONSUMPTION_REQUEST, Apple'ın çoğu zaman varsayılan olarak verdiği bir iadedir. Bu bir çift ücretlendirme değildir. Bu kayıp bir satış artı satın almayı teslim etmek için zaten harcadığınız işlem gücü, API çağrıları, depolama ve ödemelerdir, bunların hiçbirini iade geri getirmez.

Yinelenen iade bildirimlerini iki kez işlem yapmadan nasıl ele alırsınız

Kalıp her iki mağazada da aynıdır, farklı bir anahtarla. Teslimatı kaydedin, işlem yapmadan önce anahtarı kontrol edin, bir kez işlem yapın ve mağazaya her zaman onu aldığınızı söyleyin.

• Mağazanın teslimat kimliği üzerinden yineleme giderin, işlem üzerinden değil. Apple için notificationUUID ve Google Play için Pub/Sub messageId kullanın. Eşzamanlı bir yinelemenin iki kez işlem yapmak yerine yarışı kaybetmesi için onu benzersiz bir kısıtlamayla saklayın.
• Aşağı akış eylemini kendi koşullarında idempotent yapın. Teslimat kimliği üzerine anahtarlamak yeniden işlemeyi durdurur, ama etkiyi de öyle yazın ki iptal, düşürme ya da geri alma önce mevcut durumu kontrol etsin ve iki kez çalıştırmak güvenli olsun.
• Önce kalıcı kılın, sonra onaylayın. 200 döndürmeden ya da Pub/Sub mesajını onaylamadan önce olayı veritabanınıza yazın. Önce onaylar ve yazma başarısız olursa, mağaza mesajı teslim edilmiş sayar ve onu bir daha asla göndermez, ve artık onu tamamen kaybettiniz.
• Bir yineleme için bile her zaman bir başarı durumu döndürün. Apple için 200 ile 206 arası, Google için Pub/Sub push'a bir 200. Bir tekrarı hatayla reddetmek yalnızca mağazanın onu yeniden denemesine yol açar.
• Varlık üzerinde gruplayın, olay üzerinde tanımlayın. Sırasız teslimatların tek bir satırı güncellemesi için saklanan satın alma durumunuzu purchaseToken ya da originalTransactionId üzerine anahtarlayın, ama her notificationUUID ya da messageId değerine kendi olayı olarak davranın, çünkü bir satın alma haklı olarak birkaç tane üretir.

İade webhook'unuza güvenmeden önce kısa bir kontrol listesi

• Apple teslimatları notificationUUID üzerinden yineleme giderilir ve bir tekrar yeni hiçbir şey yazmaz ama yine de 200 döndürür.
• Google Play teslimatları, herhangi bir işlemeden önce kontrol edilen Pub/Sub messageId üzerinden yineleme giderilir.
• Satın alma durumu, sırasız olayların tek bir kayda inmesi için purchaseToken ya da originalTransactionId üzerine anahtarlanır.
• Her iade yan etkisi, iptal, düşürme ya da geri alma, birden fazla kez çalıştırmak için güvenlidir.
• İşleyiciniz olayı onaylamadan önce yazar, asla sonra değil.
• Tekrarlanan CONSUMPTION_REQUEST bildirimleri, yineleme olarak değil ayrı istemler olarak ele alınır, böylece hiçbir açık iade penceresi atlanmaz.

Kendi webhook'unuzdan bilerek bir yineleme geçirin ve ikinci kez hiçbir şeyi değiştirmediğini izleyin. Tüm test budur. İki kez vurulmaya güvenli bir iade işleyicisi, bir mağazanın onu altı kez vurmaya karar verdiği anda endişelenmeyi bırakabileceğiniz bir işleyicidir.