एक ग्राहक Apple से रिफंड माँगता है। बारह घंटे बाद आपके सर्वर पर एक विंडो बंद हो जाती है, और ज़्यादातर टीमों को पता ही नहीं चलता कि वह कभी खुली थी।
यह विंडो Apple CONSUMPTION_REQUEST की है — एक नोटिफिकेशन जो App Store तब भेजता है जब वह किसी रिफंड अनुरोध का मूल्यांकन करते समय आपसे जानकारी चाहता है। यह रिफंड नहीं है। यह कोई फ़ैसला नहीं है। अंतिम रिफंड निर्णय हर हाल में Apple ही लेता है। यह नोटिफिकेशन आपको बस एक सीमित मौका देता है यह बताने का कि उस खरीद के साथ वास्तव में क्या हुआ।
इसे सही ढंग से संभालना बैकएंड की समस्या है, सपोर्ट की नहीं। नोटिफिकेशन पहुँचना चाहिए, ट्रांज़ैक्शन पहचानी जा सकनी चाहिए, सहमति की स्थिति पता होनी चाहिए, और रिस्पॉन्स समय रहते जाना चाहिए।
यह लेख बताता है कि इस नोटिफिकेशन का क्या मतलब है, Apple अब क्या माँगता है (फ़ील्ड की सूची पहले से काफ़ी छोटी हो गई है), और इसके इर्द-गिर्द वर्कफ़्लो कैसे बनाया जाए। व्यापक प्रक्रिया के लिए, App Store रिफंड प्रबंधन पर हमारी गाइड पूरा संदर्भ देती है।
मुख्य बातें
• CONSUMPTION_REQUEST का मतलब है कि Apple रिफंड मूल्यांकन के दौरान जानकारी माँग रहा है। यह रिफंड की सूचना नहीं है।
• अंतिम रिफंड निर्णय Apple लेता है। आपका रिस्पॉन्स कई इनपुट में से एक है।
• मौजूदा endpoint पाँच फ़ील्ड लेता है, जिनमें से तीन अनिवार्य हैं — पुराने संस्करण के बारह से घटकर।
• सहमति अनिवार्य है। जहाँ customerConsented true नहीं होता, Apple अनुरोध अस्वीकार कर देता है।
• Apple नोटिफिकेशन के 12 घंटे के भीतर रिस्पॉन्स माँगता है।
• चूँकि विंडो छोटी है और नोटिफिकेशन किसी भी समय आ सकते हैं, यह चरण मानवीय प्रक्रिया के बजाय ऑटोमेशन के लिए ज़्यादा उपयुक्त है।
Apple CONSUMPTION_REQUEST क्या है?
CONSUMPTION_REQUEST एक App Store Server Notification है जो आपको बताता है कि किसी ग्राहक ने Apple से रिफंड माँगा है, और App Store आपको उस खरीद के बारे में consumption जानकारी भेजने के लिए आमंत्रित कर रहा है।
डेवलपर्स के लिए Apple का consumption request एक जानकारी की कमी की वजह से मौजूद है। Apple को ट्रांज़ैक्शन, अकाउंट और खरीद इतिहास दिखता है। उसे यह नहीं दिखता कि आपके ऐप के अंदर क्या हुआ — कंटेंट डिलीवर हुआ या नहीं, उसने काम किया या नहीं, ग्राहक ने उसे वास्तव में कितना इस्तेमाल किया। आपको यह दिखता है।
एक बात जो यह नहीं है: वीटो। रिस्पॉन्स रिफंड को रोकता नहीं है, और Apple स्पष्ट कहता है कि वह कई कारकों को तौलता है।
Apple CONSUMPTION_REQUEST कैसे काम करता है?
क्रम कुछ इस तरह चलता है:
ग्राहक रिफंड का अनुरोध करता है
↓
Apple अनुरोध का मूल्यांकन शुरू करता है
↓
CONSUMPTION_REQUEST आपके notifications endpoint पर पहुँचता है
↓
आप नोटिफिकेशन सत्यापित करते हैं और ट्रांज़ैक्शन पहचानते हैं
↓
आप सहमति जाँचते हैं और वास्तविक उपयोग डेटा जुटाते हैं
↓
शर्तें पूरी होने पर आप consumption जानकारी भेजते हैं
↓
Apple रिफंड का निर्णय लेता है
↓
REFUND या REFUND_DECLINED आता है; आप स्टेट अपडेट करते हैं
ध्यान देने लायक: Apple के मौजूदा endpoint पर किसी भी प्रोडक्ट प्रकार के लिए रिफंड अनुरोध इसे ट्रिगर कर सकता है — consumable, non-consumable, non-renewing subscription, या auto-renewable subscription। पुराने दस्तावेज़ और ज़्यादातर थर्ड-पार्टी लेख अब भी इसे केवल consumables और auto-renewable subscriptions तक सीमित बताते हैं। अगर आपका handler उस आधार पर प्रोडक्ट प्रकार के हिसाब से फ़िल्टर करता है, तो वह अनुरोध छोड़ रहा है।
Apple डेवलपर्स से कौन-सी जानकारी माँगता है?
पहले से कम। यही वह हिस्सा है जहाँ ज़्यादातर मौजूदा मार्गदर्शन गलत है, इसलिए सटीक रहना ज़रूरी है। Apple का मौजूदा Send Consumption Information endpoint पाँच फ़ील्ड लेता है — तीन अनिवार्य, दो वैकल्पिक।
फ़ील्ड | अनिवार्य | आपके लिए इसका मतलब |
customerConsented | हाँ | true होना चाहिए। अन्यथा Apple अनुरोध अस्वीकार कर देता है। |
deliveryStatus | हाँ | क्या आपके ऐप ने काम करने वाली खरीद सफलतापूर्वक डिलीवर की। |
sampleContentProvided | हाँ | क्या ग्राहक को खरीदने से पहले सैंपल कंटेंट मिला। |
consumptionPercentage | नहीं | खरीद का कितना हिस्सा उपभोग हुआ, milliunits में। |
refundPreference | नहीं | आपका पसंदीदा नतीजा: पूरा रिफंड, अस्वीकार, या आनुपातिक (prorate)। |
दो शर्तें लोगों को चौंकाती हैं। अगर deliveryStatus delivered के अलावा कुछ और है, तो consumptionPercentage शून्य होना चाहिए, वरना अनुरोध विफल हो जाता है। और milliunits प्रतिशत नहीं हैं — आधा उपभोग 50000 है, 50 नहीं।
वैकल्पिक refund preference नया है और समझने लायक है। आप बता सकते हैं कि आप रिफंड पूरा दिया जाना, अस्वीकार किया जाना, या आनुपातिक किया जाना पसंद करेंगे। यह एक प्राथमिकता है, निर्देश नहीं — Apple इसे बाकी सब चीज़ों के साथ तौलता है, और नतीजा आपके माँगे गए से अलग हो सकता है।
अगर Apple आनुपातिक रिफंड मंज़ूर करता है, तो रद्द किया गया हिस्सा ट्रांज़ैक्शन payload में वापस आता है, इसलिए आपके entitlement logic को हर रिफंड को सब-या-कुछ-नहीं मानने के बजाय आंशिक revocation संभालने की ज़रूरत पड़ सकती है।
Apple को consumption जानकारी की ज़रूरत क्यों है?
क्योंकि Apple ऐसी चीज़ पर फ़ैसला ले रहा है जिसे वह सिर्फ़ आंशिक रूप से देख सकता है।
Apple जानता है कि क्या खरीदा गया, कब, किस अकाउंट से, और उस अकाउंट का इतिहास कैसा है। उसे यह नहीं पता कि आपके सर्वर ने coins डिलीवर किए या नहीं, अनलॉक किया गया फ़ीचर काम किया या नहीं, या ग्राहक ने पैसे वापस माँगने से पहले प्रोडक्ट का भारी इस्तेमाल किया या नहीं। वह संदर्भ आपके सिस्टम में रहता है।
CONSUMPTION_REQUEST Apple रिफंड फ़्लो, फ़ैसला लेने से पहले उस संदर्भ को खींचने का Apple का तरीका है। यही वजह है कि वकालत से ज़्यादा सटीकता मायने रखती है। डेटा बताता है कि क्या हुआ। यह कोई मुकदमा नहीं है जिसकी आप पैरवी कर रहे हैं, और इसे उस तरह लेने में असली जोखिम है, बिना किसी भरोसेमंद फ़ायदे के।
डेवलपर्स CONSUMPTION_REQUEST का जवाब कैसे देते हैं
आठ चरण। ज़्यादातर काम किसी भी अनुरोध के आने से पहले होता है।
1. नोटिफिकेशन प्राप्त करें
App Store CONSUMPTION_REQUEST नोटिफिकेशन उस सर्वर URL पर आते हैं जिसे आप App Store Server Notifications V2 के लिए कॉन्फ़िगर करते हैं। अगर वह endpoint मौजूद नहीं है, सत्यापित नहीं है, या चुपचाप फ़ेल हो रहा है, तो अनुरोध आप तक कभी नहीं पहुँचता। Apple का App Store Server Notifications दस्तावेज़ सेटअप और payload फ़ॉर्मैट को कवर करता है।
2. नोटिफिकेशन सत्यापित करें
नोटिफिकेशन signed JWS payload के रूप में आते हैं। अंदर की किसी भी चीज़ पर कार्रवाई करने से पहले Apple की certificate chain के विरुद्ध signature सत्यापित करें, और जाँचें कि bundle ID आपके ऐप से मेल खाता है। जो भी भेजा जाए उसे स्वीकार कर लेने वाला असत्यापित endpoint किसी और के लिए आपके रिफंड logic को चलाने का रास्ता है।
3. ट्रांज़ैक्शन पहचानें
डिकोड किए गए payload में ट्रांज़ैक्शन identifiers होते हैं। उनका मिलान करने के लिए आपके पास संग्रहीत खरीद रिकॉर्ड होना चाहिए। रिकॉर्ड नहीं, तो lookup नहीं — और consumption के बारे में कुछ भी उपयोगी कहने का कोई तरीका नहीं।
4. ट्रांज़ैक्शन को सही यूज़र से मिलाएँ
जब तक आप नहीं जानते कि ग्राहक कौन है, आप उसके उपयोग का वर्णन नहीं कर सकते। यही mapping वह काम है जिसके लिए appAccountToken मौजूद है: एक UUID जो आपका ऐप खरीद के समय जोड़ता है और जो नोटिफिकेशन payload में वापस आता है। इसके बिना टीमें timing और अनुमानों के आधार पर मिलान करने लगती हैं, जो ठीक उसी समय धीमा और अविश्वसनीय होता है जब गति मायने रखती है।
5. लागू सहमति आवश्यकताएँ जाँचें
Apple यहाँ बिल्कुल स्पष्ट है: ग्राहक का डेटा साझा करने से पहले आपको वैध सहमति लेनी होगी, और उसे लेना आपकी ज़िम्मेदारी है, Apple की नहीं। नोटिफिकेशन में कोई consent flag नहीं होता, इसलिए आपको यह अपने रिकॉर्ड से जानना होगा।
अगर ग्राहक ने सहमति नहीं दी है, तो Apple का मार्गदर्शन है कि जवाब ही न दें। consent को false सेट करके अनुरोध भेजना काम नहीं करता — App Store उसे अस्वीकार कर देता है। Apple यह भी साफ़ कहता है कि App Tracking Transparency prompt इसके लिए तंत्र नहीं है; यह एक अलग सहमति है, जो आपके ऐप में ली जाती है।
6. वास्तविक उपयोग की जानकारी जुटाएँ
डिलीवरी स्थिति और consumption अपने वास्तविक रिकॉर्ड से निकालें। अगर आपका सर्वर consumable बैलेंस ट्रैक करता है, तो आपको पहले से पता है कि कितना खर्च हुआ। अगर कोई फ़ीचर अनलॉक फ़ेल हुआ, तो आपके logs को वह भी पता है। अनुमान न लगाएँ — गढ़ा हुआ consumption आँकड़ा Apple को भेजा गया गलत डेटा है, उस सहमति के तहत जो आपने सटीक डेटा के लिए ली थी।
7. उचित जानकारी भेजें
नोटिफिकेशन से मिले original transaction identifier का उपयोग करके consumption endpoint पर PUT के साथ जवाब दें। भेजकर भूल जाने के बजाय error responses को संभालें: validation विफलताएँ विशिष्ट error types के साथ HTTP 400 लौटाती हैं, और अगर कोई जाँचे नहीं तो चुपचाप फ़ेल हुई call सफल call जैसी ही दिखती है।
8. नतीजा दर्ज करें
अनुरोध, ट्रांज़ैक्शन, आपने क्या भेजा, कब भेजा, और Apple ने अंततः क्या फ़ैसला किया — सब log करें। यही रिकॉर्ड आपको हफ़्तों बाद किसी सपोर्ट सवाल का जवाब देने, रिफंड्स में पैटर्न पहचानने, और अपनी entitlement स्थिति सही होने की पुष्टि करने देता है। जब रिफंड हो जाए, तो रिफंड के बाद एक्सेस रद्द करें — और अगर Apple बाद में फ़ैसला पलटे तो उसे बहाल करने के लिए तैयार रहें।
अगर डेवलपर्स CONSUMPTION_REQUEST चूक जाएँ तो क्या होता है?
कुछ नाटकीय नहीं, और यही समस्या का हिस्सा है।
रिस्पॉन्स चूकने का मतलब है कि आप वह अतिरिक्त जानकारी नहीं देते जो Apple ने आपको उस वर्कफ़्लो के दौरान जमा करने की अनुमति दी थी। Apple फिर भी फ़ैसला लेता है। रिफंड, Apple के पास पहले से मौजूद जानकारी के आधार पर, फिर भी मंज़ूर या अस्वीकार हो सकता है। कोई error नहीं, कोई अलर्ट नहीं, और कोई स्पष्ट संकेत नहीं कि कुछ छूट गया।
इसके चूकने के तरीके बिल्कुल साधारण हैं। नोटिफिकेशन रात 2 बजे आता है। handler का ज़िम्मेदार इंजीनियर छुट्टी पर है। ट्रांज़ैक्शन lookup खिंचता है क्योंकि identifier एक सिस्टम में है और उपयोग डेटा दूसरे में। कोई इसे सोमवार को देखता है, विंडो बंद होने के काफ़ी बाद।
मैन्युअल CONSUMPTION_REQUEST हैंडलिंग मुश्किल क्यों है
इस वर्कफ़्लो की हर शर्त मैन्युअल हैंडलिंग से दूर इशारा करती है।
नोटिफिकेशन चौबीसों घंटे आते हैं। विंडो 12 घंटे की है। हर अनुरोध के लिए ट्रांज़ैक्शन lookup, यूज़र मिलान, सहमति जाँच, उपयोग की गणना, signed API call, और logged नतीजा चाहिए — सात चरण, कोई भी दिलचस्प नहीं, सभी समय-बद्ध।
हफ़्ते में एक अनुरोध पर यह झुंझलाहट है। दिन में तीस पर यह किसी की नौकरी है — ऐसी जो सही ढंग से करने पर कुछ नहीं देती और देर से करने पर चुपचाप नुकसान करती है।
ऑटोमेशन रिफंड वर्कफ़्लो को कैसे बदलता है
ऑटोमेशन आपको Apple पर प्रभाव नहीं देता। इसे दोहराना ज़रूरी है, क्योंकि बहुत सी मार्केटिंग इसके उलट संकेत देती है। Apple का फ़ैसला Apple का ही रहता है।
ऑटोमेशन जो करता है, वह है आपकी तरफ़ को सुसंगत बनाना। नोटिफिकेशन की निगरानी और सत्यापन होता है। प्रासंगिक अनुरोध बाकी स्ट्रीम से अलग किए जाते हैं। ट्रांज़ैक्शन अकाउंट से मिलाए जाते हैं। रिस्पॉन्स डेटा वास्तविक रिकॉर्ड से तैयार होता है, समय-सीमाएँ ट्रैक होती हैं, रिस्पॉन्स जमा और log होते हैं, और नतीजे entitlement अपडेट में जाते हैं।
इनमें से किसी भी चरण में निर्णय-क्षमता की ज़रूरत नहीं। सभी में सही समय पर ध्यान की ज़रूरत है, जिसे सॉफ़्टवेयर लोगों से बेहतर संभालता है।
App Store रिफंड प्रबंधन सॉफ़्टवेयर को क्या संभालना चाहिए?
अगर आप App Store रिफंड प्रबंधन सॉफ़्टवेयर का मूल्यांकन कर रहे हैं, तो उपयोगी सवाल यह है कि क्या वह ऊपर बताई गई विशिष्ट कमियों को भरता है।
उसे App Store Server Notifications की निगरानी और सत्यापन करना चाहिए, ताकि इवेंट किसी फ़ेल होते endpoint में गायब न हों। उसे CONSUMPTION_REQUEST इवेंट्स को अलग से ट्रैक करना चाहिए, क्योंकि उन्हें रिफंड नतीजों से अलग हैंडलिंग चाहिए। उसे ट्रांज़ैक्शन को अकाउंट से मिलाना चाहिए, क्योंकि मैन्युअल समय वहीं जाता है। उसे रिस्पॉन्स विंडो ट्रैक करनी चाहिए, क्योंकि यही वह समय-सीमा है जो लोग चूकते हैं।
इसके अलावा: सहमति स्थिति का सम्मान करने वाले consumption-data वर्कफ़्लो, खोजने योग्य रिफंड इतिहास, नतीजों की ट्रैकिंग, आंशिक revocation सहित entitlement सिंक्रोनाइज़ेशन, और पैटर्न दिखाने लायक स्पष्ट रिपोर्टिंग। मायने वर्कफ़्लो की कवरेज रखती है, फ़ीचर सूची की लंबाई नहीं।
ये नियम कहाँ दस्तावेज़ित हैं
ऊपर की सारी बातें Apple के तीन स्रोत कवर करते हैं। उन्हें सीधे पढ़ें — यह क्षेत्र हाल में बदला है, और बहुत सा सेकेंडरी कंटेंट API के पुराने संस्करण का वर्णन कर रहा है।
Send Consumption Information — मौजूदा endpoint। सहमति की आवश्यकता, 12 घंटे की विंडो, पाँच-फ़ील्ड वाली request body, और यह तथ्य कि consumption जानकारी सभी प्रोडक्ट प्रकारों पर लागू होती है, इन सबको कवर करता है। स्टैंडर्ड In-App Purchases के लिए इसी के आधार पर बनाएँ।
App Store Server Notifications — नोटिफिकेशन आपके बैकएंड तक कैसे पहुँचते हैं, signed payload फ़ॉर्मैट, और notification types, जिनमें CONSUMPTION_REQUEST, REFUND और REFUND_DECLINED शामिल हैं।
Send Consumption Information V1 — पुराना endpoint, बारह-फ़ील्ड वाली request body के साथ, जो कुछ टीमों के पास अब भी जुड़ी हुई है। उस पेज पर Apple का अपना नोट स्टैंडर्ड In-App Purchases को मौजूदा endpoint की ओर निर्देशित करता है, और V1 को Advanced Commerce API का उपयोग करने वाली खरीदों तक सीमित करता है। यह पहचानने के लिए उपयोगी है कि आपका इंटीग्रेशन किस पर है, बनाने के लक्ष्य के रूप में नहीं।
अंतिम विचार
CONSUMPTION_REQUEST Apple का रिफंड निर्णय नहीं है। यह Apple को वह बताने का एक छोटा, समय-बद्ध मौका है जो आपके सिस्टम जानते हैं और Apple के नहीं।
इसे भरोसेमंद ढंग से संभालने वाले वर्कफ़्लो को चाहिए: सत्यापित notifications endpoint, ऐसे ट्रांज़ैक्शन जिन्हें आप पहचान सकें, ऐसे ग्राहक जिन्हें आप map कर सकें, सहमति जो आपने वास्तव में ली हो, वास्तविक उपयोग डेटा, विंडो के भीतर रिस्पॉन्स, और इतने अच्छे से दर्ज नतीजे कि बाद में entitlements अपडेट किए जा सकें।
अगर इसे पढ़ने के बाद आप एक ही काम करें, तो जाँचें कि आपका इंटीग्रेशन कौन-सा endpoint कॉल करता है। अगर वह स्टैंडर्ड In-App Purchases के लिए अब भी V1 path पर बारह फ़ील्ड भेज रहा है, तो सबसे पहले वही कमी भरने लायक है।
अगर रिफंड वॉल्यूम मैन्युअल हैंडलिंग से आगे निकल गया है
जब रिफंड गतिविधि इतनी बार-बार होने लगे कि नोटिफिकेशन हाथ से देखना यथार्थवादी न रहे, तो एक समर्पित सिस्टम इवेंट्स की निगरानी कर सकता है, विंडो के भीतर रिस्पॉन्स तैयार करके जमा कर सकता है, नतीजे ट्रैक कर सकता है, और entitlements को तालमेल में रख सकता है। RefundSensor उस वर्कफ़्लो के डेवलपर पक्ष को ऑटोमेट करता है — Apple के फ़ैसले को नहीं, सिर्फ़ उस हिस्से को जिसकी ज़िम्मेदारी आपकी है।
अक्सर पूछे जाने वाले प्रश्न
यह एक App Store Server Notification है जो आपके सर्वर को बताता है कि किसी ग्राहक ने रिफंड का अनुरोध किया है और Apple consumption जानकारी चाह सकता है। यह रिफंड का निर्णय नहीं है।
Apple इसे तब भेजता है जब कोई ग्राहक रिफंड का अनुरोध करता है और Apple उस अनुरोध की समीक्षा कर रहा होता है। यह App Store के अलग-अलग प्रोडक्ट प्रकारों पर लागू हो सकता है।
आपका सर्वर नोटिफिकेशन प्राप्त करके सत्यापित करता है, ट्रांज़ैक्शन और ग्राहक की पहचान करता है, सहमति जाँचता है, और रिस्पॉन्स विंडो के भीतर आवश्यक consumption जानकारी Apple को भेजता है।
नोटिफिकेशन सत्यापित करें, ग्राहक की सहमति जाँचें, सटीक उपयोग और डिलीवरी डेटा दें, उसे Apple को जमा करें, और रिस्पॉन्स व अंतिम नतीजे का रिकॉर्ड रखें।
Apple के मौजूदा दस्तावेज़ में 12 घंटे की रिस्पॉन्स विंडो बताई गई है। डेवलपर्स को इम्प्लीमेंटेशन से पहले Apple की नवीनतम आवश्यकताएँ जाँच लेनी चाहिए।
यह इस बारे में जानकारी है कि ग्राहक ने खरीद का उपयोग कैसे किया। मौजूदा endpoint के अनुसार इसमें सहमति, डिलीवरी स्थिति, सैंपल कंटेंट, consumption डेटा, और पसंदीदा रिफंड नतीजा शामिल हो सकते हैं।
नहीं। अंतिम निर्णय Apple लेता है। डेवलपर्स consumption जानकारी दे सकते हैं और रिफंड की प्राथमिकता बता सकते हैं, लेकिन अंतिम फ़ैसला Apple का होता है।
हाँ। डेवलपर्स नोटिफिकेशन सत्यापन, ट्रांज़ैक्शन मिलान, सहमति जाँच, डेटा तैयारी, समय-सीमा ट्रैकिंग, और रिस्पॉन्स logging को ऑटोमेट कर सकते हैं।
