Hızlı olay işleme için Google Play RTDN'yi kullanın. İptal edilen siparişleri kontrol etmek ve kayıtlarınızı mutabakata getirmek için Voided Purchases API'yi kullanın. Çoğu ücretli uygulama için en güvenli seçim her ikisini de kullanmaktır.
Uygulamalar için Google Play iade savunması planlıyorsanız, bu ayrımla başlayın. Bir yol, bir şeyin değiştiğini size bildirir. Diğer yol ise sunucunuzun iptal edilen satın almaların listesini almasını ve neyi kaçırdığını kontrol etmesini sağlar.
Bu seçim tam olarak iki bildirim sistemi arasında değildir. Google Play RTDN, mesajları Cloud Pub/Sub üzerinden push eder. Voided Purchases API ise bir pull API'dir: arka uç sisteminiz onu çağırır.
Bunların hiçbiri tek başına birinin iade talep etmesini durdurmaz. Değerleri, değişiklikleri tespit etmek, siparişleri kontrol etmek ve ücretli erişimin satın alma durumuyla eşleştiğinden emin olmaktır.
Önemli çıkarımlar
Satın alma ve abonelik olaylarına hızlı bir şekilde tepki vermek için RTDN'yi kullanın.
Etkilenen siparişleri kontrol etmek için ikinci bir yol olarak iptal edilen satın alma listesini kullanın.
İptal edilen bir aboneliği iadenin kanıtı olarak değerlendirmeyin.
Her iki yolun da aynı güvenli erişim güncelleme mantığını kullanmasını sağlayın.
Bekleyen chargeback incelemesini tamamlanmış bir iptalden ayrı tutun.
Google Play RTDN nedir?
Genellikle RTDN olarak adlandırılan Google Play Real-Time Developer Notifications, satın almayla ilgili olayları bir Cloud Pub/Sub konusuna gönderir.
Arka uç sisteminiz bir mesaj alır ve bunu doğru worker'a yönlendirir. Mesaj türü önemlidir. Bir yenileme, bir iptal ve iptal edilmiş bir satın alma aynı olay değildir.
İade takibi için voidedPurchaseNotification'a yakından dikkat edin. Bu bildirim şunları içerir:
purchaseToken: olayı bir satın almayla ilişkilendirir.
orderId: etkilenen siparişi tanımlar.
productType: bir aboneliği veya tek seferlik satın almayı tanımlar.
refundType: tam bir iptali, miktara dayalı kısmi bir iadeden ayırt eder.
Google'ın RTDN referansı ve olay tanımları bu alanları ve diğer bildirim türlerini açıklar.
RTDN, bir değişiklikten kısa süre sonra işlem yapmak istediğinizde kullanışlıdır. Ancak bir mesaj, tam satın alma veritabanınız değildir. Erişimi değiştirmeden önce bunu kayıtlı verilerle eşleştirin ve gerektiğinde ilgili satın alma durumunu alın.
Abonelik iptali bir iade anlamına mı gelir?
Hayır. Bir müşteri, mevcut dönemin kalanı için ücretli erişime sahip olmayı sürdürürken gelecekteki yenilemeleri durdurabilir.
SUBSCRIPTION_CANCELED geldiğinde erişimi kaldıran bir kural oluşturmayın. Bunun yerine abonelik durumunu ve bitiş tarihini kontrol edin. Geri alma (revocation) ve süre dolumu kendi işleme mantıklarını gerektirir.
Voided Purchases API nedir?
Google Play Voided Purchases API, desteklediği kapsam dahilinde iptal edilen, iade edilen veya chargeback'e uğrayan satın almaların bir listesini döndürür.
Tek seferlik uygulama içi siparişler ve abonelikler için geçerlidir. Sunucunuz, sonuçları hangi satın almaların artık erişim sağlamaması gerektiğini kontrol etmek için kullanabilir.
Liste, sipariş kimliğini, satın alma token'ını, iptal zamanını, iptal kaynağını ve iptal nedenini içerebilir. Desteklenen miktara dayalı kısmi iadeler için iade edilen miktarı da içerebilir.
Google'ın Voided Purchases API kılavuzu 30 günlük bir geriye dönük bakış süresi belgeler. Bu, kalıcı bir iade arşivi değildir. İşlenmiş kayıtları kendi sisteminizde saklayın.
Bu API, bir worker kesintisinden, bir yönlendirme hatasından veya yerel kayıtlarınızdaki bir boşluktan sonra özellikle kullanışlıdır. Ayrıca işlediğiniz olaylara karşı rutin bir kontrol de sağlar.
RTDN ile Voided Purchases API: pratik fark
Soru | Google Play RTDN | Voided Purchases API |
Nasıl çalışır? | Google, Pub/Sub'a bir olay yayınlar. | Sunucunuz bir liste talep eder. |
Temel rolü nedir? | Satın alma durumu değişikliklerinin hızlı işlenmesi. | İptal edilen siparişlerin kontrol edilmesi ve mutabakatı. |
İadelerin dışındaki olayları da kapsıyor mu? | Evet, yenilemeler ve diğer yaşam döngüsü olayları dahil. | İptal edilen satın almalara odaklanır. |
Bir işleme boşluğundan sonra yardımcı olabilir mi? | Pub/Sub kurtarma, kurulumunuza ve saklama süresine bağlıdır. | 30 günlük pencere içinde mevcut kayıtları listeleyebilir. |
Yinelenme korumasına ihtiyaç duyar mı? | Evet. | Evet, özellikle taramalar örtüştüğünde veya RTDN ile olayları paylaştığında. |
Temel soru, hangi aracın tek başına daha iyi olduğu değildir. Her bir aracın hangi hatayı yönetmenize yardımcı olduğudur.
RTDN size hızlı bir yol sunar. API ise size bir kontrol yolu sunar. Kendi veritabanınız bunları bir araya getirmelidir.
Uygulamanız hangisini kullanmalı?
Hız önemli olduğunda RTDN'yi kullanın
Ücretli bir uygulama, bir satın alma durumu değişikliğini fark etmek için zamanlanmış bir taramayı beklemek zorunda kalmamalıdır.
Uygulamanız abonelikler, tek seferlik satın almalar ve iptal edilen siparişler için hızlı güncellemelere ihtiyaç duyduğunda RTDN'yi kullanın. Tüm mesajlara tek bir iade kuralı uygulamak yerine her olayı türüne göre yönlendirin.
Eksiksizlik önemli olduğunda API'yi kullanın
Worker'ınızın kayıtlarınıza uygulamadığı iptal edilen siparişleri bulmak için zamanlanmış API kontrollerini kullanın.
Örneğin, alıcınız bir mesajı kabul etmiş olabilir, ancak bir hata sonraki erişim güncellemesini durdurmuş olabilir. Yalnızca iletimi düzeltmek, bu yerel boşluğu düzeltmez.
Üretim ortamındaki bir iade iş akışı için her ikisini de kullanın
Çoğu ücretli uygulama için bunları birleştirin. Her iki yolun da siparişi kontrol eden ve her değişikliği güvenli bir şekilde uygulayan tek bir paylaşılan işleyiciye veri sağlamasını sağlayın.
Bu, kaçırılan bir olayın erişimi etkin bırakması riskini azaltır. Ayrıca tersi riski de azaltır: aynı iade için erişimin iki kez kaldırılması.
Google Play iadeleri adım adım nasıl tespit edilir
1. Bir satın alma defteri (ledger) tutun
Uygulama paketini, satın alma token'ını, sipariş kimliğini, ürünü, kullanıcı eşlemesini ve verilen miktarı saklayın. Bir defter, basitçe neyin satın alındığının ve bunun hangi erişimi sağladığının net bir kaydıdır.
Abonelikler için yenileme sipariş kimliklerini de saklayın. RTDN referansı, her otomatik yenilemenin yeni bir sipariş kimliğine sahip olduğunu belirtir. Tek başına bir satın alma token'ı, etkilenen her yenilemeyi tanımlamak için yeterli değildir.
2. RTDN mesajlarını güvenli hale getirin ve yönlendirin
Pub/Sub erişimini doğru şekilde yapılandırın. Push iletimi için kimliği doğrulanmış isteği doğrulayın. Pull iletimi için aboneliği kimlerin okuyabileceğini kısıtlayın.
Yavaş işlemleri çalıştırmadan önce mesajı çözümleyin, paket adını kontrol edin ve kaydedin. Test olaylarını yalnızca alıcı uç noktası üzerinden değil, tam yol üzerinden gönderin.
3. Zamanlanmış bir iptal edilen satın alma taraması çalıştırın
List yöntemini uygun kimlik bilgileri ve Play Console izinleriyle çağırın. Tüm sonuç sayfalarını takip edin.
Kolayca gözden kaçabilecek iki sorgu ayarı vardır:
type=1, hem tek seferlik satın almaları hem de abonelikleri içerir. Varsayılan değer olan 0, yalnızca tek seferlik satın almaları içerir.
includeQuantityBasedPartialRefund=true, desteklenen miktara dayalı kısmi iadeleri içerir. Varsayılan değeri false'tur.
Google'ın voidedpurchases.list yöntem referansı istek ve sayfalama alanlarını kapsar.
Taramalar arasında makul bir örtüşme kullanın ve sonuçları yinelenmelerden ayıklayın. Tarama hızını hacminize, kotalarınıza ve uygulamanızın kabul edebileceği geciktirme süresine göre seçin. Geriye dönük bakış penceresi bitmek üzereyken bunu beklemeyin.
4. Her değişikliği yalnızca bir kez uygulayın
Her iki yol da aynı iptali bildirebilir. Idempotent bir işleme mantığı kurun: aynı değişikliğin yeniden çalıştırılması sonucu değiştirmemelidir.
Daha sonraki her olayı göz ardı etmek için tek başına sipariş kimliğini kullanmayın. Çok miktarlı bir satın almada birden fazla kısmi iade olabilir. Gerçek bir sonraki iadenin kaybolmaması için işlenen düzeltmeleri ve iade edilen miktarları takip edin.
5. Sadece mesaj sayısını değil, boşluğu da izleyin
Son başarılı taramayı, tamamlanmamış sayfaları, worker hatalarını ve eşleşmeyen siparişleri takip edin. Onaylanmış bir olaydan sonra erişimin güncellenmesinin ne kadar sürdüğünü ölçün.
Daha kapsamlı raporlama için mobil uygulama iade ve chargeback takip araçları kılavuzumuza bakın.
Örnek: bir iade, iki tespit yolu
Bu varsayımsal bir iş akışıdır, bildirilen bir müşteri vakası değildir.
Bir oyuncu, 500 coin veren tek seferlik bir paket satın alır. Satın alma daha sonra tamamen iptal edilir.
RTDN bir voided-purchase mesajı gönderir. Worker'ınız siparişi bulur, kaydedilen hak tanımını kontrol eder ve yayımlanmış politikanızı bu satın almaya bağlı coinlere uygular.
Daha sonra, zamanlanmış API taraması aynı siparişi döndürür. Paylaşılan işleyici, tam iptal düzeltmesinin zaten uygulandığını görür. Eşleşmeyi kaydeder ve ikinci bir kesinti yapmaz.
Şimdi worker'ın ilk değişikliği uygulamadan önce başarısız olduğunu varsayalım. Tarama siparişi bulur ve sisteminize bunu işlemek için başka bir yol sunar.
Her ikisini de kullanmanın amacı budur. İki ayrı ceza değil, aynı doğru sonuca ulaşmanın iki yolu.
Eğer bazı coinler zaten harcanmışsa, ilgisiz ücretli bir paketten gözü kapalı coin kaldırmayın. Net bir politika kullanın, işlemi açıklayın ve bir destek yolu sağlayın.
Bekleyen iade incelemesi ayrı bir iş akışıdır
Güncel Google belgeleri, geliştirici incelemesi gerektiren bir chargeback talebi için pendingRefundReviewNotification'ı da listeler.
Bu olay için Google, 24 saat içinde orders.reviewrefund aracılığıyla bir iade önerisi ve satın alma kullanım kanıtı sağlamanızı belirtir.
Bunu voidedPurchaseNotification ile karıştırmayın. Biri bekleyen bir incelemeyle ilgilidir. Diğeri, iptal edilmiş bir satın almayı bildirir.
Voided Purchases API, bekleyen bir inceleme olayını işlemenin yerini tutmaz. Bu dalı ayrı tutun ve her iade talebinin bunu oluşturduğunu varsaymayın.
App Store iadeleri ve gelir kaçağı: geliştiricilerin bilmesi gerekenler
Gelir kaçağı, bir mağazanın para iade edip etmemesiyle sınırlı değildir. Ayrıca arka uç sisteminizin, ilgili satın alma bunu artık desteklemediği halde ücretli erişimi vermeyi sürdürmesi anlamına da gelebilir.
Her iki platformda da çalışan ekipler için hedef benzerdir: parayı, satın alma durumunu ve erişim kayıtlarını uyumlu tutmak. Ancak mağaza araçları ve olay kuralları farklıdır. Bir Apple iş akışını değiştirmeden Google Play'e kopyalamayın.
Bu App Store iade gelir yönetimi kılavuzu daha geniş gelir yönetimi sorununu kapsar. Bu Google Play entegrasyonu için önce kaçırılan iptalleri, yinelenen kesintileri ve yanlış abonelik erişim değişikliklerine odaklanın.
Google Play iade dolandırıcılığı önleme neyi yapabilir, neyi yapamaz
Google Play iade dolandırıcılığı önleme, sağlam kayıtlar ve adil kurallarla başlar. İptal edilen bir sipariş, müşterinin dürüst olmayan bir şekilde davrandığının kanıtı değildir.
Bir kullanıcının geçerli bir şikayeti olabilir. Bir ödeme başarısız olabilir. Uygulamanız yanlış öğeyi teslim etmiş olabilir.
Bu araçları gerçekleri kontrol etmek ve erişim değişikliklerini uygulamak için kullanın. Tekrarlanan kalıpları bağlam içinde inceleyin. Tek bir iadeye dayalı otomatik hesap yasaklamalarından kaçının ve müşterilerin hatalara itiraz etmesine izin verin.
Ne RTDN ne de list API, bir iadeyi önleyebileceğinizi, reddedebileceğinizi veya geri alabileceğinizi garanti etmez.
Sonuç
RTDN ile Voided Purchases API arasındaki seçim, çoğu ücretli uygulama için ya biri ya diğeri şeklinde bir karar değildir.
Hızlı tepki vermek için RTDN'yi kullanın. Kayıtları mutabakata getirmek için zamanlanmış iptal edilen satın alma kontrollerini kullanın. Her ikisini de tek bir güvenli işleyici üzerinden gönderin ve bekleyen incelemeleri tamamlanmış iptallerden ayrı tutun.
Küçük bir testle başlayın: bir iptali her iki yol üzerinden de gönderin ve erişimin yalnızca bir kez değiştiğini doğrulayın. Ardından worker'ınızı durdurun ve kurtarma yolunuzun boşluğu yakaladığını kontrol edin.
Sık sorulan sorular
RTDN, olayları hızlı şekilde işlemek için daha uygundur. API ise iptal edilen siparişlerin zamanlanmış kontrolleri için daha uygundur. Çoğu ücretli uygulama her ikisinden de yararlanır.
Evet. Sipariş ve iade türü ayrıntılarını içeren bir voided-purchase (iptal edilen satın alma) bildirimi sunar. Bu olayı bir abonelik iptalinden ayrı olarak işleyin.
Polling (yoklama) yoluyla mevcut iptal edilmiş kayıtları tespit edebilirsiniz, ancak tespit işlemi bir sonraki başarılı taramanızı bekler. Ayrıca RTDN'nin daha kapsamlı yaşam döngüsü olay akışını da kaçırırsınız.
Google 30 günlük bir pencere belgeliyor. Daha uzun vadeli kontroller ve destek ihtiyaçları için kendi kayıtlarınızı tutun.
Evet. List isteklerinde desteklenen kısmi iade sonuçlarını etkinleştirin. İade edilen miktarları takip edin ve bir sipariş üzerinde birden fazla kısmi iade olabileceğini hesaba katın.
