consumptionRequestReason क्या है?

consumptionRequestReason एक स्ट्रिंग फ़ील्ड है जिसे Apple हर CONSUMPTION_REQUEST सूचना में शामिल करता है, जो WWDC24 में App Store Server Notifications संस्करण 2.11 में जोड़ा गया था। यह रिफंड का अनुरोध करने के लिए ग्राहक का खुद का कारण बताता है, जो आपको 12 घंटे की विंडो के भीतर उपभोग डेटा के साथ जवाब देने से पहले संदर्भ देता है।

consumptionRequestReason के संभावित मान क्या हैं?

पाँच हैं: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL, और OTHER. Apple हर रिफंड अनुरोध पर ठीक एक भेजता है। हर एक एक अलग स्थिति की ओर इशारा करता है, एक आकस्मिक टैप से लेकर एक बताए गए कानूनी कारण तक, और हर एक को आपके द्वारा वापस भेजे जाने वाले refundPreference और उपभोग डेटा को आकार देना चाहिए।

क्या रिफंड कारण तय करता है कि मैं पैसा रखूँगा या नहीं?

नहीं। consumptionRequestReason एक संदर्भ है, फैसला नहीं। Apple फिर भी रिफंड तय करता है, आपके refundPreference, आपके deliveryStatus और consumptionPercentage, और ग्राहक के इतिहास को तौलते हुए। कारण आपको बताता है कि कौन सा मामला बनाना है। आपका डिलीवरी और उपयोग डेटा वह है जो इसे बनाता है।

मेरे पास एक CONSUMPTION_REQUEST का जवाब देने के लिए कितना समय है?

CONSUMPTION_REQUEST सूचना प्राप्त करने से लेकर Send Consumption Information को कॉल करने तक आपके पास 12 घंटे हैं। कॉल को customerConsented को true पर सेट करना होगा, वरना Apple इसे अस्वीकार कर देता है। विंडो चूक जाएँ और रिफंड आपके किसी भी डेटा के बिना तय हो जाता है।

क्या consumptionRequestReason सब्सक्रिप्शन रिफंड के लिए दिखता है?

हाँ। वही WWDC24 अपडेट जिसने consumptionRequestReason जोड़ा, उसने केवल उपभोग्य वस्तुओं के लिए नहीं, बल्कि ऑटो-रिन्यूएबल सब्सक्रिप्शन के लिए भी CONSUMPTION_REQUEST भेजना शुरू कर दिया। अधिकांश ऐप्स के लिए इसका मतलब है कि कारण फ़ील्ड अब उन रिफंड तक पहुँचता है जो वित्तीय रूप से सबसे अधिक मायने रखते हैं।

सभी लेख

गहन विश्लेषण25 जुलाई 2026पढ़ने में 7 मिनट

अब हर Apple रिफंड अनुरोध एक कारण के साथ आता है, और उसे पढ़ने का तरीका consumptionRequestReason है

WWDC24 के बाद से, हर Apple CONSUMPTION_REQUEST एक consumptionRequestReason ले जाता है, यानी रिफंड चाहने के लिए ग्राहक का खुद बताया गया कारण। इसके पाँच मान हैं, UNINTENDED_PURCHASE से LEGAL तक, और हर एक को आपकी 12 घंटे की विंडो के भीतर आपके भेजे जाने वाले जवाब को बदलना चाहिए। यहाँ बताया गया है कि हर एक को कैसे पढ़ें।

एक अँधेरे डेस्क पर एक स्मार्टफोन जो एक खाली कागज़ के टैग के बगल में सब्सक्रिप्शन भुगतान स्क्रीन दिखा रहा है, जो अब हर उपभोग अनुरोध के साथ आने वाले Apple रिफंड अनुरोध कारण को दर्शाता है

मुख्य बातें

WWDC24 में घोषित App Store Server Notifications संस्करण 2.11 के बाद से, हर CONSUMPTION_REQUEST सूचना में consumptionRequestReason शामिल होता है, एक स्ट्रिंग जो बताती है कि ग्राहक ने रिफंड क्यों माँगा।
ठीक पाँच मान हैं: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL, और OTHER. Apple हर अनुरोध पर एक भेजता है।
कारण रिफंड तय नहीं करता। यह वह संदर्भ है जिसका उपयोग आप 12 घंटे की विंडो बंद होने से पहले अपना refundPreference और अपना उपभोग डेटा चुनने के लिए करते हैं।
CONSUMPTION_REQUEST अब केवल उपभोग्य वस्तुओं के लिए नहीं, बल्कि ऑटो-रिन्यूएबल सब्सक्रिप्शन के लिए भी सक्रिय होता है, इसलिए consumptionRequestReason आपके रिफंड में से WWDC24 से पहले की तुलना में कहीं अधिक तक पहुँचता है।
FULFILLMENT_ISSUE कारण एक संकेत है कि आपकी अपनी डिलीवरी विफल हो सकती है। इसका विरोध करने से विंडो जल जाती है और बाद में चार्जबैक को न्योता मिलता है। इसे स्वीकार करना आमतौर पर सस्ता जवाब है।
आप 12 घंटे के भीतर customerConsented को true पर सेट करके और GRANT_FULL, GRANT_PRORATED, या DECLINE में से एक refundPreference के साथ Send Consumption Information को कॉल करके जवाब देते हैं। Apple आपकी वरीयता को एक इनपुट मानता है, आदेश नहीं।
एक रिफंड फिर भी आपको वह कंप्यूट, API कॉल, स्टोरेज, और भुगतान चुकाता है जो खरीद पहले ही खपत कर चुकी है। कारण फ़ील्ड वह तरीका है जिससे आप अपना बचाव केवल उन मामलों पर खर्च करते हैं जो बचाव के लायक हैं।

Apple ने बदल दिया कि रिफंड अनुरोध आपके सर्वर पर कैसे पहुँचते हैं, और बहुत सारे डेवलपर्स ने कभी ध्यान ही नहीं दिया। WWDC24 में घोषित App Store Server Notifications 2.11 अपडेट के बाद से, हर CONSUMPTION_REQUEST सूचना consumptionRequestReason नाम का एक फ़ील्ड ले जाती है। यह अपना पैसा वापस माँगने के लिए ग्राहक का खुद बताया गया कारण है। एक सादा स्ट्रिंग, पाँच संभावित मान, उसी पेलोड के भीतर पहुँचाई जाती है जिसका जवाब देने के लिए आपके पास पहले से बारह घंटे हैं।

Apple रिफंड अनुरोध कारण अपने आप में कुछ भी तय नहीं करता। यह जो करता है वह आपको बताता है कि आप पाँच बहुत अलग स्थितियों में से किस एक में हैं, ताकि आप एक ऐसे रिफंड को, जिसे आपको स्वीकार करना चाहिए, और एक ऐसे रिफंड को, जिससे आपको लड़ना चाहिए, वही सामान्य उपभोग डेटा भेजना बंद कर दें। यहाँ बताया गया है कि यह फ़ील्ड क्या है, वे सटीक मान जो Apple भेज सकता है, हर एक क्या संकेत देता है, और यह आपके लौटाए गए वरीयता और साक्ष्य को कैसे बदलना चाहिए।

consumptionRequestReason असल में क्या है

consumptionRequestReason एक CONSUMPTION_REQUEST सूचना के data ऑब्जेक्ट में एक स्ट्रिंग फ़ील्ड है। Apple ने इसे रिफंड फ्लो में WWDC24 के बदलावों के साथ-साथ App Store Server Notifications संस्करण 2.11 में जोड़ा। इससे पहले, अनुरोध हस्ताक्षरित लेनदेन के साथ आता था और मकसद के बारे में कुछ भी नहीं। आप आँख मूँदकर जवाब देते थे। अब ग्राहक का बताया गया कारण अनुरोध के साथ यात्रा करता है।

बताया गया शब्द को ध्यान से पढ़ें। यह वह कारण है जो ग्राहक ने Apple के पास दावा दाखिल करते समय चुना था, न कि कोई तथ्य जिसे Apple ने सत्यापित किया हो। UNINTENDED_PURCHASE यह साबित नहीं करता कि खरीद अनुपयोगी रही, और UNSATISFIED_WITH_PURCHASE यह साबित नहीं करता कि उत्पाद खराब था। मान एक लेंस है, फैसला नहीं। आप फिर भी इसे अपने खुद के डिलीवरी और उपयोग रिकॉर्ड के साथ जोड़ते हैं।

यह उसी सूचना के भीतर आता है जिसे आप पहले से संभालते हैं

CONSUMPTION_REQUEST एकमात्र Apple फ्लो है जो डेवलपर से साक्ष्य माँगता ही है। इसका Google Play समकक्ष orders.reviewrefund के माध्यम से चार्जबैक समीक्षा है। जब कोई आता है, तो आपके पास Send Consumption Information को कॉल करके जवाब देने के लिए 12 घंटे होते हैं, जो लेनदेन उपभोग एंडपॉइंट के लिए एक PUT है। consumptionRequestReason अब उसी सूचना का हिस्सा है, इसलिए सब्सक्राइब करने के लिए कुछ नया नहीं है। यदि आप पहले से CONSUMPTION_REQUEST को पार्स करते हैं, तो कारण एक ऐसा फ़ील्ड है जिसे आप शायद अनदेखा कर रहे थे।

पाँच कारण, और हर एक आपको क्या बता रहा है

Apple ठीक पाँच मान दस्तावेज़ करता है। हर अनुरोध पर एक आता है। यहाँ पूरा सेट है और हर एक को व्यवहार में कैसे पढ़ें।

मान	ग्राहक ने क्या बताया	आपके लिए इसका आमतौर पर क्या मतलब है
UNINTENDED_PURCHASE	वे इसे खरीदना नहीं चाहते थे	अक्सर एक आकस्मिक या पारिवारिक टैप। तय करने से पहले डिलीवरी और उपभोग जाँचें।
FULFILLMENT_ISSUE	वे इसे पा या उपयोग नहीं कर सके	यह आपकी अपनी डिलीवरी की ओर इशारा करता है। विरोध करने से पहले अपने लॉग सत्यापित करें।
UNSATISFIED_WITH_PURCHASE	वे इससे खुश नहीं थे	खरीदार का पछतावा। यहाँ आपके उपभोग साक्ष्य का सबसे अधिक वज़न है।
LEGAL	उन्होंने एक कानूनी कारण का हवाला दिया	इसे एक स्वीकृति के रूप में लें। एक कानूनी अनुरोध का विरोध करना विंडो के लायक नहीं है।
OTHER	ऊपर सूचीबद्ध न किया गया कोई भी कारण	अपने आप में कोई संकेत नहीं। अपने डिलीवरी और उपयोग डेटा पर लौटें।

UNINTENDED_PURCHASE आकस्मिक-टैप की श्रेणी है

यह वह कारण है जो एक माता-पिता तब चुनते हैं जब एक बच्चे ने 10,000 सिक्के खरीद लिए हों, या एक वयस्क जिसने गलती से पुष्टि दबा दी हो। यह उन खरीदों से संबंध रखता है जो कभी खोली या उपयोग नहीं की गईं। यही ठीक वह वजह है कि आपका अपना डेटा मायने रखता है। यदि आपके रिकॉर्ड दिखाते हैं कि उपभोग्य वस्तु पूरी तरह डिलीवर हुई और भारी रूप से खपत हुई, तो एक अनजाने-में-खरीद का दावा और एक पूरी तरह खर्च हुआ बैलेंस आपस में मेल नहीं खाते, और वह अंतर consumptionPercentage के माध्यम से रिपोर्ट करने लायक है।

FULFILLMENT_ISSUE आपकी ओर इशारा करता है

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

UNSATISFIED_WITH_PURCHASE वह जगह है जहाँ साक्ष्य फैसला करता है

यह साधारण खरीदार का पछतावा है, और यह वह कारण है जहाँ आपका उपभोग डेटा सबसे अधिक काम करता है। उत्पाद ने काम किया। ग्राहक ने इसका कुछ या पूरा उपयोग किया और अब पैसा वापस चाहता है। एक उच्च consumptionPercentage, एक ईमानदार DELIVERED का deliveryStatus, और DECLINE या GRANT_PRORATED का एक refundPreference वह मामला है जिसे बनाने के लिए Apple आपसे कह रहा है। संख्याएँ भेजें, कोई तर्क नहीं।

LEGAL और OTHER

LEGAL का मतलब है कि ग्राहक ने एक कानूनी या नियामक अधिकार का सहारा लिया। समझदार लोग असहमत हो सकते हैं, लेकिन नियम के तौर पर यह मुकदमेबाज़ी की विंडो नहीं है। इसे स्वीकार करें और आगे बढ़ें। OTHER वह सर्व-समावेशी विकल्प है जिसका Apple उपयोग करता है जब बताया गया कारण ऊपर के चार में से किसी से मेल नहीं खाता। यह अपने आप में कोई संकेत नहीं रखता, इसलिए एक OTHER के साथ ठीक वैसा ही व्यवहार करें जैसा आप बिना किसी कारण वाले अनुरोध के साथ करते: अपनी डिलीवरी स्थिति और उपयोग साक्ष्य से शुरू करें।

एक फ़ोन के बगल में एक अँधेरे डेस्क पर पंखे की तरह फैले पाँच खाली मुड़े हुए कार्ड, जो पाँच consumptionRequestReason मानों को दर्शाते हैं जो एक ग्राहक भेज सकता है

कारण आपके जवाब को कैसे बदलता है, फ़ील्ड दर फ़ील्ड

आप एक CONSUMPTION_REQUEST का जवाब एक ConsumptionRequest बॉडी के साथ Send Consumption Information को कॉल करके देते हैं। कारण को उस बॉडी में तीन फ़ील्ड को आकार देना चाहिए।

customerConsented को true होना ही चाहिए

Apple सबमिशन को केवल तभी स्वीकार करता है जब customerConsented true हो, यानी ग्राहक उपभोग डेटा साझा करने पर सहमत हो। यदि आपके पास वह सहमति नहीं है, तो आप कारण चाहे जो भी हो, बिल्कुल भी डेटा नहीं भेज सकते। कोई सहमति नहीं, कोई साक्ष्य नहीं, और अनुरोध आपकी संख्याओं के बिना तय हो जाता है।

deliveryStatus और consumptionPercentage तथ्य ले जाते हैं

deliveryStatus बताता है कि आपने काम करने वाली खरीद डिलीवर की या नहीं। यदि यह DELIVERED के अलावा कुछ भी है, तो Apple को consumptionPercentage का 0 होना आवश्यक है। जब आपने डिलीवर किया हो, तो consumptionPercentage 0 से 100,000 तक milliunits में एक पूर्णांक होता है, जहाँ 100,000 का मतलब है कि ग्राहक ने पूरी खरीद का उपयोग किया। यह जोड़ी आपका तथ्यात्मक केंद्र है, और यही वह है जिसे एक FULFILLMENT_ISSUE या एक UNSATISFIED_WITH_PURCHASE मामले को ले जाना चाहिए, कारण को स्वयं नहीं।

refundPreference आपका एकमात्र लीवर है

refundPreference वह जगह है जहाँ आप बताते हैं कि आप क्या चाहते हैं। Apple तीन मान दस्तावेज़ करता है: GRANT_FULL, GRANT_PRORATED, और DECLINE. कारण पढ़ें, इसे अपने डेटा के विरुद्ध तौलें, फिर चुनें। आपके लॉग में एक विफल डिलीवरी के साथ FULFILLMENT_ISSUE GRANT_FULL की ओर झुकता है। पूरी तरह खपत हुए उत्पाद पर UNSATISFIED_WITH_PURCHASE DECLINE या GRANT_PRORATED की ओर झुकता है। LEGAL GRANT_FULL की ओर झुकता है।

एक रिफंड असल में आपको क्या चुकाता है

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

यही वजह है कि कारण पढ़ने लायक है। मान लीजिए एक ग्राहक ने 5,000 क्रेडिट खरीदे जिनमें से हर एक एक सशुल्क API कॉल को ट्रिगर करता है, उनमें से 4,000 खर्च किए, फिर UNSATISFIED_WITH_PURCHASE के अंतर्गत दावा दाखिल किया। आपका deliveryStatus DELIVERED है, आपका consumptionPercentage 80,000 milliunits है, और एक DECLINE या GRANT_PRORATED वरीयता API बिल को झेलने और उसका अधिकांश वापस पाने के बीच का अंतर है। अब कारण को FULFILLMENT_ISSUE में पलट दें, ऐसे लॉग के साथ जो दिखाते हैं कि क्रेडिट कभी पोस्ट नहीं हुए, और ईमानदार, सस्ता कदम ग्राहक द्वारा अपने बैंक तक मामला बढ़ाने से पहले GRANT_FULL है।

बिना ज़्यादा प्रतिक्रिया दिए कारण पढ़ना

जाल यह है कि कारण को प्रमाण मान लिया जाए। UNINTENDED_PURCHASE इस बात का इकबालिया बयान नहीं है कि उत्पाद अनुपयोगी रहा, और LEGAL हमेशा एक वास्तविक कानूनी दावा नहीं होता। कारण स्थिति को संकीर्ण करता है। आपके डिलीवरी लॉग और उपभोग रिकॉर्ड इसे सुलझाते हैं। जब वे ग्राहक से सहमत हों, तो जल्दी और सस्ते में स्वीकार करें। जब वे ग्राहक का खंडन करें, तो वह खंडन, deliveryStatus और consumptionPercentage के रूप में व्यक्त, सबसे मज़बूत चीज़ है जो आप भेज सकते हैं। RefundHalt हर CONSUMPTION_REQUEST पर consumptionRequestReason पढ़ता है और इसे आपके वास्तविक उपयोग डेटा के साथ अपने आप जोड़ता है, ताकि हर कारण को 12 घंटे की विंडो के भीतर वह जवाब मिले जिसका वह हकदार है।

बदलाव छोटा है और छूट जाना आसान है, लेकिन इसने रिफंड की बातचीत को आपके पक्ष में कर दिया। Apple अब आपको बता रहा है कि क्यों, इससे पहले कि आप जवाब दें। इसका उपयोग करें।

अक्सर पूछे जाने वाले सवाल

consumptionRequestReason क्या है?: consumptionRequestReason एक स्ट्रिंग फ़ील्ड है जिसे Apple हर CONSUMPTION_REQUEST सूचना में शामिल करता है, जो WWDC24 में App Store Server Notifications संस्करण 2.11 में जोड़ा गया था। यह रिफंड का अनुरोध करने के लिए ग्राहक का खुद का कारण बताता है, जो आपको 12 घंटे की विंडो के भीतर उपभोग डेटा के साथ जवाब देने से पहले संदर्भ देता है।
consumptionRequestReason के संभावित मान क्या हैं?: पाँच हैं: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL, और OTHER. Apple हर रिफंड अनुरोध पर ठीक एक भेजता है। हर एक एक अलग स्थिति की ओर इशारा करता है, एक आकस्मिक टैप से लेकर एक बताए गए कानूनी कारण तक, और हर एक को आपके द्वारा वापस भेजे जाने वाले refundPreference और उपभोग डेटा को आकार देना चाहिए।
क्या रिफंड कारण तय करता है कि मैं पैसा रखूँगा या नहीं?: नहीं। consumptionRequestReason एक संदर्भ है, फैसला नहीं। Apple फिर भी रिफंड तय करता है, आपके refundPreference, आपके deliveryStatus और consumptionPercentage, और ग्राहक के इतिहास को तौलते हुए। कारण आपको बताता है कि कौन सा मामला बनाना है। आपका डिलीवरी और उपयोग डेटा वह है जो इसे बनाता है।
मेरे पास एक CONSUMPTION_REQUEST का जवाब देने के लिए कितना समय है?: CONSUMPTION_REQUEST सूचना प्राप्त करने से लेकर Send Consumption Information को कॉल करने तक आपके पास 12 घंटे हैं। कॉल को customerConsented को true पर सेट करना होगा, वरना Apple इसे अस्वीकार कर देता है। विंडो चूक जाएँ और रिफंड आपके किसी भी डेटा के बिना तय हो जाता है।
क्या consumptionRequestReason सब्सक्रिप्शन रिफंड के लिए दिखता है?: हाँ। वही WWDC24 अपडेट जिसने consumptionRequestReason जोड़ा, उसने केवल उपभोग्य वस्तुओं के लिए नहीं, बल्कि ऑटो-रिन्यूएबल सब्सक्रिप्शन के लिए भी CONSUMPTION_REQUEST भेजना शुरू कर दिया। अधिकांश ऐप्स के लिए इसका मतलब है कि कारण फ़ील्ड अब उन रिफंड तक पहुँचता है जो वित्तीय रूप से सबसे अधिक मायने रखते हैं।

स्रोत और आगे की जानकारी

RefundHalt

App Store और Google Play के लिए refund ऑटोपायलट

आगे पढ़ें

गहन विश्लेषणपढ़ने में 8 मिनट

Google Play की chargeback समीक्षा आपको जवाबी कार्रवाई के लिए 24 घंटे देती है, यहाँ जानिए क्या भेजना है

जब कोई बैंक Google Play का कोई चार्ज वापस खींचता है, तो Google आपके सर्वर पर एक PendingRefundReviewNotification भेजता है और 24 घंटे की घड़ी शुरू कर देता है। इसका जवाब ReviewRefund API के ज़रिए एक refund प्राथमिकता और असली उपभोग के प्रमाण के साथ दें, वरना विवाद आपके बिना ही तय हो जाएगा। यहाँ पूरी प्रक्रिया है, फ़ील्ड दर फ़ील्ड।

Deep diveपढ़ने में 7 मिनट

हर App Store खरीद के साथ एक appAccountToken जोड़ें, वरना आप रिफंड का बचाव नहीं कर पाएंगे

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