आपका उपभोग डेटा Apple के रिफंड निर्णय को सूचित करता है, उसे नियंत्रित नहीं करता
जब कोई ग्राहक Apple से रिफंड मांगता है, तो आपको उपभोग डेटा भेजने के लिए 12 घंटे मिलते हैं। Apple के अपने दस्तावेज़ इसे कई कारकों में से एक कहते हैं, कोई फैसला नहीं। यहाँ बताया गया है कि आपका डेटा वास्तव में क्या बदलता है, क्यों एक DECLINE के बावजूद रिफंड हो सकता है, और यह प्रयास डॉलर में कितने का है।
मुख्य बातें
- जब कोई ग्राहक रिफंड का अनुरोध करता है, तो Apple आपके सर्वर को एक CONSUMPTION_REQUEST सूचना भेजता है और आपको Send Consumption Information एंडपॉइंट के माध्यम से उपभोग डेटा के साथ जवाब देने के लिए 12 घंटे देता है। यह समय-सीमा चूक गए तो Apple आपके इनपुट के बिना निर्णय ले लेता है।
- Apple के अपने शब्दों में, App Store रिफंड तय करने के लिए कई कारकों का उपयोग करता है, और आप जो उपभोग जानकारी भेजते हैं उसका उपयोग उस निर्णय को सूचित करने के लिए किया जाता है। आपका refundPreference उन्हीं कारकों में से एक है, फैसला नहीं।
- आप अस्वीकार करने को प्राथमिकता, पूर्ण रिफंड देने को प्राथमिकता, या आनुपातिक रिफंड देने को प्राथमिकता के रूप में एक refundPreference भेज सकते हैं। Apple इसे तौलता है। यही वजह है कि टीमें देखती हैं कि जिस खरीद को उन्होंने अस्वीकार करने को प्राथमिकता के रूप में चिह्नित किया था, उसका भी रिफंड हो जाता है, और यह दस्तावेज़ के अनुसार ही काम कर रहा है।
- जब तक customerConsented true न हो, Apple आपके उपभोग डेटा को अस्वीकार कर देता है। यदि ग्राहक ने डेटा साझा करने के लिए सहमति नहीं दी, तो Apple की सलाह है कि सूचना का जवाब बिल्कुल न दें, और वह सहमति प्राप्त करने की ज़िम्मेदारी अकेले आपकी है।
- WWDC24 के बाद से CONSUMPTION_REQUEST केवल consumables के लिए ही नहीं, बल्कि auto-renewable सब्सक्रिप्शन के लिए भी सक्रिय होता है, इसलिए वही 12 घंटे का जवाब अब पहले की तुलना में आपके कहीं अधिक रिफंड तक पहुंचता है।
- auto-renewable सब्सक्रिप्शन के लिए Apple स्वयं उपभोग की गणना करता है और आनुपातिक प्राथमिकता को मना करता है, इसलिए वहां आपका प्रभाव उस consumable की तुलना में कमज़ोर है जिसे आप पूरी तरह उपभोग किया हुआ बता सकते हैं।
- खरीद को पूरा करने में आप जो डॉलर पहले ही खर्च कर चुके हैं, कंप्यूट, तीसरे-पक्ष के API कॉल, स्टोरेज, वे चले गए, चाहे Apple रिफंड दे या न दे। आपका उपभोग जवाब रिफंड को बदलता है, वह लागत कभी नहीं जो आप डिलीवरी के लिए पहले ही चुका चुके हैं।
एक ग्राहक रिफंड पर टैप करता है, और एक मिनट के भीतर आपके सर्वर को Apple से एक CONSUMPTION_REQUEST मिल जाता है। आपके पास उपभोग डेटा के साथ जवाब देने के लिए 12 घंटे हैं, और उस जवाब को वीटो के रूप में पढ़ना लुभावना है: अस्वीकार करने को प्राथमिकता भेजो, पैसा रख लो। यह वीटो नहीं है। Apple का अपना दस्तावेज़ कहता है कि App Store यह तय करने के लिए कई कारकों का उपयोग करता है कि रिफंड अनुरोध स्वीकृत होगा या अस्वीकृत, और आप जो उपभोग जानकारी देते हैं उसका उपयोग उसके रिफंड निर्णयों को सूचित करने के लिए किया जाता है। सूचित करना, तय करना नहीं। यह पोस्ट बताती है कि आपका उपभोग डेटा वास्तव में क्या बदलता है, क्यों जिस खरीद को आपने अस्वीकार करने को प्राथमिकता के रूप में चिह्नित किया वह फिर भी रिफंड हो सकती है, और जब आप पहले से खर्च किया पैसा गिनते हैं तो यह पूरा प्रयास किस काबिल है।
Apple वास्तव में आपके उपभोग डेटा के साथ क्या करता है
Send Consumption Information एंडपॉइंट इसलिए मौजूद है ताकि जिस क्षण रिफंड सवालों के घेरे में हो, आप Apple को संदर्भ सौंप सकें। यह आपको निर्णय नहीं सौंपता। प्रवाह को सही क्रम में पढ़ना ही समझदार अपेक्षाएं तय करने और दस्तावेज़ में दर्ज व्यवहार के खिलाफ बग दाखिल करने के बीच का अंतर है।
App Store तय करता है, और आप सिफारिश करते हैं
Apple इस विभाजन के बारे में स्पष्ट है। Send Consumption Information संदर्भ में, Apple लिखता है कि App Store यह तय करने के लिए कई कारकों का उपयोग करता है कि रिफंड अनुरोध स्वीकृत होगा या अस्वीकृत, और आप जो उपभोग जानकारी देते हैं उसका उपयोग वह अपने रिफंड निर्णयों को सूचित करने के लिए करता है। refundPreference फ़ील्ड पर ही, Apple कहता है कि आपकी रिफंड प्राथमिकता उन कई कारकों में से एक है जिनका उपयोग App Store अपने रिफंड निर्णयों को सूचित करने के लिए करता है। तो सबसे मज़बूत संकेत जो आप भेज सकते हैं, एक सीधा अस्वीकार करने को प्राथमिकता, फिर भी एक ऐसे मॉडल में एक इनपुट है जिसे आप नियंत्रित नहीं करते। ग्राहक का इतिहास, उनके द्वारा दिया गया कारण, उत्पाद का प्रकार, और Apple के अपने धोखाधड़ी संकेत, ये सब आपके जवाब के साथ उसी मॉडल में बैठते हैं।
CONSUMPTION_REQUEST अब केवल consumables ही नहीं, सब्सक्रिप्शन को भी कवर करता है
यह पहले consumables की कहानी हुआ करती थी। WWDC24 के बाद से CONSUMPTION_REQUEST सूचना तब सक्रिय होती है जब कोई ग्राहक किसी consumable इन-ऐप खरीद या किसी auto-renewable सब्सक्रिप्शन के लिए रिफंड का अनुरोध करता है। यह दायरे का बड़ा विस्तार है। वही 12 घंटे का जवाब अब सब्सक्रिप्शन रिफंड पर भी लागू होता है, जहां आपका प्रभाव अलग है क्योंकि Apple auto-renewables के लिए उपभोग की गणना स्वयं करता है और आपसे कोई आनुपातिक प्राथमिकता स्वीकार नहीं करेगा। यह तय करने से पहले कि आपका जवाब कितना ज़ोर लगा सकता है, हर अनुरोध पर उत्पाद का प्रकार पढ़ें।
वे पांच इनपुट जिन्हें भेजने की आपको अनुमति है
Apple जो V2 अनुरोध बॉडी स्वीकार करता है वह छोटी है, पांच फ़ील्ड काम करती हैं, और उनमें से तीन आवश्यक हैं। हर एक एक इनपुट है जिसे Apple तौलता है, न कि कोई स्विच जो किसी परिणाम को मजबूर करता है। यहाँ बताया गया है कि आप जवाब में क्या डाल सकते हैं और वह Apple को क्या बताता है।
| फ़ील्ड | आवश्यक | यह Apple को क्या बताता है |
|---|---|---|
| customerConsented | हां | क्या ग्राहक ने इस रिफंड डेटा को साझा करने पर सहमति दी। true होना चाहिए वरना Apple अनुरोध अस्वीकार कर देता है। |
| consumptionStatus | नहीं | कितना उपयोग हुआ: अघोषित, उपभोग नहीं हुआ, आंशिक रूप से उपभोग हुआ, या पूरी तरह उपभोग हुआ। |
| deliveryStatus | नहीं | क्या आपके ऐप ने एक कार्यशील खरीद डिलीवर की, या किसी समस्या से टकराया जिसे आप रिकॉर्ड में रखना चाहते हैं। |
| sampleContentProvided | नहीं | क्या आपने खरीद से पहले एक मुफ्त नमूना, ट्रायल, या फ़ीचर का विवरण पेश किया। |
| refundPreference | नहीं | आपका अनुशंसित परिणाम: अस्वीकार करने को प्राथमिकता, पूर्ण रिफंड देने को प्राथमिकता, या आनुपातिक रिफंड देने को प्राथमिकता। |
12 घंटे की समय-सीमा, और वह सहमति द्वार जिसे ज़्यादातर टीमें चूक जाती हैं
दो तंत्र यह तय करते हैं कि आपका जवाब गिना भी जाएगा या नहीं। एक घड़ी है। दूसरा एक सहमति फ़्लैग है जो बहुत से नेक-नीयत जवाबों को दरवाज़े पर ही रोक देता है।
12 घंटे के भीतर जवाब दें वरना मौका निकल जाता है
Apple का निर्देश साफ़ है: CONSUMPTION_REQUEST सूचना प्राप्त करने के 12 घंटे के भीतर जवाब दें। यही पूरी समय-सीमा है। रिफंड अनुरोध आपके अगले कार्यदिवस का इंतज़ार नहीं करता, और देर से पहुंचने वाला उपभोग जवाब वह जवाब है जिसे Apple ने कभी तौला ही नहीं। यदि आप इनका जवाब हाथ से दे रहे हैं, तो 12 घंटे की घड़ी वही हिस्सा है जो सबसे पहले चुपचाप विफल होता है, सप्ताहांत पर, छुट्टियों पर, और आपके समय क्षेत्र में सुबह 3 बजे। जवाब को विश्वसनीय होने के लिए स्वचालित होना ही होगा, क्योंकि समय-सीमा को इससे कोई फ़र्क नहीं पड़ता कि आपकी टीम कब जाग रही है।
जब तक ग्राहक सहमति न दे, आप डेटा नहीं भेज सकते
यहाँ वह द्वार है जिस पर टीमें फिसलती हैं। Apple किसी भी Send Consumption Information अनुरोध को अस्वीकार कर देता है जिसका customerConsented मान true के अलावा कुछ भी हो। Apple के शब्दों में, यदि ग्राहक ने सहमति दी है, तो API को कॉल करके और उपभोग डेटा भेजकर जवाब दें; यदि नहीं, तो CONSUMPTION_REQUEST सूचना का जवाब न दें। Apple ज़िम्मेदारी भी सीधे आप पर डालता है: ग्राहक का व्यक्तिगत डेटा साझा करने से पहले आपको उससे वैध सहमति प्राप्त करनी होगी, और आप, डेवलपर, उसे प्राप्त करने के लिए अकेले ज़िम्मेदार हैं। तो हर अनुरोध पर पहला सवाल यह नहीं है कि उन्होंने कितना उपयोग किया, यह है कि क्या इस ग्राहक ने हमें Apple को बताने की अनुमति दी। कोई सहमति नहीं, कोई जवाब नहीं, और रिफंड आपके पक्ष की कहानी को छोड़कर बाकी हर चीज़ पर तय हो जाता है।
वास्तव में Apple के रिफंड निर्णय को क्या बदलता है
यदि जवाब एक सिफारिश है, तो ईमानदार सवाल यह है कि यह कितनी सिफारिश करता है। जवाब यह है कि आपका डेटा ठीक वहीं सबसे अधिक मायने रखता है जहां कोई इंसान झिझकेगा, और वहां सबसे कम जहां परिणाम कभी वास्तव में संदेह में था ही नहीं।
क्यों आप अस्वीकार करने को प्राथमिकता भेज सकते हैं और फिर भी रिफंड देख सकते हैं
डेवलपर बताते हैं कि उन्होंने ऐसी खरीद पर अस्वीकार करने को प्राथमिकता भेजी जिसे ग्राहक ने पूरी तरह उपभोग कर लिया था, और फिर भी Apple को उसका रिफंड करते देखा। यह कोई टूटा हुआ API नहीं है। Apple ने आपको बताया था कि वह कई कारकों को तौलता है, और किसी भी अनुरोध पर उनमें से कुछ कारक एक पूरी तरह उपभोग किए गए consumable से अधिक भारी पड़ सकते हैं: साफ़ इतिहास वाला ग्राहक, कोई बताया गया कारण जिसे Apple मज़बूत मानता है, एक छोटी डॉलर राशि, पहली बार का अनुरोध। आपके जवाब ने रिफंड के खिलाफ ज़ोर लगाया। अन्य इनपुट ने ज़्यादा ज़ोर लगाया। सबक यह नहीं है कि जवाब देना बंद कर दें, यह है कि यह उम्मीद करना बंद करें कि एक साफ़ consumable हमेशा बच निकलेगा। जहां संकेत वास्तव में मिला-जुला है, वहां एक आंशिक रूप से उपभोग हुई स्थिति, एक दस्तावेज़ीकृत डिलीवरी समस्या, और एक ईमानदार प्राथमिकता वे इनपुट हैं जो किसी सीमांत मामले को आपके पक्ष में झुका सकते हैं।
एक सिफारिश डॉलर में कितने की है
एक रिफंड बिक्री की कीमत नहीं है। यह बिक्री की कीमत के साथ-साथ वह सब कुछ है जो आप उसे डिलीवर करने के लिए पहले ही खर्च कर चुके हैं, और उपभोग जवाब केवल पहले हिस्से को ही छूता है।
अनुरोध आने तक पैसा पहले ही खर्च हो चुका होता है
जब तक Apple पूछता है कि रिफंड करना है या नहीं, ग्राहक उस चीज़ का पहले ही उपयोग कर चुका होता है। किसी consumable पर इसका मतलब है कि कंप्यूट चला, तीसरे-पक्ष के API कॉल का बिल बना, छवियां या टोकन या जनरेशन तैयार हुए, और स्टोरेज लिखा गया। ये आपकी ओर से चुकाई गई लागतें हैं और यदि Apple रिफंड अस्वीकार करता है तो ये वापस नहीं आतीं, और यदि Apple रिफंड देता है तो ये दोगुनी खो जाती हैं। आपका उपभोग जवाब किसी सीमांत मामले पर बिक्री की कीमत वापस जीत सकता है। यह उन वस्तुओं की लागत वापस नहीं जीत सकता जो आप पहले ही सौंप चुके हैं। यही असली वजह है कि एक पूरी तरह उपभोग की गई खरीद रिफंड करने के लिए महंगी होती है, और इसका इससे कोई लेना-देना नहीं कि वह कितने समय पहले खरीदी गई थी।
- बिक्री की कीमत: Apple के कमीशन के बाद आपकी शुद्ध आय, यदि रिफंड दिया जाता है तो पलट जाती है। यह एकमात्र हिस्सा है जिसे आपका जवाब प्रभावित कर सकता है।
- डिलीवरी लागत: कंप्यूट, API कॉल, स्टोरेज, और कोई भी भुगतान जो आप उस खरीद के विरुद्ध पहले ही कर चुके हैं। निर्णय चाहे जो हो, चला गया।
- स्टाफ़ का समय: हाथ से जवाब दिया गया हर रिफंड किसी व्यक्ति के दिन के कुछ मिनट है, और 12 घंटे की समय-सीमा का मतलब है कि वे मिनट असुविधाजनक घंटों में आते हैं।
- वह पैटर्न जो आप चूक जाते हैं: एक ग्राहक जो बार-बार रिफंड लेता है वह एक ऐसी लागत है जिसे आप केवल तभी देखते हैं जब आप अनुरोधों के आर-पार उपभोग और इतिहास को ट्रैक कर रहे हों, न कि हर एक को अलग-थलग मान रहे हों।
Google Play इसी सवाल को कैसे संभालता है
Apple अकेला स्टोर नहीं है जो आपसे राय मांगता है और फिर खुद तय करता है। Google Play बैंक चार्जबैक के लिए एक समानांतर प्रवाह चलाता है, और उसकी बनावट वही है: आप साक्ष्य भेजते हैं, स्टोर तय करता है। अंतर घड़ी में है और इसमें है कि आपको क्या भेजने की अनुमति है।
| सवाल | App Store | Google Play |
|---|---|---|
| ट्रिगर | CONSUMPTION_REQUEST सूचना | किसी चार्जबैक के लिए PendingRefundReviewNotification |
| आपकी समय-सीमा | 12 घंटे | 24 घंटे |
| आप कैसे जवाब देते हैं | Send Consumption Information | orders.reviewrefund |
| आपकी सिफारिश | refundPreference: अस्वीकार, पूर्ण रिफंड, आनुपातिक रिफंड | refundPreference: APPROVE, DECLINE, या NEUTRAL |
| कौन तय करता है | App Store | Google Play, या चार्जबैक पर बैंक |
दोनों स्टोर पर निष्कर्ष एक जैसा है। आपका काम समय-सीमा के भीतर सटीक उपभोग साक्ष्य और एक ईमानदार प्राथमिकता के साथ जवाब देना है। स्टोर का काम तय करना है। इन दोनों को गड्डमड्ड करना ही वह तरीका है जिससे कोई टीम या तो समय-सीमा को अनदेखा कर बैठती है क्योंकि जवाब केवल एक सिफारिश है, या जवाब पर वीटो की तरह भरोसा कर बैठती है और तब चौंक जाती है जब रिफंड फिर भी हो जाता है। दोनों में से कोई सही नहीं है। हर बार जवाब दें, सटीक जवाब दें, और परिणाम को एक ऐसे निर्णय के रूप में देखें जिसे आपने सूचित किया, न कि जिसे आपने लिया।
RefundHalt उसी क्षण CONSUMPTION_REQUEST को पकड़ लेता है जिस क्षण Apple उसे भेजता है, सहमति की जांच करता है, उपभोग स्थिति, डिलीवरी स्थिति, और एक साक्ष्य-आधारित रिफंड प्राथमिकता जुटाता है, और 12 घंटे की समय-सीमा के भीतर जवाब देता है, बिना आपकी टीम के किसी व्यक्ति के घड़ी देखे। यह Google Play की चार्जबैक समीक्षा के लिए उसकी 24 घंटे की समय-सीमा के भीतर भी यही करता है। आप Apple को अपने तरीके से निर्णय लेने के लिए मजबूर नहीं कर सकते। आप यह सुनिश्चित कर सकते हैं कि Apple आपके पक्ष की कहानी के बिना कभी निर्णय न ले, हर रिफंड पर, समय पर।
अक्सर पूछे जाने वाले सवाल
- क्या Apple को उपभोग डेटा भेजने से रिफंड रुक जाता है?
- अपने आप नहीं। Apple का दस्तावेज़ कहता है कि App Store रिफंड तय करने के लिए कई कारकों का उपयोग करता है और आपके उपभोग डेटा का उपयोग उस निर्णय को सूचित करने के लिए किया जाता है। आपका जवाब, जिसमें अस्वीकार करने को प्राथमिकता का refundPreference भी शामिल है, एक इनपुट है जिसे Apple तौलता है, इसलिए यह किसी सीमांत मामले को बदल सकता है पर अस्वीकृति की गारंटी नहीं देगा, खासकर उस खरीद पर जिसे ग्राहक ने पूरी तरह उपभोग कर लिया।
- मुझे CONSUMPTION_REQUEST का जवाब देने के लिए कितना समय मिलता है?
- 12 घंटे। Apple कहता है कि Send Consumption Information एंडपॉइंट के माध्यम से CONSUMPTION_REQUEST सूचना प्राप्त करने के 12 घंटे के भीतर जवाब दें। समय-सीमा के बाद आने वाला जवाब वह जवाब है जिसे Apple ने कभी तौला ही नहीं, यही वजह है कि जवाब को स्वचालित होना चाहिए, न कि किसी ऐसे व्यक्ति द्वारा संभाला जाना जो सो रहा हो सकता है।
- मेरे अस्वीकार करने को प्राथमिकता भेजने के बाद भी Apple ने खरीद का रिफंड क्यों कर दिया?
- क्योंकि अस्वीकार करने को प्राथमिकता एक सिफारिश है, आदेश नहीं। Apple कहता है कि आपकी रिफंड प्राथमिकता उन कई कारकों में से एक है जिनका उपयोग वह अपने निर्णय को सूचित करने के लिए करता है। किसी अनुरोध पर ग्राहक का इतिहास, उनके द्वारा दिया गया कारण, डॉलर राशि, और Apple के अपने धोखाधड़ी संकेत आपकी प्राथमिकता से अधिक भारी पड़ सकते हैं, इसलिए अस्वीकार करने को प्राथमिकता के बाद रिफंड होना, प्रवाह का दस्तावेज़ के अनुसार काम करना ही है।
- क्या उपभोग डेटा भेजने के लिए मुझे ग्राहक की सहमति चाहिए?
- हां। जब तक customerConsented true न हो, Apple किसी Send Consumption Information अनुरोध को अस्वीकार कर देता है, और उसकी सलाह है कि यदि ग्राहक ने सहमति नहीं दी तो आपको CONSUMPTION_REQUEST का जवाब बिल्कुल नहीं देना चाहिए। Apple यह भी कहता है कि आप, डेवलपर, ग्राहक का डेटा साझा करने से पहले वैध सहमति प्राप्त करने के लिए अकेले ज़िम्मेदार हैं।
- क्या उपभोग प्रवाह सब्सक्रिप्शन के लिए काम करता है या केवल consumables के लिए?
- दोनों के लिए, WWDC24 के बाद से। CONSUMPTION_REQUEST अब किसी consumable इन-ऐप खरीद या किसी auto-renewable सब्सक्रिप्शन के लिए सक्रिय होता है। auto-renewable सब्सक्रिप्शन के लिए Apple स्वयं उपभोग की गणना करता है और आनुपातिक प्राथमिकता स्वीकार नहीं करता, इसलिए आपका प्रभाव उस consumable की तुलना में संकरा है जिसके उपयोग को आप सीधे बता सकते हैं।
स्रोत और आगे की जानकारी
- Apple Developer: Send Consumption Information (12-hour window, informs refund decisions)
- Apple Developer: ConsumptionRequest (the request body fields)
- Apple Developer: refundPreference (one of a variety of factors)
- Apple Developer: customerConsented (consent is required)
- Apple Developer: notificationType (CONSUMPTION_REQUEST covers subscriptions)
- Google Play Developer API: Method orders.reviewrefund (24-hour chargeback review)
RefundHalt
App Store और Google Play के लिए refund ऑटोपायलट
आगे पढ़ें
हर Google Play खरीद पर एक obfuscated account id लगाएं, वरना चार्जबैक आने पर उसे ट्रेस करने का कोई तरीका नहीं बचता
Google Play आपको हर खरीद पर एक स्थिर, हैश किया हुआ id अंकित करने देता है और विवाद आने पर उसे वापस पढ़ता है। इसे सेट करें और एक चार्जबैक समीक्षा ठीक उसी उपयोगकर्ता से जुड़ जाती है जिसका उपयोग आपको रिपोर्ट करना है। इसे छोड़ दें और आप 24 घंटे की घड़ी के तहत एक अकेले order id को अनुमानों से मिलाते रह जाते हैं।
बैंक स्टेटमेंट पर एक न पहचाना गया शुल्क चार्जबैक बन जाता है, और एक चार्जबैक आपको रिफंड से ज़्यादा महंगा पड़ता है
जब कोई ग्राहक यह नहीं बता पाता कि आपके ऐप ने उससे किस चीज़ का शुल्क लिया, तो वह आपके बजाय बैंक को कॉल करता है, और वह विवाद एक चार्जबैक के रूप में सामने आता है। Apple सब कुछ apple.com/bill के रूप में दिखाता है और आपको कुछ भी बदलने नहीं देता। Google Play आपको स्टेटमेंट नाम सेट करने देता है। यहाँ बताया गया है कि हर एक की क्या लागत है और आप किस पर नियंत्रण रखते हैं।