संक्षिप्त जवाब: CONSUMPTION_REQUEST वह नोटिफिकेशन है जो Apple आपके सर्वर को तब भेजता है जब कोई ग्राहक किसी योग्य इन-ऐप खरीदारी या सब्सक्रिप्शन पर रिफंड का अनुरोध करता है। जवाब देने के लिए, आप एक स्ट्रक्चर्ड ConsumptionRequest वापस भेजते हैं — फ़ील्ड्स का एक सेट जो बताता है कि ग्राहक ने खरीदी गई चीज़ का इस्तेमाल कैसे किया, क्या उसने सहमति दी थी, और आपकी रिफंड प्रेफरेंस क्या है। Apple अपने फैसले में इन फ़ील्ड्स को तौलता है। यह गाइड बताती है कि हर फ़ील्ड का क्या मतलब है और यह क्यों मायने रखती है।
यह नोटिफिकेशन क्या है
जब कोई ग्राहक Apple से रिफंड मांगता है, तो App Store, App Store Server Notifications के ज़रिए आपके सर्वर को एक CONSUMPTION_REQUEST भेजता है। इसका मतलब है कि Apple कह रहा है: हमें बताएं कि इस ग्राहक ने इस खरीदारी का इस्तेमाल कैसे किया, और हम इसे अपने फैसले में शामिल करेंगे।
आप एक ConsumptionRequest बॉडी वापस भेजकर जवाब देते हैं। हर वैल्यू एक संकेत है। सटीक और पूरा apple रिफंड डेटा भेजें तो Apple के पास संदर्भ होता है; फ़ील्ड्स खाली छोड़ें तो वह कम जानकारी के आधार पर फैसला लेता है। आप खुद रिफंड को स्वीकार या अस्वीकार नहीं करते — अंतिम फैसला हमेशा Apple ही करता है — लेकिन आप जो भेजते हैं उसकी गुणवत्ता संभावनाओं को आकार देती है। पूरी प्रक्रिया जानने के लिए देखें Apple रिफंड रिक्वेस्ट को ऑटोमेट कैसे करें.
वे फ़ील्ड्स जिन्हें Apple स्वीकार करता है
यहां बताया गया है कि ConsumptionRequest में क्या शामिल होता है और हर फ़ील्ड Apple को क्या बताती है। ये consumption request फ़ील्ड्स वह स्ट्रक्चर्ड डेटा देती हैं जिसका इस्तेमाल consumption api वर्कफ़्लो में किया जाता है:
फ़ील्ड | यह क्या दर्शाती है | यह क्यों मायने रखती है |
customerConsented | क्या ग्राहक ने यह डेटा साझा करने के लिए सहमति दी | ज़रूरी है। इसका true होना आवश्यक है, वरना Apple रिस्पॉन्स को प्रोसेस नहीं करेगा। |
consumptionStatus | इस्तेमाल न किया गया / आंशिक रूप से इस्तेमाल किया गया / पूरी तरह इस्तेमाल किया गया | पूरी तरह इस्तेमाल की गई खरीदारी, बिना छुए रखी गई खरीदारी से बिल्कुल अलग मामला है। |
deliveryStatus | क्या वैल्यू या सेवा सफलतापूर्वक डिलीवर की गई | यह "हमने डिलीवर किया, उन्होंने इस्तेमाल किया" को असली डिलीवरी विफलता से अलग करता है। |
refundPreference | आपकी सिफ़ारिश: undeclared / prefer grant / prefer decline | Apple के इनपुट्स में से एक — जहां आपके सबूत इसका समर्थन करते हैं, वहां यह फैसले में आपकी आवाज़ है। |
accountTenure | ग्राहक का आपके साथ अकाउंट कितने समय से है | लंबे समय से मौजूद अकाउंट, बिल्कुल नए अकाउंट से अलग तरह से आंका जाता है। |
playTime | ग्राहक ने आपके ऐप में कितना समय बिताया है | जिस चीज़ का रिफंड मांगा जा रहा है, उसके साथ जुड़ाव का सीधा सबूत। |
lifetimeDollarsPurchased | ग्राहक ने आपके सभी ऐप्स में कुल कितना खर्च किया है | यह संदर्भ देता है कि यह एक बार की खरीदारी है या यह एक मूल्यवान, स्थापित ग्राहक है। |
lifetimeDollarsRefunded | इस ग्राहक को पहले कुल कितना रिफंड दिया जा चुका है | बार-बार रिफंड का पैटर्न एक सार्थक संकेत है। |
sampleContentProvided | क्या ग्राहक खरीदने से पहले इसे आज़मा सकता था | यह बताता है कि खरीदारी सोच-समझकर की गई थी या नहीं। |
userStatus | मौजूदा अकाउंट स्टेटस (एक्टिव, सस्पेंडेड, आदि) | यह अनुरोध के समय ग्राहक की स्थिति को दर्शाता है। |
Apple इनमें से ज़्यादातर को निर्धारित वैल्यू सेट्स से जोड़ता है (उदाहरण के लिए, consumptionStatus और deliveryStatus विशिष्ट एनुमरेटेड कोड्स का इस्तेमाल करते हैं)। सटीक कोड्स नीचे लिंक की गई Apple की डॉक्यूमेंटेशन में मौजूद हैं, और ये बदल सकते हैं — यही एक वजह है कि रिस्पॉन्स को अपडेट रखना एक बार का काम नहीं, बल्कि चलता रहने वाला काम है।
तीन सबसे महत्वपूर्ण फ़ील्ड्स
अगर आप किसी एक चीज़ पर ध्यान दें, तो यहां दें:
customerConsented: यह सिर्फ महत्वपूर्ण नहीं है, बल्कि एक गेट है। अगर यह true नहीं है तो Apple पूरी सबमिशन को अस्वीकार कर देता है, और डेटा भेजने से पहले अपने ऐप में यह सहमति हासिल करने की कानूनी ज़िम्मेदारी आपकी है। यह जितनी तकनीकी फ़ील्ड है, उतनी ही कंप्लायंस फ़ील्ड भी है। हम सहमति की ज़रूरत को विस्तार से ग्राहक सहमति और Consumption API में कवर करते हैं।
refundPreference: यह किसी वोट के सबसे करीब की चीज़ है जो आपके पास है। जहां आपके सबूत वाकई अस्वीकार करने का समर्थन करते हैं, वहां यह प्रेफरेंस बताना उन इनपुट्स में से एक है जिन पर Apple विचार करता है। जहां ऐसा नहीं है, वहां जबरदस्ती decline प्रेफरेंस डालना कोई जादुई ओवरराइड नहीं है — फैसला फिर भी Apple ही करता है।
consumptionStatus: ग्राहक ने वाकई खरीदी गई चीज़ का इस्तेमाल किया या नहीं, यह अक्सर मामले का मुख्य बिंदु होता है। यह उन फ़ील्ड्स में से भी एक है जिसमें गलती होना सबसे आसान है, अगर अनुरोध आने के समय आपका उपयोग डेटा सटीक और अद्यतन न हो।
इन्हें सही तरीके से भरना दिखने से कहीं ज़्यादा मुश्किल क्यों है
फ़ील्ड्स की टेबल पढ़कर यह एक दोपहर में हो जाने वाला काम लग सकता है। लेकिन असल में, सही तरीके से जवाब देने का मतलब है:
अनुरोध आते ही हर ग्राहक के लिए सटीक, बिल्कुल ताज़ा उपयोग और बिलिंग डेटा निकालना — न कि कल का स्नैपशॉट।
अपने आंतरिक डेटा को Apple के सटीक वैल्यू सेट्स से मैप करना, और Apple द्वारा इन्हें बदलने पर भी इस मैपिंग को सही बनाए रखना।
यह सब ~12 घंटे की विंडो के भीतर, किसी भी समय, बिना किसी व्यक्ति के निगरानी किए करना।
सहमति की स्थिति, रीट्राई, विफलताओं और लॉगिंग को संभालना, ताकि आप साबित कर सकें कि आपने क्या भेजा और देख सकें कि यह काम कर रहा है या नहीं।
इनमें से कोई भी काम अवधारणा के स्तर पर मुश्किल नहीं है। लेकिन यह सब वह इन्फ्रास्ट्रक्चर है जिसे आपको ऐसे वर्कफ़्लो के लिए खुद बनाए और बनाए रखना होगा, जो आपका प्रोडक्ट नहीं है। ज़्यादातर टीमें आखिरकार यही हिसाब लगाती हैं: फ़ील्ड्स को समझना मुश्किल नहीं है, लेकिन इनके लिए एक भरोसेमंद, समय-सीमा के भीतर काम करने वाला, कंप्लायंट रेस्पॉन्डर खड़ा करना और उसे बनाए रखना एक स्थायी लागत है, जिससे आपके असली ऐप को कोई फायदा नहीं मिलता।
यही वह कमी है जिसे RefundSensor पूरा करता है। यह आपके डेटा से हर फ़ील्ड को मैप करता है, Apple के बदलावों के साथ अपडेट रहता है, और विंडो के भीतर अपने-आप जवाब देता है, ताकि रिफंड तय करने वाली सटीकता को बिना आपके बनाए या निगरानी किए संभाला जा सके। जो टीमें Apple रिफंड ऑटोमेशन सॉफ्टवेयर की तुलना कर रही हैं, उनके लिए यह वर्कफ़्लो से इन्फ्रास्ट्रक्चर का बोझ हटा देता है।
आधिकारिक स्रोत
Apple के वैल्यू सेट्स और आवश्यकताएं बदलती रहती हैं, इसलिए इसकी डॉक्यूमेंटेशन को अंतिम प्रमाण मानें:
फ़ील्ड्स को समझा जा सकता है। इनके लिए रेस्पॉन्डर बनाए रखना आपका काम नहीं है। RefundSensor आपके डेटा से हर ConsumptionRequest फ़ील्ड को मैप करता है और Apple की विंडो के भीतर अपने-आप जवाब देता है — सटीक, अद्यतन और कंप्लायंट। मुफ़्त में शुरू करें
अक्सर पूछे जाने वाले प्रश्न
यह वह App Store Server Notification है जो Apple तब भेजता है जब कोई ग्राहक किसी योग्य खरीदारी पर रिफंड का अनुरोध करता है। यह आपको कंज़म्पशन डेटा वापस भेजने के लिए प्रेरित करता है, जिसे Apple अपने रिफंड फैसले में तौलता है।
सहमति, कंज़म्पशन स्टेटस, डिलीवरी स्टेटस, अकाउंट अवधि, प्ले टाइम, लाइफटाइम खर्च और रिफंड, सैंपल कंटेंट, अकाउंट स्टेटस, और आपकी रिफंड प्रेफरेंस बताने वाली फ़ील्ड्स। हर एक फ़ील्ड एक संकेत है जिसे Apple अपने फैसले में शामिल करता है।
customerConsented एक अनिवार्य गेट है, इसके बिना रिस्पॉन्स को अस्वीकार कर दिया जाता है। refundPreference और consumptionStatus सबसे सीधे तौर पर नतीजे को आकार देते हैं, बशर्ते आपके सबूत आपके पक्ष का समर्थन करते हों।
जब किसी प्रेफरेंस के पीछे सटीक कंज़म्पशन और डिलीवरी डेटा हो, तो उसका वज़न ज़्यादा होता है। अधूरे रिस्पॉन्स से Apple के पास कार्रवाई करने के लिए कम आधार बचता है, इसलिए सिर्फ प्रेफरेंस, सबूत के साथ दी गई प्रेफरेंस से कमज़ोर होती है।
नहीं। अंतिम फैसला हमेशा Apple ही करता है। सटीक डेटा आपकी संभावनाओं को बेहतर बनाता है; यह आपको वीटो का अधिकार नहीं देता।
