किसी रिफंड को सबूत के साथ सही ठहराने के लिए Apple आपको सिर्फ बारह घंटे देता है। लेकिन यह समय-सीमा बेकार है अगर आपके सामने मौजूद ट्रांज़ैक्शन किसी ऐसे ग्राहक का है जिसका नाम आप बता ही नहीं सकते। appAccountToken वह UUID है जो यह नाम देता है, और इसे सिर्फ खरीदारी के दौरान ही जोड़ा जा सकता है।
ज़रा सोचिए कि वह नोटिफिकेशन आ गई है। Apple जानना चाहता है कि इस खरीदार ने प्रोडक्ट का कितना हिस्सा असल में इस्तेमाल किया, वह कितने समय से ग्राहक है, और उसने कुल मिलाकर कितना खर्च किया है। यह सब वाजिब सवाल हैं, और आपके डेटाबेस में हर जवाब मौजूद है। मुश्किल यह है कि आपके सामने मौजूद पेलोड में एक originalTransactionId और एक प्रोडक्ट आइडेंटिफायर है, और इनमें से कोई भी आपके यूज़र टेबल की किसी चीज़ से मेल नहीं खाता। आपके हाथ में एक ऐसा इनवॉइस है जिस पर कोई नाम नहीं है, जबकि आपको चाहिए जवाब नामों के हिसाब से दर्ज हैं।
इस बेमेल का एक समाधान है, और उस समाधान की भी एक डेडलाइन है। appAccountToken एक UUID है जिसे आपका सिस्टम जेनरेट करता है, चेकआउट के दौरान StoreKit को सौंपता है, और फिर Apple उसे बनने वाले ट्रांज़ैक्शन पर स्टैम्प कर देता है। उस पल के बाद, उस खरीदारी के बारे में Apple आपको जो भी बताता है, वह पहले से पहचाना हुआ आता है। लेकिन अगर आप वह मौका चूक गए, तो वह बिक्री हमेशा के लिए अनाम रह जाती है। आगे जानिए: यह फील्ड क्या है, इसे कैसे जोड़ा जाए, वह endpoint जो आपके ऐप द्वारा कभी न देखी गई खरीदारियों को भी बाद में बचा सकता है, और यह हिसाब कि एक अनाम रिफंड आपके बिज़नेस से असल में कितना निकाल ले जाता है।
मुख्य बातें
किसी App Store खरीदारी पर एक UUID जोड़ दें, तो उससे बनने वाला ट्रांज़ैक्शन सीधे आपके रिकॉर्ड्स में एक खास यूज़र की ओर इशारा करता है। Apple वह वैल्यू ट्रांज़ैक्शन पर रखता है और जहां-जहां वह ट्रांज़ैक्शन दिखता है, वहां उसे वापस लौटाता है।
Apple सिर्फ फॉर्मेट पर ध्यान देता है, और वह फॉर्मेट है UUID। अगर आप इसमें कोई डेटाबेस id, ईमेल एड्रेस, या खुद जोड़कर बनाई गई कोई स्ट्रिंग दें, तो StoreKit बिना कोई शिकायत किए उसे खारिज कर देता है, और जहां appAccountToken होना चाहिए था, वहां आपको nil मिल जाता है।
StoreKit 2 इसे एक सिंगल purchase option के रूप में उपलब्ध कराता है, Product.PurchaseOption.appAccountToken(_:), जिसमें वह UUID दिया जाता है जो आपके सिस्टम ने पहले ही जेनरेट करके उस अकाउंट के नाम दर्ज कर रखा है।
इसे पहली खरीदारी पर जोड़ दें, तो Apple उसी वैल्यू को सब्सक्रिप्शन चेन में हर रिन्यूअल, हर दोबारा कोशिश की गई बिलिंग, और हर अपग्रेड तक आगे बढ़ाता रहता है।
2025 से, Set App Account Token endpoint आपके सर्वर को वे खरीदारियां टैग करने का तरीका देता है जिन्हें इन-ऐप फ्लो ने कभी देखा ही नहीं था, जिनमें offer code redemptions और promoted purchases शामिल हैं।
Apple का CONSUMPTION_REQUEST इस टोकन की वजह से ही जवाब देने लायक बनता है। इसके बिना, आप रिफंड को उस ग्राहक से जोड़ ही नहीं सकते जिसके इस्तेमाल का विवरण आपको 12 घंटे की समय-सीमा के भीतर देना होता है।
जिस रिफंड की पहचान नहीं हो पाती, उसका बचाव भी नहीं हो पाता। जिन बिक्रियों का आपके पास सबूत था, उन पर भी पैसा वापस चला जाता है, और साथ में वह compute, API calls, और payouts भी चले जाते हैं जो उन्हें डिलीवर करने में पहले ही खर्च हो चुके थे।
यह फील्ड असल में क्या करती है
Apple इस वैल्यू को बेमानी मानकर चलता है, और यही इसकी खासियत है। चेकआउट के दौरान आप StoreKit को जो भी UUID देते हैं, वह ट्रांज़ैक्शन पर लिख दिया जाता है और हमेशा के लिए सहेज लिया जाता है, और उसका मतलब समझने, वह किससे संबंधित है यह जांचने, या वह किसी चीज़ से मेल खाता भी है या नहीं, इसकी कोई कोशिश नहीं की जाती। Apple की अपनी परिभाषा इसे "वह UUID जो ट्रांज़ैक्शन को आपकी अपनी सेवा पर यूज़र के अकाउंट से जोड़ता है" कहती है। इसका अर्थ निकालना पूरी तरह से आपका काम है। Apple सिर्फ वह वैल्यू साथ लेकर चलता है और मांगे जाने पर उसे वापस दे देता है।
यह कहां-कहां वापस मिलती है, यही इस फील्ड को उपयोगी बनाता है। सर्वर नोटिफिकेशन्स इसे साइन की गई ट्रांज़ैक्शन के भीतर ले जाते हैं। App Store Server API से Get Transaction Info मांगने पर यह वहां भी दिखती है। सब्सक्रिप्शन चेन का हर आगे वाला रिन्यूअल इसे फिर से दिखाता है, बशर्ते मूल खरीदारी में यह मौजूद रही हो। यानी, वैल्यू को एक बार जोड़ दें, तो जब तक वह ग्राहक आपको पैसे देता रहेगा, तब तक यह बार-बार सामने आती रहेगी।
UUID के अलावा कुछ भी भेजें, तो वह बिना किसी चेतावनी के गायब हो जाता है
डेवलपर्स को आमतौर पर यह नियम तब पता चलता है जब वे इसे तोड़ देते हैं। कोई ऐसी चीज़ पास की जाती है जो वाजिब लगती है, जैसे कोई internal account id, एक ईमेल एड्रेस, या जोड़े गए दो-तीन फील्ड्स, और StoreKit को कोई आपत्ति नहीं होती। न कोई एक्सेप्शन, न कोई चेतावनी, न खरीदारी फेल होती है। ट्रांज़ैक्शन बस appAccountToken को nil रखते हुए वापस आ जाता है, और जो कनेक्शन आपको लगता था कि बन गया है, वह कभी बना ही नहीं था। Apple के डेवलपर फोरम्स पर इस तरह की उलझन लगातार दिखती रहती है, जिसे अक्सर "appAccountToken is missing in the transaction payload" के रूप में बताया जाता है, और इसकी वजह लगभग हमेशा वही होती है: एक वैल्यू जो फॉर्मेट की शर्त पूरी नहीं कर पाई।
यह शर्त बेहद सीमित है: StoreKit 2 सिर्फ एक RFC 4122 UUID को स्वीकार करता है, और कुछ भी नहीं। इसलिए सुरक्षित तरीका यह है कि UUID को अपने सर्वर पर बनाएं, उसे अकाउंट के साथ सहेजें, और यह सुनिश्चित करें कि किसी और तरह की वैल्यू purchase call तक कभी न पहुंच पाए।
यही खामोशी इसे खतरनाक बनाती है। गलत फॉर्मेट वाली वैल्यू की वजह से न कोई एरर आता है, न बिक्री फेल होती है, सिर्फ वह लिंक चुपचाप खत्म हो जाता है जबकि बाकी सब कुछ सामान्य रूप से चलता रहता है। वैल्यू को StoreKit तक पहुंचने से पहले UUID फॉर्मेट के खिलाफ जांच लेने में सिर्फ एक लाइन का खर्च है, और इससे यह पूरी गड़बड़ी खत्म हो जाती है।
चेकआउट के दौरान टोकन जोड़ना
पूरा इम्प्लीमेंटेशन सिर्फ एक purchase option जितना है। रजिस्ट्रेशन के समय, या जब भी कोई ग्राहक पहली बार चेकआउट पर पहुंचे, सर्वर-साइड पर UUID जेनरेट करें, उसे उनके अकाउंट रिकॉर्ड पर लिख दें, और फिर जब भी वे खरीदारी करें, वही एक जैसी वैल्यू दें।
इस option का सिग्नेचर है Product.PurchaseOption.appAccountToken(_ token: UUID), और कॉल कुछ इस तरह दिखता है: try await product.purchase(options: [.appAccountToken(token)])। पूरा हुआ ट्रांज़ैक्शन आपके पास जिस भी तरीके से पहुंचे, चाहे आप उसे खुद App Store Server API के खिलाफ वेरिफाई करें या वह सर्वर नोटिफिकेशन के रूप में आए, वह UUID उसके भीतर साथ-साथ चलता रहता है, जिससे ग्राहक की पहचान महज एक इंडेक्स्ड लुकअप जितनी आसान हो जाती है।
हर ग्राहक के लिए एक टोकन, जो हमेशा दोबारा इस्तेमाल हो
एक लुभावनी गलती यह है कि हर ट्रांज़ैक्शन के लिए नया टोकन बनाया जाए। ऐसा करने से फायदा चुपचाप खत्म हो जाता है। Apple मूल खरीदारी पर मौजूद टोकन को उसी चेन के रिन्यूअल्स, दोबारा कोशिश की गई बिलिंग, और अपग्रेड्स में भी दोहराता है, जिसका मतलब है कि हर अकाउंट के लिए एक स्थिर UUID ग्राहक के पूरे पेमेंट इतिहास को जोड़े रखता है। वैल्यू को बदलते रहें, तो हर खरीदारी एक अलग-थलग टापू बन जाती है। यहां जो चीज़ अहम है वह है स्थिरता, इसलिए अकाउंट बनते समय ही एक UUID चुन लें और उसे कभी न बदलें।
वह endpoint जो आपके ऐप द्वारा कभी न छुई गई खरीदारियों को बचाता है
दो purchase रूट पहले इसे पूरी तरह से बेअसर कर देते थे। किसी offer code को redeem करना App Store में होता है, आपके ऐप में नहीं। store listing से कोई promoted in-app purchase खरीदना भी ऐसे ही होता है। इनमें से कोई भी रूट आपके purchase कोड को चलाता नहीं, जिसका मतलब था कि टोकन देने का कोई मौका ही नहीं बचता था, और वे ट्रांज़ैक्शन्स हमेशा के लिए अनाम रह जाते थे।
यह सीमा WWDC 2025 में Set App Account Token endpoint के आने के साथ खत्म हो गई। आपका सर्वर App Store Server API के खिलाफ PUT /inApps/v1/transactions/{originalTransactionId}/appAccountToken भेजता है, जिसमें बॉडी में UUID होता है, और Apple उसे ट्रांज़ैक्शन पर लिख देता है। यह सुविधा हर प्रोडक्ट टाइप पर लागू होती है, जिसमें offer code redemptions और promoted purchases भी पूरी तरह शामिल हैं, और इस तरह भेजी गई वैल्यू पहले से मौजूद किसी भी टोकन की जगह ले लेती है। इस तरह, पहचान करना अब कुछ ऐसा बन गया है जो आप बाद में, पूरी तरह सर्वर-साइड पर, उन खरीदारियों पर भी कर सकते हैं जिनमें आपका ऐप कभी शामिल ही नहीं था।
आप टोकन कहां जोड़ते हैं, यह इस पर निर्भर करता है कि खरीदारी किस तरह हुई:
किसी सामान्य in-app purchase के लिए, इसे खरीदारी के समय StoreKit purchase option में सेट करें, Product.PurchaseOption.appAccountToken(UUID) के ज़रिए।
किसी offer code redemption के लिए, इसे अपने सर्वर से Set App Account Token endpoint के ज़रिए सेट करें, क्योंकि इसमें जुड़ने के लिए इन-ऐप में कुछ भी नहीं होता और इसे आपको बाद में जोड़ना पड़ता है।
App Store से किए गए promoted in-app purchase के लिए, इसे भी वैसे ही Set App Account Token endpoint से सेट करें, क्योंकि ट्रांज़ैक्शन आपके ऐप के दायरे से बाहर होता है।
सब्सक्रिप्शन रिन्यूअल के लिए, आपको कुछ भी नहीं करना होता। टोकन मूल खरीदारी से अपने आप इनहेरिट हो जाता है।
टूटा हुआ लिंक आपके रेवेन्यू के साथ क्या करता है
यहां बात रिकॉर्ड-कीपिंग को व्यवस्थित रखने की नहीं है। बात यह है कि Apple रिफंड के दौरान डेवलपर्स से ठीक एक सवाल पूछता है, जो CONSUMPTION_REQUEST के रूप में आता है, और इसका जवाब देने के लिए यह जानना ज़रूरी है कि बात किस ग्राहक की हो रही है।
consumables और non-renewing subscriptions पर मांगे गए रिफंड ही यह नोटिफिकेशन शुरू करते हैं, और Send Consumption Information के ज़रिए आपको बारह घंटे के भीतर जवाब देना होता है। Apple एक व्यक्ति के बारे में खास जानकारी चाहता है: प्रोडक्ट का कितना हिस्सा इस्तेमाल हुआ, अकाउंट कितने समय पुराना है, लाइफटाइम खर्च, डिलीवरी स्टेटस। टोकन खुद उस रिक्वेस्ट के भीतर एक फील्ड के रूप में भी दिखता है, लेकिन इसकी ज़्यादा अहम भूमिका ढांचागत है, क्योंकि यही एकमात्र चीज़ है जो उस नोटिफिकेशन को आपके अपने डेटाबेस की एक पंक्ति में बदल सकती है। टोकन हटा दें, तो आपकी usage tracking कितनी भी गहरी हो, वह रिक्वेस्ट जवाब देने लायक ही नहीं रह जाती।
कुछ भी जवाब न देने की कीमत
जब रिफंड बिना पहचान के आता है, तो आपके पास सिर्फ दो रास्ते बचते हैं, और दोनों ही अच्छे नहीं हैं। खाली consumption response भेजें, तो Apple इसे कम से कम इस्तेमाल मानकर पढ़ता है, जिससे फैसला मंज़ूरी की ओर झुक जाता है, भारी इस्तेमाल करने वाले ग्राहक भी इसमें शामिल हैं। या फिर कोई अंदाज़ा बना लें, तो आप एक प्लेटफॉर्म होल्डर को काल्पनिक जानकारी दे रहे होते हैं। आप जो भी रास्ता चुनें, जिन बिक्रियों को आप साबित कर सकते थे, उन पर भी रिफंड हो ही जाता है, और यह तब होता है जब आप पहले ही उन्हें पूरा करने के लिए भुगतान कर चुके होते हैं।
fulfilment cost ही वह हिस्सा है जो सबसे ज़्यादा चोट पहुंचाता है, क्योंकि इसका बिक्री के दाम से कोई संबंध नहीं होता। जनरेशन के दौरान खर्च हुए मॉडल API calls, बनाई गई इमेजेज़, रेंडर और एक्सपोर्ट की गई कोई वीडियो, आगे किसी क्रिएटर को दिया गया पेआउट: यह सारा पैसा डिलीवरी के वक्त ही आपके अकाउंट्स से निकल जाता है, और ग्राहक को रिफंड देने से वह वापस नहीं आता। अब इस समस्या को बड़े स्तर पर देखें। एक ही अनाम ग्राहक बार-बार रिक्वेस्ट करता है। आदतन रिफंड मांगने वाले लोग खासतौर पर उन बिज़नेसेज़ को निशाना बनाते हैं जो उनकी पहचान नहीं कर सकते। उस पल छूट गया टोकन एक छोटी-सी भूल नहीं रह जाता, बल्कि एक खुले हुए नल की तरह काम करने लगता है।
Apple का सवाल एक ग्राहक के असली इस्तेमाल से जुड़ा होता है, और इसका जवाब देने के लिए यह जानना ज़रूरी है कि वह ग्राहक कौन है। टोकन के बिना आप वे बिक्रियां भी गंवा देते हैं जिन्हें आप साबित कर सकते थे, साथ ही वह compute और API खर्च भी, जो उन्हें डिलीवर करने में पहले ही लगाया जा चुका था।
Android पर यही तरीका एक अलग नाम से चलता है
Google Play पर यह काम setObfuscatedAccountId करता है, जो किसी खरीदारी पर एक account identifier बांध देता है, जिससे orders.reviewrefund के ज़रिए होने वाली chargeback review के पास जांचने के लिए एक असली व्यक्ति होता है। दोनों के इम्प्लीमेंटेशन काफी अलग हैं, लेकिन इनके पीछे का बुनियादी सिद्धांत बिना किसी बदलाव के लागू होता है: पहचान को ट्रांज़ैक्शन के दौरान ही जोड़ा जाना चाहिए, नहीं तो बाद में विवाद डिफ़ॉल्ट रूप से हार में बदल जाता है। Apple के पास उस सिद्धांत का जो रूप है, वह है appAccountToken, और यह UUID पर ही अड़ा रहता है।
तीन तरीके जो हर खरीदारी की पहचान बनाए रखते हैं
हर अकाउंट के लिए एक UUID बनाएं और उसे सहेजें। हर ग्राहक के लिए एक स्थिर टोकन, जो साइनअप या पहले चेकआउट के समय बनाया जाए, उनके रिकॉर्ड पर लिखा जाए, और वे जो भी खरीदें उस पर दोबारा इस्तेमाल किया जाए।
वैल्यू सौंपने से पहले उसकी जांच करें। अपने purchase कोड के भीतर यह पुष्टि करें कि यह असल में एक UUID ही है, ताकि कोई गलत फॉर्मेट वाला आइडेंटिफायर ट्रांज़ैक्शन पर चुपचाप nil टोकन में न बदल जाए।
ऐप के बाहर खरीदी गई किसी भी चीज़ को बैकफिल करें। जब offer code redemption या promoted purchase के लिए कोई सर्वर नोटिफिकेशन आए जिसमें कोई टोकन न हो, तो Set App Account Token endpoint का इस्तेमाल करें और सही टोकन जोड़ें।
इन तीनों को अपनाएं, तो पहचान करना कोई ऐसी चीज़ नहीं रह जाती जो आप बाद में करने की कोशिश करते हैं। यह एक ऐसा गुण बन जाता है जो हर ट्रांज़ैक्शन के पास पहले से मौजूद होता है, जब Apple उसे आपको सौंपता है, और इसमें रिफंड रिक्वेस्ट्स भी पूरी तरह शामिल हैं।
Refund Sensor सीधे इसी सोच पर बनाया गया है। हम हर ट्रांज़ैक्शन और सर्वर नोटिफिकेशन से appAccountToken निकालते हैं, उसे उस अकाउंट के लिए पहले से दर्ज किए गए consumption डेटा से जोड़ते हैं, और Apple की रिक्वेस्ट का जवाब बारह घंटे की समय-सीमा के भीतर ही, उन आंकड़ों के साथ दर्ज कर देते हैं जो उस खरीदार का असल में वर्णन करते हैं। जिस रिफंड का नाम आप बता सकते हैं, वही रिफंड है जिस पर आप बहस कर सकते हैं, और बहस करने लायक एकमात्र रिफंड भी वही है।
यह नियम कहां दर्ज हैं
अक्सर पूछे जाने वाले प्रश्न
एक ऐसा UUID जिसका मालिक आपका सिस्टम होता है, और StoreKit उसे सिर्फ दर्ज करता है। आप इसे चेकआउट के दौरान देते हैं, Apple इसे बनने वाले ट्रांज़ैक्शन पर लिख देता है, और उसके बाद यह जहां-जहां वह खरीदारी दिखती है वहां दोबारा दिखाई देता है: उसकी transaction info में, उससे जुड़ी किसी भी सर्वर नोटिफिकेशन में, और उसी चेन के आगे होने वाले हर रिन्यूअल में। इसका व्यावहारिक असर यह है कि Apple बाद में आपको जो भी बताए, रिफंड रिक्वेस्ट भी शामिल, उसे आपके अपने डेटाबेस की सही पंक्ति की ओर इशारा किया जा सकता है।
लगभग तय तौर पर, फॉर्मेट। RFC 4122 वह स्टैंडर्ड है जिसे StoreKit 2 स्वीकार करता है, और जो वैल्यू इस जांच में फेल हो जाती है, उसे बिना कोई एरर दिए खारिज कर दिया जाता है, जिससे nil बचता है, जबकि खरीदारी ऐसे पूरी हो जाती है जैसे कुछ गलत हुआ ही न हो। internal record ids, ईमेल एड्रेस, और जोड़कर बनाई गई स्ट्रिंग्स - ये सब इसी तरह फेल होते हैं। दूसरी संभावना यह है कि आपके ऐप ने उस खरीदारी को प्रोसेस ही नहीं किया, जिसमें आमतौर पर offer code redemption ही ज़िम्मेदार होता है, इसलिए आपका कोई कोड टोकन देने के लिए चला ही नहीं।
2025 से, हां। Apple ने ठीक इसी स्थिति के लिए App Store Server API में Set App Account Token जोड़ा। /inApps/v1/transactions/{originalTransactionId}/appAccountToken पर एक PUT, जिसकी बॉडी में UUID दिया जाता है, एक मौजूदा ट्रांज़ैक्शन पर टोकन लिख देता है, या वहां पहले से मौजूद किसी टोकन की जगह ले लेता है। यह हर प्रोडक्ट टाइप पर लागू होता है, और यह फीचर खासतौर पर उन खरीदारियों के लिए डिज़ाइन किया गया था जिन्हें आपका ऐप कभी हैंडल नहीं कर पाया, खासकर offer codes और promoted purchases।
हां, बिना किसी अपवाद के। वह UUID आपकी तरफ किस चीज़ की ओर इशारा करता है, यह पूरी तरह आपका मामला है और Apple उसे कभी जांचता नहीं, लेकिन वैल्यू को खुद UUID फॉर्मेट पूरा करना ही होता है। अगर यह पूरा नहीं होता, तो StoreKit उसे रखने से इनकार कर देता है, और ट्रांज़ैक्शन पर nil रह जाता है।
रिफंड्स एक CONSUMPTION_REQUEST को शुरू करते हैं, और Apple बारह घंटे के भीतर एक जवाब चाहता है जिसमें बताया गया हो कि उस खास खरीदार ने प्रोडक्ट का इस्तेमाल कैसे किया। ऐसा जवाब देने के लिए नोटिफिकेशन में मौजूद ट्रांज़ैक्शन को एक ऐसे ग्राहक रिकॉर्ड में बदलना पड़ता है जिसे आप असल में क्वेरी कर सकें, और यही टोकन का काम है। यह रिक्वेस्ट के भीतर एक फील्ड के रूप में भी मौजूद होता है। इसके बिना आपका जवाब या तो खाली होता है या बनाया-बताया गया, और खाली जवाब देने पर आमतौर पर रिफंड मंज़ूर हो ही जाता है।
