एक ग्राहक आपका सब्सक्रिप्शन खरीदता है, दो हफ्ते इस्तेमाल करता है, फिर Apple के पास जाकर रिफंड मांग लेता है। आपको इसका पता बाद में चलता है, आमतौर पर तब जब आपका payout थोड़ा कम दिखता है और आप तुरंत बता नहीं पाते कि क्यों। अब आपकी रेवेन्यू रिपोर्ट, आपकी entitlement टेबल और आपकी सब्सक्राइबर संख्या, तीनों थोड़ी-थोड़ी अलग कहानी कह रही हैं, और किसी को यह पता लगाना होगा कि सही कौन सी है।
अगर ऐसा महीने में एक बार होता है, तो ठीक है, नज़रअंदाज़ कर दीजिए। अगर महीने में सौ बार हो रहा है, तो यह अब rounding error नहीं रहा, यह एक leak है। App Store refund management, अपने मूल में, बस इतना अनुशासन है कि यह leak अनदेखा न रह जाए। इसे मैन्युअली करना कुछ समय तक काम करता है। फिर, आमतौर पर ठीक उसी समय जब आप बिल्कुल नहीं चाहेंगे, यह काम करना बंद कर देता है। यह ठीक कहाँ टूटता है, इस पर हमने अपने Apple refund automation ओवरव्यू में और विस्तार से लिखा है, अगर आप गहराई में जाना चाहें।
एक बात शुरू में ही साफ़ कर लेना ज़रूरी है: हर रिफंड पर अंतिम फैसला Apple का होता है, बस। यहाँ लिखी कोई भी बात इसे नहीं बदलती। यह लेख असल में उस हिस्से के बारे में है जो आपके नियंत्रण में है, और वह हिस्सा उससे कहीं बड़ा है जितना ज़्यादातर लोग मानते हैं।
मुख्य बातें
● हर App Store खरीद पर रिफंड का अंतिम फैसला Apple करता है।
● कुछ रिफंड के लिए Apple आपके सर्वर से consumption जानकारी मांगता है, जो आप दे सकते हैं।
● CONSUMPTION_REQUEST हर रिफंड पर नहीं आता, सिर्फ eligible रिफंड पर आता है।
● रिफंड का असर रेवेन्यू, entitlements और सब्सक्रिप्शन मेट्रिक्स पर पड़ता है, इसलिए मॉनिटरिंग ज़रूरी है।
● अगर access अपडेट न हो तो सब्सक्रिप्शन रिफंड से recurring revenue leak हो सकता है।
● वॉल्यूम, प्रोडक्ट और ऐप्स बढ़ने के साथ मैन्युअल हैंडलिंग टूटने लगती है।
● ऑटोमेशन आपको रिफंड पकड़ने, जवाब देने और reconcile करने में लगातार मदद करता है।
App Store Refund Management क्या है?
यह एक साधारण-से काम का थोड़ा औपचारिक नाम है: Apple रिफंड ट्रैक करें, जहाँ अनुमति हो वहाँ जवाब दें, और बाद में अपने सिस्टम को out of sync न होने दें। बस यही पूरी बात है। फैसला Apple का है, उसके इर्द-गिर्द की plumbing आपकी है, और सच कहें तो ज़्यादातर पैसा फैसले में नहीं, इसी plumbing में खोता है।
Reconcile करने वाला कदम वही है जिसे लोग छोड़ देते हैं, और यही वह कदम है जो सचमुच हर रिफंड पर लागू होता है, चाहे उस पर आपत्ति की गई हो या नहीं। अगर रिफंड हो जाता है और आपकी तरफ से कोई access अपडेट नहीं करता, तो अब आप ऐसे ग्राहक को सेवा देने का खर्च उठा रहे हैं जिसे पैसा पहले ही वापस मिल चुका है। यह कोई काल्पनिक बात नहीं है, अगर कोई नज़र नहीं रख रहा तो यही डिफ़ॉल्ट नतीजा है।
Apple की रिफंड प्रक्रिया कैसे काम करती है?
संक्षेप में: शुरू से अंत तक यह Apple की प्रक्रिया है। आप इसमें भागीदार हैं, फैसला लेने वाले नहीं, और सच कहें तो इसे जानबूझकर ऐसा बनाया गया है, आप ग्राहक के पैसे या उसके असली रिफंड अनुरोध को कभी छूते ही नहीं। आपको मिलती है visibility, और कभी-कभी अपनी बात रखने का मौका।
मोटे तौर पर, यह ऐसे चलता है:
● कोई ऐप, in-app purchase या सब्सक्रिप्शन खरीदता है।
● वह Apple की अपनी प्रक्रिया के ज़रिए Apple से रिफंड मांगता है, आपसे नहीं।
● Apple उसकी समीक्षा करता है।
● अगर खरीद eligible है, तो Apple आपके सर्वर को CONSUMPTION_REQUEST भेज सकता है।
● अगर लागू हो, तो आप consumption जानकारी वापस भेज सकते हैं।
● Apple फैसला करता है। उसके बाद server notifications से आप अपने रिकॉर्ड अपडेट कर सकते हैं।
हर रिफंड के साथ आपकी राय नहीं मांगी जाती, बहुत से रिफंड पूरी तरह Apple की तरफ ही तय हो जाते हैं, आपको कोई संकेत मिले बिना। फैसला हो जाने के बाद, App Store Server Notifications ही वह ज़रिया हैं जिनसे आपका backend अपडेट होता है। और अगर आप देखना चाहते हैं कि ग्राहक की तरफ से यह कैसा दिखता है, तो Apple का अपना रिफंड सपोर्ट पेज इसे समझाता है।
App Store रिफंड से रेवेन्यू का नुकसान क्यों होता है?
सीधी बात है, रिफंड उस पैसे को वापस खोल देता है जिसे आप पहले ही earned मान चुके थे। यह gross और net दोनों रेवेन्यू से घटता है। खासकर सब्सक्रिप्शन पर यह one-off से भी बुरा है, क्योंकि आप सिर्फ वह एक भुगतान नहीं खो रहे, अक्सर उसके ऊपर वे renewals भी खो रहे हैं जिन्हें आप पहले ही forecast में गिन चुके थे। फिर बाद की सफाई अलग, जिसके लिए कोई समय बजट नहीं करता लेकिन जो हमेशा कुछ समय लेती ही है।
एक फर्क जो लोगों को लगातार उलझाता है: रिफंड, cancellation, chargeback और billing failure चार अलग चीज़ें हैं, और ये आपके खातों पर चार अलग तरीकों से असर डालती हैं।
● Refund: पैसा वास्तव में वापस जाता है, और यह आपके दर्ज किए गए रेवेन्यू को घटाता है।
● Cancellation: आगे के renewals रोकता है। पिछले भुगतान वहीं के वहीं रहते हैं।
● Chargeback: बैंक से शुरू होता है, Apple के ज़रिए बिल्कुल नहीं।
● Billing failure: एक renewal जो बस... हो ही नहीं पाता।
हम लगातार देखते हैं कि टीमें रिफंड को बस एक थोड़ा-सा बड़ा cancellation मान लेती हैं, और यह वाकई महंगी गलती है। रिफंड पर access तुरंत खत्म होना चाहिए। Cancellation सिर्फ अगला बिल रोकता है, व्यक्ति के पास जो उसने पहले ही खरीदा है वह अवधि खत्म होने तक रहता है। इस रेखा को धुंधला करें और आपकी entitlement टेबल चुपचाप आपके रेवेन्यू आंकड़ों से असहमत होने लगती है, और किसी के ध्यान देने में आमतौर पर हफ्ते लग जाते हैं।
Apple रिफंड अनुरोध के दौरान डेवलपर क्या नियंत्रित कर सकते हैं?
नतीजा नहीं, वह हिस्सा तय है। आप जो नियंत्रित करते हैं: आपका notification सेटअप, आपका डेटा, और जब Apple वाकई आपको मौका देता है तब आप कैसे जवाब देते हैं। आप notification की सत्यता जांच सकते हैं, उसे सही यूज़र से मिला सकते हैं, usage डेटा इकट्ठा कर सकते हैं, और Apple के पूछने पर उसकी समय-सीमा के भीतर जवाब दे सकते हैं। आप खुद रिफंड मना नहीं कर सकते, चाहे आपका डेटा कितना भी पुख्ता हो। इसे जल्दी स्वीकार कर लेना बेहतर है, क्योंकि जो नतीजा आपके हाथ में नहीं है उसके पीछे भागना इंजीनियरिंग का बहुत सारा समय बर्बाद करने का अच्छा तरीका है।
Apple Consumption Information रिफंड समीक्षा को कैसे प्रभावित कर सकती है
Consumption information मूल रूप से Apple का आपसे यह पूछना है: इस खरीद के साथ असल में हुआ क्या? क्या यह डिलीवर हुई, कितनी इस्तेमाल हुई, इस तरह की बातें। यह CONSUMPTION_REQUEST के रूप में आती है, और आप इसका जवाब Apple के Send Consumption Information endpoint के ज़रिए देते हैं। इसे उस फैसले में एक input समझें जो Apple वैसे भी लेने वाला है, कोई ऐसा lever नहीं जिसे आप खींचते हैं।
यह सिर्फ उन खरीदों पर आती है जिन्हें Apple eligible मानता है, और वह भी तभी जब कोई पहले ही रिफंड मांग चुका हो। और डेटा को सचमुच टिकना भी चाहिए, Apple यह पकड़ने में काफी अच्छा है कि आपके भेजे आंकड़े ग्राहक के दावे से मेल नहीं खाते, इसलिए लापरवाह या generic जवाबों से आपको ज़्यादा फायदा नहीं होता।
App Store सब्सक्रिप्शन रिफंड रेवेन्यू को कैसे प्रभावित करते हैं
सब्सक्रिप्शन इसे सामान्य रिफंड से बदतर बना देते हैं, बस इसलिए कि यह पैसा शुरू से ही एक बार का नहीं था। एक अकेला सब्सक्रिप्शन रिफंड एक भुगतान मिटा सकता है, entitlement खत्म कर सकता है, और वह हर renewal रद्द कर सकता है जिसे आप पहले ही अपने forecast में लिख चुके थे। यह "हमने एक बिक्री खोई" नहीं है। यह "हमने recurring revenue का वह हिस्सा खोया जिस पर हम महीनों से भरोसा कर रहे थे" है। फाइनेंस टीम के साथ यह बिल्कुल अलग बातचीत है।
यहीं पर मॉनिटरिंग सचमुच अपनी कीमत वसूल करती है। रिफंड इवेंट छूट जाए, तो सब्सक्राइबर के पास अक्सर access बना रहता है, और इस बीच आपका dashboard उसे अब भी paying, active यूज़र गिन रहा होता है। ऐसा कुछ सौ अकाउंट में हो जाए तो आपके lifetime-value आंकड़ों का कोई खास मतलब नहीं रह जाता।
App Store रिफंड से रेवेन्यू का नुकसान कैसे कम करें
रिफंड कभी शून्य नहीं होंगे, किसी के नहीं होते। लेकिन आप टालने लायक रिफंड घटा सकते हैं और बाकी पर access का रिसाव रोक सकते हैं। हैरानी की बात है कि रिफंड अनुरोधों की एक बड़ी संख्या किसी ठीक करने लायक चीज़ से जुड़ी होती है: अस्पष्ट pricing, उलझाने वाला trial, कोई bug जिसने प्रोडक्ट को बेकार बना दिया। पहले साधारण चीज़ें ठीक करें।
● खरीद से पहले कीमत, trial की अवधि और renewal की तारीख साफ़ दिखाएं।
● ऐसे crash और delivery bugs ठीक करें जो लोगों को रिफंड की ओर धकेलते हैं।
● eligible CONSUMPTION_REQUEST इवेंट का सटीक डेटा के साथ जवाब दें।
● रिफंड मंज़ूर होते ही access खत्म करें, उसे मुफ्त में सेवा देते न रहें।
● प्रोडक्ट के हिसाब से रिफंड के कारण ट्रैक करें ताकि आपको अनुमान नहीं, असली वजहें मिलें।
मैन्युअल Apple रिफंड मैनेजमेंट मुश्किल क्यों हो जाता है
कम वॉल्यूम पर इसे हाथ से करना वाकई ठीक है, एक व्यक्ति queue देखता है, जवाब देता है, आगे बढ़ जाता है। परेशानी तब शुरू होती है जब रिफंड इतनी तेज़ी से आने लगते हैं कि एक व्यक्ति के लिए साथ चलना मुमकिन नहीं रहता, और वे शालीनता से ऑफिस के घंटों में भी नहीं आते। CONSUMPTION_REQUEST को इससे फर्क नहीं पड़ता कि रविवार की रात के 3 बजे हैं। वह बस एक घड़ी चालू कर देता है, और वह घड़ी किसी के लिए नहीं रुकती।
● ज़्यादा purchase वॉल्यूम और बार-बार आने वाले रिफंड अनुरोध।
● कई सब्सक्रिप्शन प्रोडक्ट और कई ऐप्स।
● Server notifications जिन्हें कोड में verify करना पड़ता है।
● eligible Apple अनुरोधों पर समय-सीमा में जवाब।
● इवेंट मिलाते समय खंगालने के लिए बड़ी transaction histories।
App Store Refund Management सॉफ़्टवेयर कैसे मदद कर सकता है
सॉफ़्टवेयर यहाँ असल में आपको जो देता है वह है consistency, न intelligence, न strategy, बस हर बार बिना चूके हाज़िर रहना। यह रिफंड इवेंट पर नज़र रख सकता है, transactions को आपस में जोड़ सकता है, consumption डेटा इकट्ठा कर सकता है, deadline पर नज़र रख सकता है, जो हुआ उसे log कर सकता है, और रेवेन्यू पर चोट पड़ने पर flag कर सकता है। इनमें से किसी के लिए रात 2 बजे किसी व्यक्ति का dashboard देखते रहना ज़रूरी नहीं।
यही वह इलाका है जहाँ Apple refund management tools और Apple refund automation रहते हैं। इनमें से किसी एक को अपनाने का तर्क सच कहें तो गणित पर टिकता है, जब छूटी हुई समय-सीमाएं या बना रहा access टूल से ज़्यादा महंगे पड़ने लगें, तो टूल जीत जाता है। RefundSensor वह विकल्प है जो हमने बनाया है, और यह App Store और Google Play दोनों को कवर करता है। पूरी ईमानदारी से: हम यहाँ निष्पक्ष नहीं हैं। लेकिन अपने प्रोडक्ट के बारे में हम वही कहेंगे जो किसी और के बारे में कहते, कोई भी सॉफ़्टवेयर आपके लिए Apple का फैसला नहीं करता, और जो कोई ऐसा जताता है वह बढ़ा-चढ़ाकर बेच रहा है।
मैन्युअल रिफंड मैनेजमेंट | ऑटोमेटेड रिफंड मैनेजमेंट |
एक व्यक्ति जब मौका मिले तब इवेंट देखता है | इवेंट होते ही ट्रैक हो जाते हैं |
रात में आए अनुरोध छूट सकते हैं | चौबीसों घंटे चलता है |
Transactions हाथ से मिलाए जाते हैं | Transactions अपने आप मिल जाते हैं |
जवाब की समय-सीमा आसानी से छूट जाती है | जवाब समय-सीमा के भीतर दर्ज होते हैं |
Access और रिकॉर्ड मैन्युअली अपडेट होते हैं | Entitlements sync में रहते हैं |
मोबाइल ऐप रेवेन्यू को रिफंड से कैसे बचाएं
तीन चीज़ें, साथ मिलकर: पहले तो टालने लायक रिफंड कम होना, जो होते हैं उन्हें पकड़ना, और बाद में तेज़ी से सफाई करना। इनमें से कोई एक छोड़ दें तो बाकी दो आपको आधे रास्ते तक ही ले जाएंगी।
App Store रिफंड का चरण | क्या होता है |
अनुरोध दर्ज | ग्राहक Apple से रिफंड मांगता है, अभी कुछ नहीं, कोई संकेत नहीं भेजा जाता |
समीक्षा | Apple अनुरोध का मूल्यांकन करता है, अगर CONSUMPTION_REQUEST आए तो जवाब दें |
फैसला | Apple मंज़ूर या अस्वीकार करता है, आपके लिए कुछ करने को नहीं, Apple तय करता है |
नतीजा | रिफंड प्रोसेस होता है, access और रेवेन्यू रिकॉर्ड अपडेट करें |
असली बात: आप रिफंड को पूरी तरह रोकने की कोशिश नहीं कर रहे। आप यह पक्का कर रहे हैं कि किसी ऐसे रिफंड से आपका पैसा कभी न जाए जिस पर आपकी नज़र ही नहीं पड़ी।
अंतिम विचार
रिफंड Apple के ज़रिए बेचने का हिस्सा हैं, यह बदलने वाला नहीं है, और इससे लड़ना असल में लक्ष्य भी नहीं है। जो ठीक करने लायक है वह है चुपचाप होने वाली चीज़ें: वह रिफंड जो किसी ने नहीं पकड़ा, वह access जो पैसा जा चुकने के बाद भी चलता रहा। यह Apple की समस्या नहीं है। यह operations की समस्या है, और इसका जवाब काफी साधारण और ठीक करने लायक है।
जो टाला जा सकता है उसे घटाएं, जो नहीं टल सकता उस पर नज़र रखें, सब कुछ reconcile करें। इसे हाथ से करें या किसी ऑटोमेटेड सिस्टम को सौंप दें, लक्ष्य किसी भी तरह नहीं बदलता: जो आपने सचमुच कमाया है उसे रखें, और सिर्फ वही लौटाएं जो वाकई देना बनता है।
ये नियम कहाँ दर्ज हैं
ऊपर की हर तकनीकी बात Apple के अपने दस्तावेज़ों पर आधारित है, हमारी व्याख्या पर नहीं:
● Apple Support: ऐप्स या कंटेंट के लिए रिफंड का अनुरोध करें
अक्सर पूछे जाने वाले प्रश्न
Apple के ज़रिए, डेवलपर के ज़रिए नहीं। reportaproblem.apple.com पर जाएं, या अपनी purchase history में Report a Problem का इस्तेमाल करें, आइटम चुनें, कारण बताएं, सबमिट करें। आगे का काम Apple संभालता है। इसके लिए डेवलपर की तरफ से कोई फॉर्म नहीं होता।
Apple रिफंड को ट्रैक करने, जहाँ संभव हो जवाब देने, और बाद में अपने access और रेवेन्यू रिकॉर्ड को सही रखने की प्रक्रिया। फैसला Apple का है; उसके इर्द-गिर्द की हर चीज़ आपकी है।
नहीं, यह पूरी तरह Apple का है। आप eligible खरीदों के लिए consumption डेटा भेज सकते हैं और अपने सिस्टम को नतीजे के साथ sync रख सकते हैं, लेकिन रिफंड मंज़ूर या अस्वीकार करना डेवलपर का काम नहीं है।
ग्राहक के बताए कारण, उसके अकाउंट के इतिहास और अपने आंतरिक संकेतों के आधार पर, साथ ही कुछ eligible खरीदों के लिए वह consumption डेटा जो आप CONSUMPTION_REQUEST के जवाब में भेजते हैं।
एक App Store Server Notification जो Apple तब भेजता है जब कोई eligible खरीद पर रिफंड मांगता है। इसमें आपके सर्वर से usage और delivery की जानकारी मांगी जाती है, जिसे आप Apple की तय समय-सीमा के भीतर वापस भेजते हैं।
टाले जा सकने वाले रिफंड की वजहें ठीक करें, साफ़ pricing, कम bugs, ईमानदार trial शर्तें, और बाकी को जल्दी reconcile करें: eligible अनुरोधों का जवाब दें, रिफंड होते ही access काटें, और प्रोडक्ट के हिसाब से ट्रैक करें कि रिफंड क्यों हो रहे हैं।
हाँ। यह एक दोहराया जाने वाला workflow है, जिसे ऑटोमेशन अच्छे से संभालता है, इवेंट मॉनिटर करना, notifications verify करना, transactions मिलाना, समय पर जवाब देना। हालांकि यह इस बात को नहीं छूता कि फैसला कौन करता है। वह हमेशा Apple होता है।
गतिविधि मॉनिटर करना, transactions मिलाना, consumption डेटा इकट्ठा करना, deadlines पर नज़र रखना, नतीजे log करना, रेवेन्यू पर असर flag करना। जो यह नहीं कर सकता, वह है आपके लिए Apple का फैसला लेना या किसी खास नतीजे का वादा करना, इसकी असली कीमत consistency में है, control में नहीं।
