İadeden Sonra Erişimi İptal Etmek: Apple ve Google'ın Sizin İçin Yapmadığı Adım

Bir iadeyi onaylamak ile erişimi kaldırmak birbirinden ayrı iki adımdır ve bunlardan yalnızca biri otomatik olarak gerçekleşir. İşlenmiş bir iadenin iptal edilmiş bir satın alma anlamına geldiğini varsayan geliştiriciler, her iki büyük mağazada da, farklı şekillerde ve farklı nedenlerle yanılıyor. Otomasyonun tam olarak nerede durduğunu bilmek, aylar sonra bunun hiç gerçekleşmediğini fark etmek yerine iadeden sonra erişimi gerçekten iptal etmek için gereken şeydir.

Bir iade neden varsayılan olarak erişimi iptal etmez

Apple ve Google, parayı ve erişimi iki ayrı işlem olarak ele alır. Para tarafı mağaza politikasıdır: bir iade onaylandığında bu kesindir ve kayıt güncellenir. Erişim tarafı ise isteğe bağlıdır, geliştiricinin işidir ya da her ikisidir birden, bu platforma ve satın alma türüne göre değişir. Hiçbir mağaza, iade tamamlanır tamamlanmaz erişimin ortadan kalkmasını istediğinizi varsaymaz, çünkü kısmi iade, bir jest olarak verilen kredi ya da bir destek hareketi gibi birçok meşru durumda ürünün elden hiç alınmaması gerekir.

Google Play: kimsenin fark etmediği onay kutusu

Play Console'da bir siparişi iade etmek iki parçalı bir formdur: önce iade tutarı seçilir, sonra Remove entitlement seçeneğinin işaretlenip işaretlenmeyeceğine ayrıca karar verilir. Çoğu destek temsilcisinin izlediği varsayılan yol, bu seçeneği işaretlemeden bırakmaktır, çünkü çoğu iade talebi müşterinin satın aldığı şeyi elinde tuttuğu bir iyi niyet jestidir. Sorun şu ki, iade onay ekranında hiçbir yer, bunun aynı zamanda kesin olmasını istediğiniz bir iadeden sonra müşterinin bir aboneliği veya uygulama içi ürünü elinde tutmasının yolu olduğunu söylemez.

API yolunda da aynı tuzak var

Aynı seçim kodda da mevcuttur. orders.refund uç noktası isteğe bağlı bir revoke sorgu parametresi alır; bu true olduğunda öğeye erişim hemen sonlandırılır ve tekrarlayan bir abonelik için gelecekteki tüm ödemeler de bununla birlikte iptal edilir. Parametre atlanırsa varsayılan olarak false kabul edilir: iade kaydedilir, satın alma kaydı güncellenir ve kullanıcı ürünü tamamen öncekiyle aynı şekilde kullanmaya devam eder.

İşte entegrasyonları yakalayan tam olarak o son satırdır. Voided Purchases API, Play Console'u elle sürekli kontrol etmeden bir iptal hattı kurabilmeniz için vardır, ancak yalnızca gerçekten revocation ile geçersiz kılınmış siparişleri listeler. Onay kutusu olmadan ya da revoke=true olmadan işlenen bir iade, bir hata yüzünden değil, tasarım gereği bu akışa görünmez.

voidedReason alanını okumak Bir satın alma voided olarak göründüğünde, voidedReason alanı bunun nedenini dokuz değerlik bir ölçekte belirtir: other, remorse, not_received, defective, accidental_purchase, fraud, friendly_fraud, chargeback ve unacknowledged_purchase. Bu yalnızca bir kayıt tutma meselesi değildir. Remorse ve accidental_purchase sıradan iadelerdir. Fraud, friendly_fraud ve chargeback ise düz bir iptal edip unutma yolu yerine bir dolandırıcılık inceleme kuyruğuna yönlendirilmeye değer olanlardır, çünkü aynı hesabın istatistiksel olarak tekrar etme olasılığı daha yüksektir.

Bu akışa doğrudan karşı bir şeyler inşa ediyorsanız önemli bir operasyonel ayrıntı var: purchases.voidedpurchases.list, günde 6,000 sorgu ve herhangi bir 30 saniyelik pencerede 30 sorgu ile sınırlıdır. Sıkı bir döngüde sorgulama yapan bir tasarım bu sınıra hızla ulaşır; amaçlanan desen sürekli sorgulama değil, sayfalama belirteçleriyle zamanlanmış bir çekme işlemidir.

Apple: App Store bir lisansı iptal edebilir, ama tüketilebilir bir ürünü edemez

Apple'ın App Store Server Notifications V2'si, bir iade tamamlandığı anda tüketilebilir, tüketilemeyen, otomatik yenilenen abonelik ve otomatik yenilenmeyen abonelik türlerinin tümü için bir REFUND bildirimi gönderir. Bu bildirimden sonra ne olacağı tamamen satın alma türüne bağlıdır, çünkü StoreKit'in kendi iptal mekanizması dört türden yalnızca ikisini kapsar.

Tüketilebilir ürünlerin neden istisna olduğu

Tüketilemeyen bir ürünün ya da bir aboneliğin, Apple'ın sistemlerinin kapatabileceği kalıcı bir hakkı, bir entitlement'ı vardır. Tüketilebilir bir üründe bu yoktur: bir kez kullanıldığında teslim edilmiş sayılır ve StoreKit tarafında iptal edilecek hiçbir şey kalmaz. Bir müşteri 500 coin satın alıp bunları harcadıysa ve sonra iade aldıysa, Apple'ın bakış açısından o coinler zaten yok olmuştur. Bunların hâlâ kayıtlı olduğu tek defter sizinkidir. REFUND bildirimi, eşleşen orijinal işlem kimliğini bulup bu bakiyeyi kendi kayıtlarınızdan düşmeniz için tek sinyalinizdir; Apple tarafında bunu sizin için yapacak hiçbir şey yoktur.

Neredeyse hiç kimsenin ele almadığı bildirim

REFUND_REVERSED, çoğu entegrasyonun tamamen atladığı bildirimdir, çünkü Apple'ın kendi kararını geri almasını tanımlar; bu, geliştiricilerin çoğunun ilk seferde tasarladığı bir durum değildir. Bu bildirim geldiğinde, işlem üzerindeki revocationDate yeniden null olur: Apple açısından satın alma yeniden geçerlidir. Orijinal REFUND geldiğinde sunucunuz bir entitlement'ı sildiyse, bir abonelik kaydını iptal ettiyse ya da tüketilebilir bir bakiyeyi sıfırladıysa, REFUND_REVERSED bunların hepsini geri koymanız gerektiğinin sinyalidir.

Bu boşluğu adım adım nasıl kapatırsınız

• Google Play'de, belirli bir destek durumu müşterinin erişimi elinde tutmasını gerektirmediği sürece, ister Play Console üzerinden ister API üzerinden olsun, her iade yolunda varsayılanı revoke=true olarak ayarlayın.
• purchases.voidedpurchases.list'i sıkı bir döngüyle değil, sayfalama belirteçleriyle zamanlanmış bir şekilde sorgulayın ve günde 6,000 isteğin ve 30 saniyede 30 isteğin altında kalın.
• voidedReason değeri fraud, friendly_fraud ve chargeback olanları, otomatik iptal edip kapatmak yerine bir inceleme kuyruğuna yönlendirin.
• Apple tarafında App Store Server Notifications V2'ye abone olun ve bir REFUND bildirimi ilgili öğeleri belirttiği anda tüketilemeyen ürün ve abonelik erişimini iptal edin.
• Her tüketilebilir satın alma için orijinal işlem kimliğini saklayın, böylece bir REFUND bildirimi geldiğinde manuel arama yapmadan düşülecek doğru bakiyeyi bulabilirsiniz.
• REFUND_REVERSED'ı açıkça işleyin ve her iptali kendi işlem veya sipariş kimliğine karşı kaydedin, böylece bir geri alma işlemi tam olarak neyin kaldırıldığını geri yükleyebilsin.

Bu boşluğun asıl maliyeti nedir

Bunların hiçbiri müşteriye karşı adalet meselesi değildir; para gittikten sonra ne çalışmaya devam ettiği meselesidir. API'nizi çağırmaya, veri saklamaya ve işlem gücü tüketmeye devam eden iade edilmiş bir abonelik ahlaki bir sorun değildir, bir maliyet kalemidir: zaten geliri geri verdiğiniz bir satın alma için altyapı faturasını ödemeye devam ediyorsunuzdur. Mağazalar bu maliyeti sizin için takip etmez, çünkü onların açısından para hareket eder etmez iade tamamlanmıştır. Erişim tarafı tamamen sizin kontrol etmeniz gereken bir faturadır.

RefundHalt'ın iptali sonradan akla gelen bir iş olarak değil, iade hattının bir parçası olarak ele almasının nedeni de tam olarak budur: bir REFUND olayı ve bir erişim değişikliği tek bir işlem olarak kaydedilir ve bir REFUND_REVERSED olayı, birinin müşterinin Apple'ın geri verdiği bir şeyden hâlâ dışlanmış olduğunu fark etmesini beklemek yerine durumu otomatik olarak geri yükler.