हर इन-ऐप परचेज़ टाइप का रिफंड अलग तरीके से होता है, और उनमें से सिर्फ़ दो ही कभी आपका पक्ष माँगते हैं

App Store Connect या Play Console में आपने जो इन-ऐप परचेज़ टाइप चुना, वह सिर्फ़ यह तय नहीं करता कि प्रोडक्ट कैसे बिकता है। वह यह तय करता है कि रिफंड आने पर वह कैसा बर्ताव करेगा, क्या ग्राहक उसके बाद वह आइटम मुफ़्त में वापस पा सकता है, और क्या पैसे हिलने से पहले आपसे कभी आपका पक्ष पूछा जाएगा। एक कॉइन पैक, एक लाइफटाइम अनलॉक, एक मासिक subscription, और एक बार का सीज़न पास, ये चार अलग-अलग कानूनी और तकनीकी वस्तुएँ हैं, और रिफंड नियम इन्हें उसी तरह मानते हैं। ज़्यादातर डेवलपर इन सभी को एक ही परचेज़ कोड से शिप करते हैं और फिर हैरान होते हैं कि रिफंड असंगत क्यों लगते हैं। वे असंगत नहीं हैं। वे टाइप-विशिष्ट हैं।

यहाँ बताया गया है कि हर इन-ऐप परचेज़ टाइप क्या है, रिफंड उस पर कैसे असर डालता है, और क्यों चार में से सिर्फ़ दो ही कभी फ़ैसले को आपके सर्वर से होकर भेजते हैं।

चार इन-ऐप परचेज़ टाइप, और रिफंड इनके साथ अलग-अलग क्यों बँटते हैं

Apple चार प्रोडक्ट टाइप परिभाषित करता है। एक consumable इस्तेमाल होकर ख़त्म हो जाता है और दोबारा खरीदा जाता है, गेम करेंसी, हिंट्स, एक एनर्जी रिफिल। एक non-consumable एक बार खरीदा जाता है और हमेशा के लिए रखा जाता है, एक प्रो अनलॉक, एक विज्ञापन-हटाने वाला अपग्रेड, एक डाउनलोड करने योग्य लेवल पैक। एक auto-renewable subscription तब तक दोहराए जाने वाले चक्र पर बिल करता है जब तक ग्राहक रद्द न कर दे। एक non-renewing subscription एक निश्चित अवधि के लिए एक्सेस देता है जो अपने आप रिन्यू नहीं होता, जैसे एक ही अवधि के रूप में बेचा गया कंटेंट का एक सीज़न।

Google Play उसी कैटलॉग को अलग तरीके से बाँटता है पर उसी जगह पहुँचता है। यह प्रोडक्ट्स को one-time products और subscriptions में बाँटता है, और एक one-time product को consumable माना जाता है या नहीं, यह इस पर निर्भर करता है कि परचेज़ के बाद आपका ऐप उसे consume करता है या नहीं। शब्द अलग हैं। रिफंड के परिणाम नहीं।

Consumables वह टाइप हैं जिन्हें रिफंड धोखाधड़ी असल में निशाना बनाती है

एक consumable सबसे कठिन रिफंड मामला है जिसका आप सामना करेंगे, और यह कोई संयोग नहीं कि Apple ने consumption request इसी के इर्द-गिर्द बनाई। जिस पल एक ग्राहक 10,000 सिक्के खरीदता है और आपका सर्वर उन्हें देता है, वैल्यू डिलीवर हो जाती है। अगर वे उन सिक्कों को खर्च कर दें और फिर रिफंड के लिए फ़ाइल करें, तो स्टोर उनके पैसे लौटा सकता है, पर सिक्के जा चुके हैं और उन्हें पूरा करने में आपको जो लगा वह भी। Apple का अपना टूलिंग यही दर्शाता है, एक consumable पूरा होने के बाद ट्रांज़ैक्शन रिकॉर्ड से हट जाता है और कभी कोई रद्दीकरण तारीख नहीं रखता, क्योंकि रद्द करने के लिए कुछ स्थायी होता ही नहीं।

यही वजह है कि consumable वह प्रोडक्ट टाइप है जहाँ सबूत काम आता है। जब कोई ग्राहक किसी consumable पर रिफंड माँगता है, Apple आपके सर्वर को एक CONSUMPTION_REQUEST भेजता है और एक Send Consumption Information कॉल के लिए 12 hours तक इंतज़ार करता है। उस कॉल में आप एक deliveryStatus सेट करते हैं और, जब आपने डिलीवर किया हो, एक consumptionPercentage। यह प्रतिशत milliunits में 0 से 100,000 तक का एक पूर्णांक है, जहाँ 100,000 का मतलब है कि ग्राहक ने पूरी खरीद इस्तेमाल कर ली। एक कॉइन बैलेंस जिसे आपके रिकॉर्ड पूरी तरह खर्च दिखाते हैं वह एक 100,000 है जिसे आप रिपोर्ट कर सकते हैं, और यह किसी अनजाने-परचेज़ दावे के सामने रखने के लिए सबसे मज़बूत अकेला तथ्य है।

Consumables बहाल नहीं किए जा सकते, इसलिए समय ही सब कुछ है

क्योंकि एक consumable बहाल नहीं किया जा सकता, आप उसे उस तरह वापस नहीं खींच सकते जैसे आप एक subscription को वापस ले सकते हैं। एक बार रिफंड मंज़ूर हो जाने पर, आपकी एकमात्र सुरक्षा वह रिकॉर्ड है जो आपने बिक्री के समय रखा। अगर आपने डिलीवरी और consumption को तब लॉग नहीं किया जब यह हुआ, तो आप उसे एक 12-hour घड़ी के तहत फिर से जोड़ रहे हैं, जो डेटा ढूँढने के लिए सबसे बुरा समय है। इसे आते समय रिकॉर्ड करें, जाते समय नहीं।

Subscriptions का रिफंड एक ऐसी घड़ी पर होता है जिसे आप नियंत्रित नहीं करते

Auto-renewable subscriptions वहाँ हैं जहाँ ज़्यादातर ऐप अपना पैसा कमाते हैं, और WWDC24 रिफंड अपडेट ने आख़िरकार उन्हें consumables के समान सबूत विंडो से होकर भेज दिया। App Store Server Notifications version 2.11 के बाद से, एक auto-renewable subscription पर रिफंड रिक्वेस्ट भी एक CONSUMPTION_REQUEST फ़ायर करती है। तो वे subscription रिफंड जो पहले पूरी तरह आपके बिना तय होते थे, अब एक 12-hour विंडो के साथ आते हैं।

पेच यह है कि consumption को कैसे मापा जाता है। एक auto-renewable subscription के लिए, Apple नहीं चाहता कि आप कोई usage प्रतिशत गढ़ें। यह बीते हुए समय से consumption की गणना खुद करता है, इसलिए एक साल की योजना में छह महीने बिता चुका कोई व्यक्ति लगभग आधा consumed पढ़ा जाता है, चाहे आप कुछ भी भेजें। आपका लीवर प्रतिशत नहीं है। यह GRANT_FULL, GRANT_PRORATED, या DECLINE का एक ईमानदार refundPreference है, जिसके पीछे वह कोई भी usage सिग्नल हो जो आपके पास असल में है। वह प्राथमिकता भेजें जिसका सबूत समर्थन करता है और Apple को उसे तौलने दें।

Non-renewing subscriptions एक बार के अनलॉक के ज़्यादा करीब बैठते हैं

एक non-renewing subscription एक निश्चित अवधि है जिसे ग्राहक एक बार खरीदता है, और रिफंड के मामले में यह एक auto-renewable योजना से ज़्यादा एक non-consumable जैसा बर्ताव करता है। Apple शायद ही कभी इसे एक CONSUMPTION_REQUEST भेजता है, और अनुपात में बाँटने के लिए कोई स्वचालित रिन्यूअल नहीं होता। आपका ऐप अवधि को ट्रैक करने और ग्राहक के डिवाइसों में उसे बहाल करने के लिए ज़िम्मेदार है, इसलिए एक रिफंड का मतलब है एक ऐसी एक्सेस विंडो को समाप्त करना जिसे आप खुद संभाल रहे थे, न कि वह जिसे Apple आपके लिए घड़ी पर रख रहा था।

Non-consumables स्थायी होते हैं, जो दोनों तरफ़ काटता है

एक non-consumable बेचने के लिए सबसे साफ़ चीज़ है और रिफंड पर एक चुपचाप जाल। इसे एक बार खरीदा जाता है, यह हमेशा के लिए ग्राहक के स्टोर अकाउंट से जुड़ा होता है, और स्टोर इसे माँगने पर किसी भी डिवाइस पर बहाल कर सकता है। वह स्थायित्व एक फ़ीचर है जब तक कोई रिफंड न आए, क्योंकि अब आपको एक ऐसी entitlement वापस लेनी होगी जिसे अकाउंट अब भी याद रखता है। अगर आपका revoke लॉजिक सिर्फ़ परचेज़ के समय जाँचता है और कभी दोबारा सत्यापित नहीं करता, तो एक रिफंड पाया ग्राहक परचेज़ बहाल कर सकता है और सीधे भुगतान वाले फ़ीचर में वापस चल सकता है।

Google Play यहाँ एक कठोर किनारा जोड़ता है जो नए डेवलपरों को पकड़ता है। अगर आपका ऐप किसी परचेज़ को 72 hours के भीतर acknowledge नहीं करता, Google उसे अपने आप रिफंड कर देता है और entitlement वापस ले लेता है। एक non-consumable जिसे आपके बिलिंग कोड ने acknowledge करना भूल गया, वह अधर में नहीं लटकता। यह खुद उलट जाता है, और ग्राहक उस चीज़ की एक्सेस खो देता है जिसके लिए उन्होंने भुगतान किया, उनके अपने किसी अनुरोध के बिना।

रिफंड कौन जारी कर सकता है यह भी स्टोर और टाइप के हिसाब से बदलता है

किसी भी रिफंड प्रतिक्रिया की योजना बनाने से पहले, जान लें कि कलम किसके हाथ में है। App Store पर, हर प्रोडक्ट टाइप के लिए सिर्फ़ Apple ही इन-ऐप परचेज़ रिफंड जारी कर सकता है। आपका StoreKit कोड किसी परचेज़ का रिफंड नहीं कर सकता, और न ही आपका सपोर्ट डेस्क। आप उन दो टाइप पर Apple के फ़ैसले को प्रभावित करने के लिए consumption डेटा भेज सकते हैं जो एक विंडो खोलते हैं, और यही आपके सीधे नियंत्रण का पूरा दायरा है।

Google Play इसके उलट है। आप खुद Play Console या Voided Purchases और रिफंड APIs से किसी one-time product या subscription ऑर्डर का पूरा या आंशिक रिफंड कर सकते हैं। वह आज़ादी एक ज़िम्मेदारी भी है, किसी consumable पर आपके द्वारा जारी किए गए रिफंड को फिर भी आपके अपने बैकएंड में आइटम वापस लेना पड़ता है, क्योंकि Google नहीं जानता कि आपके सिक्के खर्च हो चुके हैं। आपने जो प्रोडक्ट टाइप चुना वह तय करता है कि वह revoke कितना साफ़ है।

हर रिफंड टाइप आपको असल में क्या पड़ता है

रिफंड की गई कीमत वह पंक्ति है जिसे हर कोई देखता है और बिल का सबसे छोटा हिस्सा है। जब कोई भी स्टोर रिफंड मंज़ूर करता है, वह उसके साथ अपना कमीशन भी उलट देता है, इसलिए आप पूरी sticker कीमत के बजाय अपनी नेट आय खोते हैं। यह अच्छी खबर है, और यहीं रुक जाती है। स्टोर जो लौटाता है वह वह कट है जो उसने लिया था। जो यह कभी नहीं लौटाता वह है जो आप बिक्री पूरी करने के लिए पहले ही खर्च कर चुके हैं, और वह संख्या प्रोडक्ट टाइप के हिसाब से तेज़ी से बदलती है।

Consumable महँगा रिफंड है

एक रिफंड किया गया consumable वह है जो अपनी कीमत से ज़्यादा पड़ सकता है। मान लीजिए एक ग्राहक 5,000 क्रेडिट खरीदता है जिनमें से हर एक एक भुगतान वाली inference कॉल ट्रिगर करता है, उनमें से 4,000 खर्च करता है, फिर रिफंड के लिए फ़ाइल करता है। स्टोर कीमत और अपना कमीशन वापस दे देता है, पर कंप्यूट, प्रति-टोकन API बिल, आपके बनाए इमेज, और उन क्रेडिट से जो कोई creator पेआउट हुआ, वह सब खर्च हो चुका है। एक non-consumable रिफंड कम से कम एक entitlement को आपके नियंत्रण में वापस खींचता है। एक consumable रिफंड एक ऐसी बिक्री वापस खींचता है जिसकी पूरी लागत आप पहले ही चुका चुके हैं।

एक chargeback उसी बिल का भारी संस्करण है

एक रिफंड और एक chargeback अलग घटनाएँ हैं, और अब उस फ़र्क पर एक तारीख है। जब कोई ग्राहक स्टोर से माँगने के बजाय अपने बैंक के पास चार्ज को विवादित करता है, एक पूरा हुआ chargeback बैंक-अंतिम होता है। August 3 2026 को या उसके बाद दिए गए Google Play ऑर्डर के लिए, एक हारा हुआ chargeback डेवलपर से खरीद कीमत में से Play की सेवा शुल्क घटाकर बिल करता है, साथ ही बैंक की chargeback फ़ीस, एक फ़्लैट चार्ज जो कार्ड नेटवर्क तय करता है। Google Play एक chargeback को समीक्षा के लिए orders.reviewrefund के ज़रिए आपके पास 24-hour विंडो के साथ भेजता है, यह एकमात्र Google फ़्लो है जो आपका सबूत माँगता है, और यह किसी भी प्रोडक्ट टाइप पर आ सकता है।

जब टाइप नियम तय करता है तो कैसे प्रतिक्रिया दें

आप यह नहीं बदल सकते कि बिक्री के बाद एक रिफंड किस प्रोडक्ट टाइप पर आता है, पर आप चारों को एक ही तरीके से संभालना बंद कर सकते हैं।

• consumables के लिए डिलीवरी और consumption को उसी पल रिकॉर्ड करें जब वे होते हैं। वह लॉग उस एक टाइप पर आपका पूरा बचाव है जिसे बहाल नहीं किया जा सकता, और 12-hour विंडो उसे शुरू से बनाने के लिए बहुत छोटी है।
• non-consumables के लिए एक रिफंड के बाद entitlements को दोबारा सत्यापित करें, सिर्फ़ परचेज़ के समय नहीं। एक restore कॉल को मौजूदा स्थिति जाँचनी चाहिए, ताकि एक रिफंड पाया ग्राहक भुगतान वाले फ़ीचर में वापस न चल सके।
• दोनों सबूत विंडो का अपने आप जवाब दें। एक 12-hour consumption request और एक 24-hour chargeback समीक्षा किसी के इनबॉक्स पढ़ने का इंतज़ार नहीं कर सकतीं, और वे समय क्षेत्रों के लिए नहीं बढ़तीं।
• अपने रिफंड बचाव को सिर्फ़ उन दो विवादित टाइप पर आँकें। उन टाइप पर रिफंड की बढ़ती संख्या जिन्होंने कभी विंडो नहीं खोली, वह एक प्रोडक्ट या मूल्य निर्धारण संकेत है, आपके सबूत की विफलता नहीं।

इसमें से कुछ भी स्टोर को हराने के बारे में नहीं है। यह आपकी प्रतिक्रिया को उस वस्तु से मिलाने के बारे में है जो असल में बेची गई थी। RefundHalt consumable और subscription CONSUMPTION_REQUEST और Google Play orders.reviewrefund समीक्षा का अपने आप, विंडो के भीतर, उस डिलीवरी और usage सबूत के साथ जवाब देता है जो आपने बिक्री के समय रिकॉर्ड किया, और यह उन रिफंड को जिन्हें किसी विंडो ने आपको कभी विवादित करने नहीं दिया, अपने ही खाते में रखता है, ताकि जिस संख्या से आप खुद को आँकते हैं वह ईमानदार बनी रहे।