Apple daha önce onayladığı bir iadeyi geri alabilir ve sunucunuzun görmezden geldiği geri alınmış bir iade, ödeme yapmış bir müşteriyi kilitler

Bir iade her zaman son söz değildir. App Store, müşteri itiraz ettikten sonra daha önce onayladığı bir iadeyi geri alabilir ve o geri alınmış iade sunucunuza ulaştığında tek bir talimat taşır: erişimi geri ver. Çoğu ekip yalnızca düz REFUND bildirimini bağlar, müşteriyi keser ve orada durur. Diğer yarısını hiç inşa etmezler. Böylece geri alma geldiğinde hiçbir şey çalışmaz ve yeniden ödeme yapan bir müşteri, satın aldığı şeyin dışında kilitli kalır. İade bildirimlerinin tam kümesinin App Store ve Google Play üzerinde nasıl çalıştığı ve her birini görmezden geldiğinizde size neye mal olduğu burada.

App Store bir değil, üç iade bildirimi gönderir

Çoğu iade işleme tek bir olay için inşa edilmiştir: para geri gitti, müşteriyi kes. App Store Server Notifications V2 akışı aslında üç ayrı iade sonucu taşır ve üç farklı şey ister. Bunlardan ikisi bir müşterinin neye erişebileceğini değiştirir. Biri ilkini geri alır. İşte tam küme, Apple'ın kendi sözleriyle.

REFUND, her ekibin işlediği bildirim

App Store bir iadeyi işlediğinde, yapılandırdığınız URL'ye bir REFUND bildirimi gönderir ve Apple'ın tanımı açıktır: 'App Store'un tüketilebilir bir In-App Purchase, tüketilemez bir In-App Purchase, otomatik yenilenen bir abonelik veya yenilenmeyen bir abonelik için bir işlemi başarıyla iade ettiğini gösterir.' İade edilen işlemi saklarsınız, satın aldığı her şeyin yetkisini iptal edersiniz ve Apple, uygulamadaki bağlamsal mesajlarla müşteriye neyin değiştiğini bildirmenizi ister. Bu, herkesin ilk bağladığı ve çoğu zaman tek bağladığı bildirimdir.

REFUND_DECLINED, sizden hiçbir şey istemeyen bildirim

REFUND_DECLINED tam olarak söylediği şey anlamına gelir: 'App Store bir iade talebini reddetti.' Müşteri istedi, Apple hayır dedi ve işlem geçerli kalır. Müşterinin erişimiyle ilgili hiçbir şey değişmez, dolayısıyla yetki mantığınız burada hiçbir şey yapmaz. Bu bildirimin değeri kayıt tutmaktır. Bir CONSUMPTION_REQUEST ile yanıtlamış olabileceğiniz bir iade talebinin döngüsünü kapatır ve müşterinin hâlâ ödediği şeye sahip olduğunu doğrular. Bunu bir eylem değil, bir kayıt olarak ele alın.

REFUND_REVERSED, ekipleri gafil avlayan bildirim

Bu, çoğu iade hattının hiç işlemediği bildirimdir. Apple'ın tanımı nettir: REFUND_REVERSED 'müşterinin başlattığı bir itiraz nedeniyle App Store'un daha önce onaylanmış bir iadeyi geri aldığını gösterir. İlgili iade sonucunda uygulamanız içerik veya hizmetleri iptal ettiyse, bunları yeniden vermesi gerekir.' Bunu iki kez okuyun. Apple müşteriye bir iade verdi, siz erişimi iptal ettiniz, sonra Apple iadenin geçerli olmaması gerektiğine karar verip geri çekti. Ücret yeniden aktif. Müşteri ödedi ve sunucunuz yalnızca iptal etmeyi biliyorsa, hâlâ kilitli kalır. Geri alınmış bir iade, erişimi yeniden ekleyen tek iade olayıdır ve neredeyse hiç kimsenin öngörmediği olaydır.

Geri alınmış bir iade size gerçekte neye mal olur

Kaçırılan bir geri alma bir yuvarlama hatası değildir. Parayı her iki yönde de takip edin, çünkü iki yarıdan birini yanlış yapmanın bir bedeli var.

Geri almayı kaçırırsanız ödeme yapan bir müşteriyi kilitli tutarsınız. Apple ücreti yeniden uyguladı, dolayısıyla müşteri yine cebinden çıkmış durumda ve uygulamanız ona satın aldığı şeyi reddediyor. Anlık maliyet, destek süresi ve şimdi kendinizin verebileceği bir iyi niyet iadesidir, bu kez onu yumuşatmak için mağazadan geri gelen bir komisyon yok. Daha yavaş maliyet, yorum ve müşteri kaybıdır ve Google Play'de aynı kilitlenme hayal kırıklığı tam olarak bir ters ibraza dönüşen şeydir.

Orijinal iadeyi kaçırırsanız hiçbir şey ödememiş bir müşteriye hizmet vermeye devam edersiniz. Ayna hatası hiç iptal etmemektir. Hâlâ görüntü üreten, API'lerinizi çağıran ve depolamanızı dolduran iade edilmiş bir müşteri, geri alınmış bir satışa karşılık gerçek maliyet biriktirir. İşlem gücü, üçüncü taraf çağrıları ve depolama zaten harcadığınız paradır ve bunların hiçbiri iade ile geri gelmez.

• Destek maliyeti: kendi kodunuzun kaldırdığı ve hiç geri vermediği bir erişim için bir talebi yanıtlayan bir insan.
• İyi niyet iadeleri: yanlışlıkla kilitlediğiniz bir müşteriye para geri vermek, manuel bir jestte mağazadan geri gelen hiçbir komisyon olmadan.
• Boşa giden harcama: hiç kesmediğiniz iade edilmiş bir hesabın tükettiği işlem gücü, API çağrıları ve depolama.
• Ters ibraz riski: Google Play'de, iki kez ücret alındığını hisseden bir müşteri itiraz edebilir ve kaybedilen bir itiraz artık size düşer.

Geri alınmış iade ve düz iade, zıt yönlere işaret eden aynı webhook akışıdır. Birini işleyip diğerini atlarsınız ve her iki uçtan da ödersiniz.

Apple bir iadeyi neden geri alır ve revocationReason nasıl okunur

Bir geri alma rastgele değildir. Apple bunu 'müşterinin başlattığı bir itiraza' bağlar, yani müşterinin iade kararını sonradan sorgulamasıdır. İade ilk onaylandığında, işlem bir revocationDate ve bir revocationReason taşıyordu ve aşağı akıştaki herhangi bir şey onun üzerinde işlem yapmadan önce o nedeni okumaya değer.

• revocationReason 1: App Store 'uygulamanızdaki gerçek veya algılanan bir sorun nedeniyle' iade etti. Bu yalnızca bu müşteri hakkında değil, ürününüz hakkında bir sinyaldir.
• revocationReason 0: App Store 'başka nedenlerle, örneğin yanlışlıkla yapılan bir satın alma nedeniyle' iade etti. İlişkili herhangi bir uygulama kalitesi sinyali yok.

O işlem için bir REFUND_REVERSED geldiğinde, iptal geri alınıyor demektir. Yeniden verme mantığınız orijinal işlem id'sini aramalı, iptal ettiğinizi doğrulamalı ve yetkiyi tam olarak eski hâliyle geri koymalıdır.

Google Play bir geri alma göndermez, bunun yerine mutabakat yaparsınız

Google Play'in modeli farklıdır ve her iki mağazayı tek bir webhook işleyicisi üzerinden yönetiyorsanız fark önemlidir. REFUND_REVERSED'ın Google karşılığı yoktur. Google'ın gerçek zamanlı geliştirici bildirimleri iade olaylarını iki mesaja böler ve geri almalar bir push ile değil, mutabakatla işlenir.

İptal edilmiş satın alma bildirimi

Bir Google Play satın alması iptal edildiğinde, sunucunuz bir VoidedPurchaseNotification alır. purchaseToken ve orderId'yi, subscription veya one-time olan bir productType'ı ve ya tam bir iptal ya da çok adetli satın almalarda adet bazlı kısmi bir iade olan bir refundType'ı belirtir. Google, o verinin doğru satın almayı bulmak ve yetkiyi ayarlamak için yeterli olduğunu söyler. Daha fazlası için sizi, sorguladığınız bir zaman damgası aralığındaki iptal edilmiş siparişleri listeleyen bir çekme modeli olan Voided Purchases API'ye yönlendirir.

Ters ibraz incelemesi ve 24 saatlik zamanlayıcısı

Ters ibrazlar farklı bir mesajla gelir, PendingRefundReviewNotification. Bir müşteri bankasıyla bir ücrete itiraz ettiğinde, Google Play bu bildirimi gönderir ve bir zamanlayıcı başlatır. Bir iade tercihi ve varsa kullanım kanıtıyla orders.reviewrefund çağrısını yapmak için 24 hours süreniz vardır, böylece Google sizin adınıza gayrimeşru bir ters ibraza itiraz edebilir. Google ilk çağrınızı kaydeder ve gerisini yok sayar. Bu, Google'ın Apple'ın CONSUMPTION_REQUEST'ine paralelidir, bir itirazda sizin tarafınızın sayıldığı tek penceredir.

Bir geri alma push'u olmadığı için, Google'ın itiraz edip kazandığı bir ters ibraz, düzenli bir yeniden verme olayı olarak gelmez. Bunu Voided Purchases API ve kendi kayıtlarınıza karşı mutabakat yaparsınız. Ders, App Store'daki ile aynıdır: iptal edilmiş bir sipariş her zaman kalıcı değildir ve yetki durumunuz yalnızca ileri değil, geri de gidebilmelidir.

Kimseyi kilitlemeden her iade bildirimi nasıl işlenir

Mağaza başına ayrı hatlara ihtiyacınız yok. Bir yetkiyi her iki yönde de hareket ettirebilen ve her mesajı muhtemelen yinelenmiş olarak ele alan bir işleyiciye ihtiyacınız var.

• Yalnızca iptali değil, yeniden vermeyi de inşa edin. Bir REFUND'da erişimi kaldıran her yol için, bir REFUND_REVERSED'da onu geri getiren tersini yazın, aynı işlem id'sine bağlı olarak.
• İdempotent yapın. Her iki mağaza da aynı bildirimi birden fazla kez teslim edebilir, bu yüzden her iptali ve yeniden vermeyi işlem veya sipariş id'sine bağlayın ve bir tekrarın hiçbir etki yaratmamasını sağlayın.
• Harekete geçmeden önce nedeni okuyun. Bir uygulama kalitesi iadesini yanlışlıkla yapılan bir iadeden ayırmak için revocationReason'ı kullanın ve uygulama kalitesiyle ilgili olanları ürün kalitesinden sorumlu kişiye yönlendirin.
• Kanıt pencerelerini zamanında yanıtlayın. Apple'ın tüketim verisini bir CONSUMPTION_REQUEST'ten sonra 12 hours içinde gönderin ve bir PendingRefundReviewNotification'dan sonra 24 hours içinde orders.reviewrefund çağrısını yapın.
• Her olayı saklayın. REFUND_DECLINED'ı ve ham bildirimleri saklayın, böylece daha sonra gelen bir geri alma, geri aldığı iade ile eşleştirilebilir.

Bunların hiçbiri bir iadenin gerçekleşip gerçekleşmeyeceğini değiştirmez. Geri alınmış bir iadenin diğer tarafındaki müşterinin, sunucunuzun bunu yanlış yaptığını fark edip etmeyeceğini değiştirir.