संक्षिप्त जवाब: जब कोई ग्राहक इन-ऐप परचेज़ या सब्सक्रिप्शन पर Apple से रिफंड मांगता है, तो App Store आपके सर्वर को एक CONSUMPTION_REQUEST नोटिफिकेशन भेजता है और आपको Send Consumption Information एंडपॉइंट के ज़रिए कंज़म्पशन डेटा के साथ जवाब देने के लिए लगभग 12 घंटे देता है। Apple अपने फैसले में उस डेटा को तौलता है। अगर आप समय पर जवाब नहीं देते, तो Apple आपके इनपुट के बिना फैसला ले लेता है, और अनुचित रिफंड अक्सर डिफ़ॉल्ट रूप से मंज़ूर कर दिए जाते हैं। इस जवाब को ऑटोमेट करने का मतलब है कि हर रिक्वेस्ट का जवाब हर बार विंडो के भीतर दिया जाता है।
संक्षिप्त सार
पेमेंट रेल्स पर Apple का मालिकाना हक है। जब कोई आपके ऐप में सब्सक्रिप्शन या इन-ऐप परचेज़ खरीदता है, तो Apple पैसे इकट्ठा करता है, अपना हिस्सा रखता है, और रिफंड को संभालता है। सालों तक डेवलपर्स की रिफंड फैसलों में कोई राय ही नहीं होती थी।
यह बदल गया है। अब Apple आपको कंज़म्पशन इंफॉर्मेशन भेजने देता है, यानी ग्राहक ने जो खरीदा उसे कैसे इस्तेमाल किया इसका स्ट्रक्चर्ड सबूत, और इसे रिफंड फैसले में शामिल करता है। आप खुद रिफंड को मंज़ूर या अस्वीकार नहीं कर सकते; अंतिम फैसला अब भी Apple ही लेता है। लेकिन चुप्पी से Apple के पास काम करने के लिए कुछ नहीं बचता, जबकि एक अच्छी तरह से तैयार किया गया जवाब उसे संदर्भ देता है।
दिक्कत टाइमिंग और निरंतरता की है। रिफंड विंडो छोटी होती है, apple refund response time सीमित होता है, यह अप्रत्याशित समय पर शुरू होती है, और किसी भी वास्तविक वॉल्यूम पर इसे मैनुअली करना असंभव है। यही वह समस्या है जिसे ऑटोमेशन हल करता है।
Apple का रिफंड फ्लो असल में कैसे काम करता है
यहां पूरी प्रक्रिया, शुरू से अंत तक दी गई है:
ग्राहक रिफंड का अनुरोध करता है। वे reportaproblem.apple.com पर जाते हैं, परचेज़ चुनते हैं, एक कारण चुनते हैं, और सबमिट करते हैं।
Apple आपके सर्वर को सूचित करता है। योग्य परचेज़ेज़ के लिए, App Store App Store Server Notifications V2 के ज़रिए एक CONSUMPTION_REQUEST नोटिफिकेशन भेजता है। पेलोड में परचेज़ की पहचान करने वाला साइन किया हुआ ट्रांज़ैक्शन डेटा होता है।
आप कंज़म्पशन डेटा के साथ जवाब देते हैं। आप ओरिजिनल ट्रांज़ैक्शन ID और डिलीवरी, यूसेज, कंसेंट, और अपनी रिफंड प्रेफरेंस बताने वाली एक स्ट्रक्चर्ड ConsumptionRequest बॉडी के साथ Send Consumption Information को कॉल करते हैं।
Apple फैसला लेता है। इसका रिफंड डिसीज़निंग सिस्टम आपके डेटा को ग्राहक के इतिहास और अन्य कारकों के साथ तौलता है, फिर एक फैसला जारी करता है।
आपको नतीजे की सूचना दी जाती है। एक REFUND नोटिफिकेशन का मतलब है कि रिफंड मंज़ूर हो गया; एक REFUND_DECLINED नोटिफिकेशन (StoreKit API के ज़रिए शुरू की गई रिक्वेस्ट्स के लिए) का मतलब है कि नहीं हुआ।
एक CONSUMPTION_REQUEST में क्या होता है, और आप जवाब में क्या भेजते हैं
नोटिफिकेशन खुद साइन किया हुआ ट्रांज़ैक्शन इंफो और ग्राहक द्वारा बताया गया कारण (consumptionRequestReason) लेकर आता है। असली काम आपके जवाब में होता है। Apple फील्ड्स के साथ एक स्ट्रक्चर्ड ConsumptionRequest परिभाषित करता है, जिनमें शामिल हैं:
यहां आपकी इमेज से फिर से बनाई गई टेबल दी गई है:
फील्ड | यह Apple को क्या बताता है |
customerConsented | क्या ग्राहक ने यह डेटा शेयर करने पर सहमति दी थी। यह true होना चाहिए, नहीं तो Apple सबमिशन को अस्वीकार कर देता है। |
consumptionStatus | क्या खरीदा गया कंटेंट इस्तेमाल नहीं किया गया, आंशिक रूप से इस्तेमाल किया गया, या पूरी तरह इस्तेमाल किया गया। |
deliveryStatus | क्या इन-ऐप वैल्यू या सर्विस वास्तव में डिलीवर की गई थी। |
accountTenure | ग्राहक का आपके साथ कितने समय से अकाउंट है। |
playTime | ग्राहक ने ऐप में कितना समय बिताया है। |
lifetimeDollarsPurchased | ग्राहक ने आपके ऐप्स पर कुल कितना खर्च किया है। |
lifetimeDollarsRefunded | ग्राहक को पहले कुल कितना रिफंड किया जा चुका है। |
sampleContentProvided | क्या ग्राहक खरीदने से पहले कंटेंट आज़मा सकता था। |
userStatus | ग्राहक के अकाउंट की मौजूदा स्थिति (एक्टिव, सस्पेंडेड, आदि)। |
refundPreference | Apple को आपकी सिफारिश: undeclared, prefer grant, या prefer decline। |
Apple को आपकी सिफारिश: undeclared, prefer grant, या prefer decline।
हर फील्ड एक संकेत है। खाली छोड़ने पर, यह ऐसा संदर्भ है जो Apple को कभी नहीं मिलता। हम हर फील्ड और उसके स्वीकृत वैल्यूज़ का विस्तार से विश्लेषण What Is a CONSUMPTION_REQUEST Notification? A Field-by-Field Breakdown में करते हैं।
12-घंटे की विंडो
प्रोडक्शन में CONSUMPTION_REQUEST का जवाब देने के लिए आपके पास लगभग 12 घंटे होते हैं। यह consumption_request deadline महत्वपूर्ण है क्योंकि इसे चूकने का मतलब है कि आप इनपुट देने का मौका गंवा देते हैं; Apple जो कुछ उसके पास पहले से है, उसी के आधार पर फैसला ले लेता है।
समस्या apple refund response window की लंबाई नहीं है, समस्या यह है कि यह कब शुरू होती है। रिफंड रिक्वेस्ट्स बिज़नेस ऑवर्स का इंतज़ार नहीं करतीं। रिफंड विंडो रात में, वीकेंड पर, या छुट्टी के दौरान कभी भी शुरू हो सकती है, और बिना किसी को हमेशा ऑन-कॉल रखे मैनुअल रिव्यू क्यू इसे कवर नहीं कर सकता। यही वह सबसे आम वजह है जिसके चलते डेवलपर्स ऐसे रिफंड गंवा देते हैं जिन्हें वे चुनौती दे सकते थे: यह खराब जवाब की वजह से नहीं, बल्कि जवाब न होने की वजह से होता है। हम इस पर The 12-Hour Window: Why Most Developers Lose Refunds by Default में और गहराई से बात करते हैं।
सहमति की आवश्यकता, इसे नज़रअंदाज़ न करें
यह वह हिस्सा है जिसमें लगभग सभी उलझ जाते हैं, और यह सिर्फ एक तकनीकी मुद्दा नहीं बल्कि एक कानूनी मुद्दा है।
Apple का CONSUMPTION_REQUEST आपको यह नहीं बताता कि ग्राहक ने अपना डेटा शेयर करने की सहमति दी है या नहीं। यह जानबूझकर किया गया है, Apple चाहता है कि किसी भी कंज़म्पशन डेटा को भेजने से पहले सहमति इकट्ठा करने और उसकी पुष्टि करने का काम आपका ऐप करे, न कि आपका सर्वर। आपको अपने API कॉल में customerConsented को true सेट करना होगा, और आप, डेवलपर, वैध सहमति प्राप्त करने के लिए पूरी तरह ज़िम्मेदार हैं, क्योंकि आप ही वह हैं जो यूज़र से इकट्ठा किया गया डेटा शेयर कर रहे हैं।
अगर आप इसमें गलती करते हैं, तो सिर्फ सबमिशन के अस्वीकार होने का जोखिम नहीं है, बल्कि GDPR या DPDP कंप्लायंस की समस्या का भी जोखिम है। किसी भी चीज़ को ऑटोमेट करने से पहले अपने ऐप की टर्म्स और परचेज़ फ्लो में सहमति को सही तरीके से संभालें। हम बताते हैं कि इसे बिल्कुल कहां और कैसे करना है, Customer Consent & the Consumption API: What Apple Actually Requires में।
इसे ऑटोमेट करने में वास्तव में क्या लगता है
कागज़ पर, जवाब को ऑटोमेट करना एक वीकेंड प्रोजेक्ट जैसा लगता है: नोटिफिकेशन पकड़ो, फील्ड्स भरो, एंडपॉइंट को कॉल करो। प्रोडक्शन में, यह इन्फ्रास्ट्रक्चर का एक स्थायी हिस्सा है, और वास्तव में इसमें क्या-क्या शामिल है यह समझना ही "हम इसे बनाएंगे" और "हम इसे छोड़ देंगे" के बीच का फर्क है।
एक भरोसेमंद इन-हाउस रिस्पॉन्डर को Apple के साइन किए गए नोटिफिकेशंस को प्राप्त करना और वेरिफाई करना होता है, रिक्वेस्ट आते ही हर ग्राहक के लिए सटीक, अभी की यूसेज और बिलिंग डेटा निकालना होता है, उस डेटा को Apple के सटीक ConsumptionRequest वैल्यूज़ में मैप करना होता है, और इसे ~12-घंटे की apple refund response window के भीतर, किसी भी समय, बिना किसी इंसान के देखे सबमिट करना होता है। इसके अलावा इसे डेडलाइन-सेफ रीट्राई, फेल्योर हैंडलिंग, ऐसी लॉगिंग जिसे आप ऑडिट कर सकें, मॉनिटरिंग ताकि आपको पता चले अगर कुछ टूटता है, और हर बार जब Apple अपने पेलोड्स या फील्ड्स में बदलाव करता है तब निरंतर मेंटेनेंस की ज़रूरत होती है। इनमें से कुछ भी आपका प्रोडक्ट नहीं है। यह सब ऐसा इन्फ्रास्ट्रक्चर है जिसे आपको अनिश्चित काल तक बनाए रखना होगा, एक ऐसे वर्कफ्लो के लिए जिसका आपके ऐप के काम से कोई लेना-देना नहीं है। (हम नोटिफिकेशन लेयर पर और गहराई से Setting Up App Store Server Notifications V2 में बात करते हैं।)
यही वह हिसाब है जिस पर ज़्यादातर टीमें अंत में पहुंचती हैं: मैकेनिक्स को समझा जा सकता है, लेकिन एक कंप्लायंट, डेडलाइन-सेफ रिस्पॉन्डर बनाना और उसकी लगातार देखभाल करना एक स्थायी लागत है जिसका ऐप को खुद कोई फायदा नहीं होता। यह बिल्कुल उसी तरह की सामान्य, बिना-किसी-भेद वाली जरूरत है जिसके लिए एक मैनेज्ड सर्विस बनी होती है।
यही काम RefundSensor करता है। यह एक वेबहुक URL के साथ आपके App Store Connect सेटअप से जुड़ जाता है, कोई SDK नहीं, कोई कोड बदलाव नहीं, कोई ऐप री-सबमिशन नहीं, फिर हर CONSUMPTION_REQUEST का Apple की रिफंड विंडो के भीतर अपने आप जवाब देता है, आपके डेटा से फील्ड्स को मैप करता है, रीट्राई और मॉनिटरिंग को संभालता है, Apple के बदलावों के साथ अपडेट रहता है, और हर नतीजे को एक डैशबोर्ड में रिकॉर्ड करता है। Apple refund automation software ढूंढ रही टीमों के लिए, यह पूरे रिफंड-रिस्पॉन्स इन्फ्रास्ट्रक्चर को खुद बनाने और बनाए रखने की ज़रूरत को खत्म कर देता है।
क्या जवाब देने से वाकई रिफंड कम होते हैं?
हां, हालांकि नतीजे अलग-अलग होते हैं और फैसला हमेशा Apple ही लेता है। सटीक कंज़म्पशन डेटा सबमिट करने से Apple के सिस्टम को ज़्यादा संदर्भ मिलता है, और जो डेवलपर्स लगातार जवाब देते हैं उन्हें आम तौर पर उन डेवलपर्स की तुलना में कम रिफंड मंज़ूर होते दिखते हैं जो रिक्वेस्ट्स का जवाब नहीं देते। "prefer decline" सिफारिश चुनना, जहां आपके सबूत वाकई इसका समर्थन करते हैं, Apple के लिए एक और इनपुट है जिस पर वह विचार करता है।
इसलिए apple refund response time के भीतर जवाब देने से यह सुनिश्चित करने में मदद मिलती है कि Apple को consumption_request deadline से पहले आपकी जानकारी मिल जाए। यह किसी नतीजे की गारंटी नहीं देता, लेकिन यह इस बात को रोकता है कि छूट गया जवाब इस बात की वजह बने कि आपकी जानकारी पर विचार ही नहीं किया गया।
ऑटोमेशन क्या कर सकता है और क्या नहीं
इसकी सीमा के बारे में खुद से ईमानदार रहें:
यह किसी खास रिफंड के अस्वीकार होने की गारंटी नहीं दे सकता। हर बार अंतिम फैसला Apple ही लेता है।
यह उन रिफंड को चुनौती नहीं दे सकता जो कभी CONSUMPTION_REQUEST जनरेट ही नहीं करते, हर रिफंड ऐसा नहीं करता।
यह सुनिश्चित कर सकता है कि हर योग्य रिक्वेस्ट का apple refund response window के भीतर, लगातार और सटीक डेटा के साथ जवाब दिया जाए, ताकि आप कभी भी सिर्फ इसलिए रिफंड न गंवाएं क्योंकि किसी ने नोटिफिकेशन देखा ही नहीं।
यह Apple रिफंड रिक्वेस्ट्स का 12 घंटे के भीतर जवाब कैसे दें, इसे ऑटोमेट कर सकता है, जिससे consumption_request deadline चूकने का जोखिम कम हो जाता है।
आखिरी बिंदु ही असली फायदे की बात है। आप Apple के फैसले को पलट नहीं रहे, आप बस यह सुनिश्चित कर रहे हैं कि आपको हमेशा अपनी बात कहने का मौका मिले।
मैनुअल हैंडलिंग इस अंतर को क्यों नहीं भर सकती
जो टीमें इसे हाथ से संभालने की कोशिश करती हैं, वे आमतौर पर इन तीन में से किसी एक स्थिति में पहुंचती हैं:
"हम सुबह देख लेंगे" वाला तरीका — जो हर रात और वीकेंड की रिक्वेस्ट को चूक जाता है, यानी उनका एक बड़ा हिस्सा।
ऑन-कॉल रोटेशन — कोई व्यक्ति तकनीकी रूप से 24 घंटे एक 12-घंटे की विंडो वाले काम के लिए ज़िम्मेदार होता है, जो एक बहुत ही थका देने वाला काम है और फिर भी इंसानी गलती की गुंजाइश रहती है।
"हमने हार मान ली" वाला तरीका — चुपचाप बहुमत, जिसने जवाब देना बंद कर दिया क्योंकि साथ बने रहना असंभव था।
इन सबमें एक समान बात है: डेडलाइन मशीन की रफ्तार से चलती है और जवाब इंसान की रफ्तार से आता है। आप उस घड़ी को अनुशासन से हरा नहीं सकते जो आपके सोते समय भी चलती रहती है। हर मैनुअल तरीका असल में सिर्फ यह चुनना है कि कौन सी रिक्वेस्ट्स चूकनी हैं।
यह टाइमिंग की समस्या है, प्रोडक्ट की नहीं
जो नज़रिया मायने रखता है वह यह है: ये रिफंड गंवाना आपके ऐप के बारे में कुछ नहीं बताता।
आपके पास एक बेहतरीन प्रोडक्ट, खुश यूज़र्स, और वास्तविक रिफंड की एक कम दर हो सकती है, और फिर भी आप इस विंडो के ज़रिए रेवेन्यू गंवा सकते हैं क्योंकि नुकसान इस बात पर निर्भर नहीं करता कि रिफंड जायज़ था या नहीं। यह इस बात पर निर्भर करता है कि जवाब देने के लिए कोई वहां मौजूद था या नहीं। यह अजीब तरह से अच्छी खबर है। प्रोडक्ट की समस्या को ठीक करना मुश्किल होता है। टाइमिंग की समस्या का एक साफ समाधान है: यह सुनिश्चित करें कि जवाब देने के लिए कुछ न कुछ हमेशा मौजूद हो, तुरंत, चाहे कोई भी समय हो।
इसे असल में क्या ठीक करता है
मशीन की रफ्तार वाली विंडो को बंद करने वाली एकमात्र चीज़ मशीन की रफ्तार वाला जवाब है। ऑटोमेशन हर CONSUMPTION_REQUEST का जवाब आते ही देता है सटीक कंज़म्पशन डेटा और आपकी रिफंड प्रेफरेंस के साथ Apple की विंडो के भीतर, रविवार की रात 3 बजे भी उतनी ही भरोसेमंद तरीके से जितना मंगलवार की दोपहर 3 बजे।
यही काम RefundSensor करता है। यह हर रिफंड रिक्वेस्ट पर नज़र रखता है, विंडो के भीतर अपने आप जवाब देता है, और नतीजे को ट्रैक करता है, ताकि आप फिर कभी सिर्फ इसलिए रिफंड न गंवाएं क्योंकि किसी ने नोटिफिकेशन देखा ही नहीं। सेटअप में लगभग 30 मिनट लगते हैं, कोई कोड बदलाव नहीं, और यह Google Play की चार्जबैक-रिव्यू विंडो को भी कवर करता है, जिसमें वही "कभी भी शुरू हो जाती है, तेज़ी से बंद होती है" वाली समस्या है। (पूरी तस्वीर के लिए, देखें How to Automate Apple Refund Requests और Google Play Refunds & Chargebacks.)
[PRODUCT DATA PLACEHOLDER Refund Index लाइव होने के बाद यहां एक वास्तविक RefundSensor आंकड़ा डालें, जैसे बिज़नेस ऑवर्स के बाहर आने वाली रिक्वेस्ट्स का हिस्सा, या बचाई गई राशि। कोई आंकड़ा खुद से न बनाएं।]
आप Apple के साथ कोई चालाकी नहीं कर रहे। आप बस यह सुनिश्चित कर रहे हैं कि आपको हमेशा अपनी बात कहने का मौका मिले वह मौका जिसे ज़्यादातर डेवलपर्स बिना जाने-समझे गंवा देते हैं।
आधिकारिक स्रोत {#official-sources}
Apple की टाइमिंग और प्रक्रिया बदल सकती है, इसलिए इसके डॉक्यूमेंटेशन को ही अंतिम प्राधिकार मानें:
विंडो तब खुलती है जब आपके ग्राहक चाहें। फिर भी आप वहां मौजूद रहें। RefundSensor हर Apple रिफंड रिक्वेस्ट का अपने आप जवाब देता है, 12-घंटे की विंडो के भीतर सुबह 3 बजे, वीकेंड्स, छुट्टियां शामिल और हर नतीजे को ट्रैक करता है। सेटअप में लगभग 30 मिनट लगते हैं, कोई कोड बदलाव नहीं। मुफ्त में शुरू करें →
प्रकाशित होने के बाद जोड़े जाने वाले इंटरनल लिंक्स: Apple refund automation cornerstone · CONSUMPTION_REQUEST field-by-field · Google Play refunds cornerstone.
अक्सर पूछे जाने वाले प्रश्न
प्रोडक्शन में लगभग 12 घंटे, जो ग्राहक के रिक्वेस्ट सबमिट करते ही शुरू हो जाते हैं। अगर आप चूक जाते हैं, तो Apple आपके इनपुट के बिना ही फैसला ले लेता है।
Apple के पास जो जानकारी होती है, उसी के आधार पर वह आगे बढ़ता है, यानी सिर्फ ग्राहक की रिक्वेस्ट, आपकी तरफ से कुछ नहीं। बिना जवाब वाली रिक्वेस्ट्स, यहां तक कि अनुचित रिक्वेस्ट्स भी, अक्सर डिफ़ॉल्ट रूप से मंज़ूर कर दी जाती हैं।
नहीं। यह विंडो Apple द्वारा तय की जाती है। इसे हमेशा समय पर पूरा करने का एकमात्र भरोसेमंद तरीका है, रिक्वेस्ट आते ही अपने आप जवाब देना।
आमतौर पर यह मामले की योग्यता की वजह से नहीं, बल्कि समय की वजह से होता है। रिक्वेस्ट्स बिज़नेस ऑवर्स के बाहर आती हैं और मैनुअल प्रोसेस हर एक का समय पर जवाब नहीं दे पाता, इसलिए चुनौती दिए जा सकने वाले रिफंड डिफ़ॉल्ट रूप से गंवा दिए जाते हैं।
नहीं। अंतिम फैसला हमेशा Apple ही लेता है। ऑटोमेशन इस बात की गारंटी देता है कि आप हर बार जवाब दें; यह Apple के फैसले को नहीं बदलता।
