Sunucunun zaten aldığı iade neden kodunu oku, uygulamanı mı düzelteceğini yoksa müşteriye mi karşı çıkacağını sana söyler

Apple ya da Google müşterilerinden birine iade yaptığında, para genellikle sen daha bir söz hakkı bulamadan çoktan gitmiştir. Sonrasında sunucuna düşen şey bir makbuza benzer ve çoğu ekip ona bir makbuz gibi davranır. Bundan fazlasıdır. Her iade bir iade neden kodu taşır ve bu, karar verildikten sonra bile hâlâ okuyabildiğin, iadenin tek parçasıdır. Google Play sana iadenin bir ters ibraz mı, bir pişmanlık talebi mi, yoksa kendi uygulamanın hiç onaylamadığı bir satın alma mı olduğunu söyler. Apple sana iadenin uygulamanın içindeki bir şeyi suçlayıp suçlamadığını söyler. O kodu oku, iade bir raporda bir satır olmayı bırakır ve bir talimata dönüşür: şunu düzelt, şuna itiraz et ya da şunu bırak gitsin. İşte her kodun ne anlama geldiği, bunları nasıl ayıracağın ve her birinin neye mal olduğu.

İade neden kodu aslında nedir

Bir iade neden kodu, bir satın almanın neden geri alındığına dair mağazanın kendi etiketidir. Onu sen belirlemezsin ve onunla tartışamazsın. İadeye, iş işten geçtikten sonra iliştirilmiş olarak gelir ve iki mağaza onu farklı biçimlerde ve çok farklı bir çözünürlükte sunar.

Google Play her iptale bir neden ve bir kaynak damgalar

Google Play'in Voided Purchases API'si, geri alınan her satın alma için bir kayıt döndürür ve her kayıt önemli olan iki tam sayı taşır. voidedReason satın almanın neden iptal edildiğini söyler. voidedSource onu kimin harekete geçirdiğini söyler. İkisi birlikte çıplak bir iadeyi bir cümleye dönüştürür: bu sipariş bir ters ibraz nedeniyle, Google tarafından başlatılarak iptal edildi ya da pişmanlık olarak, kullanıcı tarafından başlatılarak iptal edildi. Bunları API'yi yoklayarak ya da bir iptal düştüğünde tetiklenen gerçek zamanlı geliştirici bildirimine abone olarak okursun. Her iki durumda da, saklamaya değer yük bu iki sayıdır.

Apple sana daha dar ama keskin bir sinyal verir

Apple sana dokuz yönlü bir neden vermez. İadesi yapılmış bir işlemde Apple, revocationReason'ı iki değerden birine ayarlar. Bir 1, App Store'un işlemi uygulamanın içindeki gerçek ya da algılanan bir sorun nedeniyle iade ettiği anlamına gelir. Bir 0, örneğin kazara bir satın alma gibi başka bir nedenle iade ettiği anlamına gelir. Bu alan yalnızca iadesi yapılmış ya da geri alınmış işlemlerde, bir revocationDate ile birlikte, REFUND App Store Server Notification'ın imzalı işlem bilgisi içinde görünür. İki değer çok değildir, ama önemli olanı, bir 1, Apple'ın sana iadenin müşterinin fikir değiştirmesiyle değil, ürününle ilgili olduğunu söylemesidir.

Google Play'in sana verdiği dokuz neden

Google'ın voidedReason'ı ikisinin daha zengin olanıdır ve her değer, her biri farklı bir yeri işaret ettiği için görür görmez bilmeye değer. İşte doğrudan VoidedPurchase kaynağından alınmış tam liste ve her kodun sana aslında ne yapmanı söylediği.

voidedSource sana tetiği kimin çektiğini söyler

Nedenin yanında voidedSource durur ve farklı bir soruyu yanıtlar: bunu kim geri aldı. Bir 0, bunu kullanıcının, self servis ya da bir banka aracılığıyla yaptığı anlamına gelir. Bir 1, bunu geliştiricinin, yani sen ya da kendi araçlarının bir iade yayınlayarak yaptığı anlamına gelir. Bir 2, bunu Google'ın kendi kararıyla yaptığı anlamına gelir; onaylanmamış bir satın alma için yapılan otomatik iade de buna dahildir. Bir iptal artışı gördüğünde, ilk ayrım kaynaktır. Bir source 2 duvarı, Google'ın hesabın üzerinde harekete geçmesidir ve bu genellikle müşterilerinden çok entegrasyonuna geri işaret eden bir sinyaldir.

Her iadeyi düzelt, itiraz et ya da kabul et olarak ayır

Bir kodun işe yarama nedeni, bir iadenin üç yanıttan hangisini hak ettiğini sana söylemesidir. Çoğu ekip bütün iadelere aynı davranır ve asla kazanamayacakları iadeler için çaba yakar. Kodlar tertemiz ayrılır.

Düzelt: ürününün yol açtığı iadeler

Bazı kodlar, iade kılığına girmiş hata raporlarıdır. Google'da kusurlu (3) ve teslim alınmadı (2) ile Apple'da 1 olan bir revocationReason, hepsi aynı şeyi söyler: müşteri ödedi ve uygulaman teslim etmedi. Onaylanmamış satın alma (8) bunların en keskinidir, çünkü kabahat tümüyle senin faturalandırma kodundadır. Bunlar ortadan kaldırılması en ucuz iadelerdir, çünkü onları birini ikna ederek değil, kendine ait bir şeyi düzelterek ortadan kaldırırsın. Bu yığında artan bir sayı, üzerinde bir para tutarı asılı duran bir ürün kusurudur.

İtiraz Et: birinin üzerinde çalıştığı iadeler

Dolandırıcılık (5), dost dolandırıcılığı (6) ve ters ibraz (7) uyuşmazlıklardır. Saf dolandırıcılık (5) senin müşterin değildir ve zaten hiç elinde tutamayacağın bir gelirdir. Dost dolandırıcılığı (6), alıcının ödediği şeyin tam olarak aynısını alıp sonra itiraz ettiği durumdur ve kanıtının hâlâ kıpırdatabildiği tek uyuşmazlıktır; ters ibraz (7) ise o kanıtın sunulduğu yerdir. Bunlardan biri düştüğünde, henüz yapmadıysan erişimi geri alırsın ve bir inceleme penceresi açık olduğunda ona, hesap hakkında bildiklerinle yanıt verirsin.

Kabul Et: durdurmanın hiçbir zaman senin elinde olmadığı iadeler

Pişmanlık (1) ve kazara satın alma (4), müşterinin kendi fikir değişikliğidir. Apple'ın 0 olan revocationReason'ı da buraya oturur. Hiçbir özellik başarısız olmadı ve hiçbir dolandırıcılık gerçekleşmedi. Kazara yığınını daha net bir satın alma onayıyla yumuşatabilirsin, ama bir pişmanlık iadesini tartışarak savuşturamazsın ve bunu denemeye harcanan zaman, paranın gerçekten olduğu düzeltme yığınından alınan zamandır.

Neden kodlarını kaybetmeyi kolaylaştıran 30 günlük tuzak

Google tarafında, bunu bir raporlama özelliğinden bir son tarihe çeviren katı bir sınır var. Kodları sürekli yakalamıyorsan, onları kaybediyorsun.

Voided Purchases API yalnızca 30 gün geriye bakar

Google, API'nin yalnızca son 30 günün iptal edilmiş satın almalarını gösterebildiğini açıkça belirtir. Daha eski iptaller, hangi startTime'ı geçersen geç döndürülmez ve startTime değerinin kendisi de 30 günden daha eskiye ayarlanamaz. Saf bir entegrasyon için daha kötüsü, 30 günlük pencerenin, satın almanın ne zaman yapıldığına ya da kayıttaki voidedTimeMillis'e göre değil, Google'ın sistemlerinin bir satın almayı ne zaman iptal edilmiş olarak gördüğüne göre ölçülmesidir. Yani o pencere içinde çekmediğin bir iade neden kodu gitmiştir ve herhangi bir boşluğu olan aylık bir dışa aktarma işi, yakalamakta fazla yavaş kaldığı iptalleri sessizce düşürür.

Neden kodları parasal olarak ne değer taşır

İki kod belirli bir fiyat taşır ve onları okumak, aksi takdirde toplu bir iade oranının içinde gizlenen sorunlara bir sayı koymanın yoludur.

Bir kod, kendine kestiğin bir faturadır

voidedReason 8, onaylanmamış satın alma, yol açtığın bir iadenin en temiz örneğidir. Google Play, uygulamanın hak tanımasının ardından üç gün içinde bir satın almayı onaylamasını gerektirir ve bunu yapmazsan Google siparişi otomatik olarak iade eder ve öğeyi geri alır. 8 damgalı her iptal, ürünü isteyen bir müşteriden gelen gerçek bir satıştır ve satın almayı onaylayacak bir çağrı hiç tetiklenmediği için geri verilmiştir. Kaybedilen tutar, tam satış fiyatına ek olarak, onu teslim etmek için çoktan harcadığın hesaplama, API çağrıları ve depolamadır. Bu, pazarlık ettiğin bir iade değildir. Kapattığın bir hatadır ve kod, onu bulma yoludur.

Ters ibraz kodu artık bir ücret taşıyor

voidedReason 7, ters ibraz, August 3, 2026 tarihinde maliyet değiştirdi. O tarihte ya da sonrasında verilen Google Play siparişlerinde, kaybedilen bir ters ibraz geliştiriciye satın alma fiyatından Play'in hizmet ücreti düşüldükten sonraki tutara ek olarak bankanın ters ibraz ücretine mal olur, Google ise yalnızca kendi hizmet ücretini karşılar. Ters ibraz ücretleri sabit, ürün fiyatları ise değişken olduğundan, ucuz bir uygulama içi satın almada tek başına ücret, müşterinin ödediğini aşabilir. Kod 7 iptallerini saymak artık yalnızca kaybedilen bir satışı değil, bir gider kalemini saymaktır; ters ibraz yığınının, oluşturduğun herhangi bir iade raporunda kendi satırını hak etmesinin nedeni tam da budur.

Apple ve Google nasıl hizalanır

İki mağaza aynı soruyu farklı çözünürlüklerde yanıtlar, bu yüzden mağazalar arası bir iade raporu, eşleşmelerini beklemek yerine onları normalleştirmek zorundadır.

Mağazalar aynı iade için sana asla aynı kodu vermeyecek ve bu sorun değil. Önemli olan, her ikisinin de sana makine tarafından okunabilir bir neden vermesi ve her ikisinin de onu okuyan bir ekibi ödüllendirmesidir. Apple'ın tek biti, bir iadenin ne zaman ürününün kusuru olduğunu sana söyler. Google'ın dokuz nedeni ve kaynak bayrağı, hangi ürün hatasına, hangi uyuşmazlığa ve hangi kendi kendine verilmiş faturalandırma boşluğuna baktığını söyler. Kodların hiçbiri bir iadeyi durdurmaz. Her ikisi de bir sonrakinin olmaması için ne yapman gerektiğini söyler.

RefundHalt, her iadenin neden kodunu geldiği anda, her iki mağazada da yakalar ve Google'ın 30 günlük penceresinin çok içinde tutar, böylece hiçbir şey kaçmaz. Her iptali düzelt, itiraz et ya da kabul et olarak ayırır, böylece kod 3 kusurludaki bir artış sana bir ürün uyarısı olarak ulaşır ve kod 8 onaylanmamıştaki bir artış sana, belirsiz bir gelir düşüşü olarak değil, bir entegrasyon hatası olarak ulaşır. Apple'ın CONSUMPTION_REQUEST'ine 12 saat içinde, Google Play'in ters ibraz incelemesine 24 saat içinde yanıt verir ve bir iade ya da ters ibraz düştüğü anda erişimi geri alır. Bir mağazanın bir iadeye damgaladığı kodu değiştiremezsin. Hepsini okuduğundan ve gerçekten düzeltmen gereken olanlara aksiyon aldığından emin olabilirsin.