Her App Store satın alımına bir appAccountToken ekleyin, yoksa iadeyi savunamazsınız

Bir müşteri Apple'dan iade ister, Apple sunucunuza bir CONSUMPTION_REQUEST gönderir ve o kişinin ürünü nasıl kullandığına dair gerçek verilerle yanıt vermek için on iki saatiniz vardır. Sonra bildirimi açarsınız ve onun kim olduğu hakkında hiçbir fikriniz olmadığını fark edersiniz. İşlem bir originalTransactionId ve bir ürün id'si taşır, ancak kendi veritabanınızdaki hesaba işaret eden hiçbir şey taşımaz. appAccountToken'ın kapattığı boşluk tam olarak budur ve onu satın alma anında ayarlamadıysanız, o satış için sonradan kapatamazsınız.

appAccountToken, sonuçtaki App Store işleminin sisteminizdeki tam kullanıcıya geri bir işaretçi taşımasını sağlamak için bir satın alıma eklediğiniz bir UUID'dir. Onu ayarlayın, Apple'ın o müşteri hakkında soracağı her iade sorusu kimlik ekli olarak gelir. Atlayın, tahmin yürütmek zorunda kalırsınız. İşte bu alanın ne olduğu, nasıl ayarlanacağı, uygulamanız dışında yapılan satın alımları kurtaran yeni uç nokta ve bir iade geldiğinde eksik bağlantının gerçekte size neye mal olduğu.

appAccountToken aslında nedir

appAccountToken, satın alma anında oluşturup StoreKit'e geçirdiğiniz opak bir UUID'dir. Apple onu işlemde saklar ve o satın alımın işlem bilgisinde geri döndürür, ve orada kalır. Apple'ın deyimiyle, "işlemi kendi hizmetinizdeki kullanıcının hesabıyla ilişkilendiren UUID"dir. Tek biçimlendirme kuralı, onun bir UUID olması gerektiğidir. Apple onu okumaz, neye eşlendiğini doğrulamaz ve sizin tarafınızda ne anlama geldiğini umursamaz. O, sizin kontrol ettiğiniz bir bağlantıdır.

İşlemde yaşadığı için, işlemin gittiği her yere geri gelir. Bir sunucu bildirimindeki imzalı işlem, App Store Server API'nin Get Transaction Info yanıtı ve bir abonelik zincirindeki her yenileme, onu orijinal satın alımda ayarladıysanız hepsi aynı token'ı taşır. Bir kez eklenen tek bir UUID, ilişkinin ömrü boyunca müşterinin faturalandırmasını takip eder.

Gerçek bir UUID olması gerekir, yoksa sessizce kaybolur

Apple'ın uyguladığı tek kural biçimdir. StoreKit 2 bir RFC 4122 UUID gerektirir. Birleştirilmiş bir dize, bir tamsayı id'si veya bir e-posta adresi geçirirseniz, StoreKit hata fırlatmaz. Değeri düşürür ve işlem appAccountToken nil olarak ayarlanmış şekilde geri gelir. Geliştiriciler buna sürekli takılır ve belirti her zaman aynıdır, Apple'ın kendi forumlarında "appAccountToken işlem yükünde eksik" ifadesinin bir varyantı, neredeyse her zaman geçirilen değerin geçerli bir UUID olmaması nedeniyle. Sunucu tarafında gerçek bir UUID oluşturun, onu hesaba karşı saklayın ve StoreKit'e asla başka bir şey vermeyin.

Satın alma anında nasıl ayarlanır

StoreKit 2'de bu tek bir satın alma seçeneğidir. Kullanıcı kaydolduğunda veya ilk kez ödemeye ulaştığında sunucunuzda UUID'yi oluşturun, onu hesap kaydına saklayın ve aynı değeri satın alma çağrısına geçirin.

İmza Product.PurchaseOption.appAccountToken(_ token: UUID) şeklindedir ve bir satın alım try await product.purchase(options: [.appAccountToken(token)]) gibi görünür. İşlem geri geldiğinde, App Store Server API aracılığıyla doğrulanmış veya bir sunucu bildirimiyle teslim edilmiş olarak, o UUID'yi taşır ve sunucunuz müşteriyi tek bir sorguda bulur.

Hesap başına bir kararlı token kullanın

Aynı kullanıcının her satın alımı için yeni bir token oluşturmayın. Apple, aynı zincirdeki yenilemelerde, faturalandırma yeniden denemelerinde ve yükseltmelerde token'ı döndürür, bu yüzden hesap başına kararlı bir UUID size ilk satın alımdan gelecekteki her olaya kadar temiz bir iplik verir. Satın alım başına değişen bir token o ipliği koparır ve tüm amacı boşa çıkarır. Bir hesap, bir token, o hesap her satın aldığında yeniden kullanılan.

Uygulama dışı satın alımları kurtaran uç nokta

2025'e kadar bir boşluk vardı. Bir müşteri bir teklif kodu kullanır veya doğrudan App Store'dan tanıtılan bir uygulama içi satın alım yaparsa, uygulamanız satın alma akışını asla çalıştırmazdı, dolayısıyla appAccountToken'ı ayarlayacak hiçbir yer yoktu. O işlemler anonim gelirdi ve öyle kalırdı.

WWDC 2025 bu boşluğu Set App Account Token uç noktasıyla kapattı. Sunucunuz App Store Server API'de gövdede UUID ile PUT /inApps/v1/transactions/{originalTransactionId}/appAccountToken çağırır ve Apple token'ı o işlemde ayarlar. Her ürün türü için çalışır, teklif kodu kullanımlarını ve tanıtılan satın alımları kapsar ve gönderdiğiniz değer işlemde zaten bulunan herhangi bir token'ı geçersiz kılar. Artık bir satın alımı sonradan, sunucunuzdan, uygulamanızdan hiç geçmeden ilişkilendirebilirsiniz.

Eksik bağlantının size nerede paraya mal olduğu

Token'ın amacı düzenli kayıtlar değildir. Amaç, Apple'ın geliştiriciler için tek iade sorusu olan CONSUMPTION_REQUEST'in, yalnızca hakkında olduğu müşteriyi bulabilirseniz yanıtlanabilir olmasıdır.

Bir alıcı bir tüketilebilir veya yenilenmeyen bir abonelik için iade istediğinde, Apple sunucunuza bir CONSUMPTION_REQUEST bildirimi gönderir ve Send Consumption Information ile yanıt vermeniz için size on iki saat verir. Yanıtınız o belirli müşteri hakkında verilerdir: ürünün ne kadarını tükettikleri, hesap kıdemleri, yaşam boyu harcamaları, teslimat durumları. appAccountToken bu isteğin alanlarından biridir ve daha da önemlisi, bildirimin işleminin, kullanımını tanımlamak üzere olduğunuz hesaba nasıl eşlendiğidir. Token yok, arama yok, doğru yanıt yok.

Boş bir yanıtın gerçekte neye mal olduğu

Kimliği belirlenemeyen bir iade kötü bir seçime zorlar. Tüketim isteğini hiçbir şeyle yanıtlayabilirsiniz, ki bu düşük tüketim olarak okunur ve Apple'ı ürünü yoğun kullanan müşteriler de dahil olmak üzere iadeyi onaylamaya iter. Ya da tahmin yürütebilirsiniz. Her iki durumda da, savunmaya deliliniz olan satın alımlara iade yapıyorsunuz ve onları sunmanın gerçek maliyetini zaten ödediniz.

O maliyet satış fiyatı değildir. Bir grup model API çağrısı çalıştıran, görüntü üreten, bir video dışa aktaran veya bir içerik üretici ödemesini tetikleyen bir tüketilebilir, teslim edildiği anda gerçek para harcadı. İade, müşterinin ödemesini geri verir. Sağlayıcı faturasını geri vermez. Kimliği belirlenemeyen bir müşteriyi, dosyaladıkları her iadeyle ve kim olduklarını bilmediğinize güvenen her seri iadeciyle çarpın, ve atladığınız token, hiç yazmadığınız en pahalı kod satırı haline gelir.

Aynı fikir Android'de, başka bir adla var

Google Play aynı sorunu setObfuscatedAccountId ile çözer, ki bu bir satın alıma bir hesap tanımlayıcısı ekler, böylece Google'ın orders.reviewrefund üzerinden ters ibraz incelemesi gerçek bir kullanıcıya karşı yanıtlanabilir. Farklı mağaza, farklı mekanik, aynı ders: satın alma anında kimlik ekleyin yoksa anlaşmazlığı daha sonra savunamazsınız. App Store'da o araç appAccountToken'dır ve bir UUID olması gerekir.

Token'ı yerinde tutan üç alışkanlık

• Hesap başına bir UUID oluşturun ve saklayın. Müşteri başına bir kararlı token, kaydolduklarında veya ilk ödemede oluşturulmuş, kaydına kaydedilmiş ve her satın alım için yeniden kullanılmış.
• Geçirmeden önce doğrulayın. Satın alma kodunuzda değerin gerçek bir UUID olduğunu teyit edin, böylece hatalı biçimlendirilmiş bir id işlemde asla sessizce nil bir token'a dönüşemez.
• Uygulama dışı satın alımları geriye doldurun. Bir teklif kodu kullanımı veya tanıtılan bir satın alım için token olmadan bir sunucu bildirimi geldiğinde, doğru olanı eklemek için Set App Account Token uç noktasını çağırın.

Bu üçünü yapın, Apple'ın size gönderdiği her işlem, iade istekleri dahil, ait olduğu müşteriye zaten bağlı olarak gelir.

RefundHalt'ın dayandığı temel budur. appAccountToken'ı her işlemden ve sunucu bildiriminden okuyoruz, onu o hesap için zaten takip ettiğimiz kullanıma bağlıyoruz ve Apple'ın tüketim isteğini on iki saatlik pencere içinde müşterinin gerçek rakamlarıyla yanıtlıyoruz. Token o ipliktir. Onu bir kez ayarlayın ve iade savunmanızın tutunacak bir şeyi olur.