रिफंड रिक्वेस्ट को हैंडल करने के ज़्यादातर गाइड notification से शुरू होते हैं। Apple आपको पिंग करता है, Google आपको पिंग करता है, यहाँ बताया गया है कि क्या जवाब भेजना है। ठीक है, लेकिन जब तक पिंग पहुँचता है, तब तक असली काम या तो हो चुका होता है या छूट चुका होता है, क्योंकि किसी खरीद के बारे में आप जो कह सकते हैं, वह इस बात पर निर्भर करता है कि जब वह घटना हुई थी, तब आपने क्या दर्ज किया था।
तो यह पोस्ट पहले से, यानी checkout से शुरू होती है। जब रिफंड रिक्वेस्ट आती है तो कौन-सा खरीद डेटा महत्वपूर्ण होता है, उसे कहाँ रखें, और वह किस तरह ऐसे जवाब में बदलता है जिसे स्टोर वास्तव में तौलेगा। अगर आपने कभी किसी खरीद के साथ identifier अटैच नहीं किया है, तो पहले हमारी appAccountToken और refund defense पर लिखी पोस्ट पढ़ें, क्योंकि नीचे दी गई हर बात यह मानकर लिखी गई है कि आप किसी transaction ID को किसी व्यक्ति से जोड़ सकते हैं।
मुख्य बातें
Apple और Google दोनों रिफंड का फैसला खुद लेते हैं, और दोनों अब पहले आपसे खरीद डेटा माँगते हैं। Apple आपको 12 घंटे देता है, Google 24।
स्टोर को detailed logs नहीं, बल्कि सीधे-सादे facts चाहिए। क्या वह deliver हुआ, कितना इस्तेमाल हुआ, क्या उन्हें सैंपल मिला, और आप क्या चाहेंगे।
हर खरीद के लिए आपको चार चीज़ें स्टोर करनी होती हैं: कौन, कब deliver हुआ, कब इस्तेमाल हुआ, और क्या इस account को पहले कभी रिफंड दिया गया है।
Apple कहता है कि ज़्यादातर रिफंड रिक्वेस्ट खरीद के 30 दिनों के भीतर आती हैं। डेटा कम से कम उतने समय तक रखें, वास्तविकता में 90 दिन।
जो ऐप्स जवाब देना शुरू करते हैं, उनकी refund rate लगभग एक-तिहाई तक घट जाती है, लेकिन केवल तभी जब फाइल में कहने लायक कुछ दर्ज हो।
स्टोर वास्तव में आपसे क्या माँगते हैं
Apple की रिक्वेस्ट छोटी होती है। जब कोई कस्टमर किसी in-app purchase पर रिफंड माँगता है, तो आपको एक CONSUMPTION_REQUEST मिलता है, और आप Send Consumption Information endpoint के ज़रिए पाँच फ़ील्ड के साथ जवाब देते हैं। क्या कस्टमर ने आपको डेटा शेयर करने की सहमति दी थी, क्या खरीद deliver हुई थी, कितना प्रतिशत इस्तेमाल हुआ (milliunits में, यानी 100,000 का मतलब पूरा इस्तेमाल), क्या उन्हें पहले कोई फ्री सैंपल या ट्रायल मिला था, और आपकी refund preference। पहले Apple एक दर्जन फ़ील्ड माँगता था और उसने उनमें से ज़्यादातर हटा दिए, जिसे मैं इस तरह देखता हूँ कि Apple ने तय कर लिया है कि वह कस्टमर की history को आपसे बेहतर जानता है।
Google का वर्ज़न chargebacks के लिए है, और यह थोड़ा ज़्यादा विस्तृत है। एक pending refund review notification Real-time Developer Notifications के ज़रिए एक token के साथ आता है। आप उस token, same sample-content flag, DECLINE, APPROVE या NEUTRAL की preference, एक optional consumption percentage, और timestamps के साथ 1,000 तक usage events के साथ orders.reviewrefund पर पोस्ट करते हैं। यह अब और ज़्यादा मायने रखता है क्योंकि Google 3 अगस्त, 2026 के बाद के orders पर chargebacks के लिए डेवलपर्स से चार्ज लेता है।
कोई भी स्टोर आपका analytics export नहीं चाहता। उन्हें delivery, consumption, sampling और preference चाहिए, और बाकी जो भी आप स्टोर करते हैं, वह इसी काम के लिए है कि इन्हें सही और तेज़ी से भरा जा सके।
रिफंड के लिए purchase history: क्या रखें और कितने समय तक
न्यूनतम आवश्यकता:
checkout पर एक identifier। Apple पर appAccountToken, Google पर obfuscatedAccountId। इसके बिना, रिफंड रिक्वेस्ट में सिर्फ transaction का नाम होता है और आपको पता ही नहीं चलता कि यह किसका है। Apple के engineers यह भी सुझाव देते हैं कि हर यूज़र के लिए कम से कम एक originalTransactionId रखें, क्योंकि इनमें से किसी एक की मदद से आप Get Transaction History कॉल कर सकते हैं और उस कस्टमर की अपने ऐप में पूरी purchase history निकाल सकते हैं, चाहे उनके पास ऐप अभी इंस्टॉल हो या न हो।
एक delivery record। जब आपने coins दिए या level अनलॉक किया, उसका timestamp और नतीजा। अगर delivery फेल हुई, तो यह साफ-साफ बताएँ। यही वह एक मामला है जहाँ आपको चाहना चाहिए कि रिफंड दिया जाए, और इसके विपरीत दावा करने से आपकी वह credibility खत्म होती है जिसकी बाद में ज़रूरत पड़ेगी।
Consumption events। हर tap नहीं, बल्कि सिर्फ वे जो यह बताते हैं कि खरीद का इस्तेमाल हुआ: coins खर्च हुए, chapter खोला गया, export चलाया गया। Google इनमें से एक हज़ार तक ले लेगा। Apple को सिर्फ एक percentage चाहिए, लेकिन आप वह percentage कभी नहीं निकाल सकते जिसे आपने दर्ज ही नहीं किया।
हर product के लिए एक sample flag। क्या इस कस्टमर को trial, preview या free tier मिला था? दोनों स्टोर पर एक yes या no, और लोग इसे लगातार भूल जाते हैं।
account पर पहले के रिफंड। Apple वैसे भी रिफंड history को खुद तौलता है, लेकिन अपने rules के लिए आपको भी इसकी ज़रूरत होगी।
retention के मामले में, Apple ने कहा है कि ज़्यादातर रिफंड रिक्वेस्ट 30 दिनों के भीतर आती हैं और consumption data को उसी के अनुसार स्टोर करना चाहिए। हम 90 दिन रखते हैं, एक वजह यह है कि Google chargebacks इससे भी ज़्यादा देर में आ सकते हैं, और दूसरी वजह यह है कि storage सस्ता है जबकि memory के आधार पर दलील देना नहीं।
purchase history रिफंड में कैसे मदद करती है
एक बार यह सब तैयार हो जाने पर, रिक्वेस्ट एक judgment call नहीं रहती, बल्कि एक lookup बन जाती है।
Deliver हुआ, पूरा इस्तेमाल हुआ, कोई सैंपल नहीं, पहले कोई रिफंड नहीं: यह DECLINE का मामला है। Deliver हुआ, लगभग इस्तेमाल ही नहीं हुआ, एक दिन के भीतर रिक्वेस्ट आई: GRANT_FULL की लागत कम है और वरना बात छोटी लगने लगती है। आपकी तरफ से delivery फेल हुई: रिफंड दें और bug ठीक करें। कई हफ्तों में थोड़ा-थोड़ा इस्तेमाल हुआ: Apple के पास इसके लिए GRANT_PRORATED है, और Google पर consumption percentage यही काम करता है।
आँकड़े भी इसकी पुष्टि करते हैं। Dipsea, एक subscription audio app, ने 2024 के अंत में Apple की रिक्वेस्ट का जवाब देना शुरू किया और इसकी refund rate लगभग दो हफ्तों में 3 प्रतिशत से 1.9 प्रतिशत हो गई। chargebacks के मामले में, Appcharge ने PocketGamer को बताया कि बिना सहायता वाले disputes 20 से 30 प्रतिशत समय जीतते हैं, जबकि evidence-backed disputes 80 प्रतिशत से ज़्यादा समय जीतते हैं। Refund Sensor पर मौजूद 800 से ज़्यादा ऐप्स में, 77 प्रतिशत eligible रिक्वेस्ट का सफलतापूर्वक बचाव किया गया है, और जो हम हारते हैं उनमें ज़्यादातर मामलों में कुछ भी दर्ज नहीं था।
purchase history यह नहीं करती कि आपको वे दलीलें जिताए जो आपको जीतनी ही नहीं चाहिए। अगर कस्टमर का डेटा बताता है कि उन्होंने ऐप सिर्फ एक बार खोला, तो ईमानदार जवाब रिफंड देना ही है।
समय सीमा के भीतर रिफंड रिक्वेस्ट को कैसे प्रोसेस करें
दोनों स्टोर पर रिफंड रिक्वेस्ट process की एक समय सीमा होती है, इसलिए यह judgment से ज़्यादा plumbing का काम है। notification आपके रजिस्टर किए हुए endpoint पर पहुँचता है। आप signature verify करते हैं, transaction ID निकालते हैं, यूज़र की delivery और consumption rows देखते हैं, percentage निकालते हैं, पहले से लिखे rule से preference चुनते हैं, और भेज देते हैं। आपने क्या और कब भेजा, यह लॉग करें, फिर नतीजे का इंतज़ार करें, जो Apple पर REFUND या REFUND_DECLINED notification के रूप में आता है। REFUND की स्थिति में, उसी घंटे access वापस ले लें, क्योंकि जो कस्टमर रिफंड पाने के बाद भी content रखता है, वह अक्सर दोबारा ऐसा करने आता है।
दो चीज़ें लोगों को अक्सर अटकाती हैं। Consent: Apple submission तब तक स्वीकार नहीं करता जब तक customerConsented true न हो, इसलिए usage data शेयर करने की अनुमति पहली रिक्वेस्ट आने से पहले ही आपकी terms में होनी चाहिए। और timing: घड़ियाँ weekends के लिए नहीं रुकती हैं, और रिक्वेस्ट का एक बड़ा हिस्सा रातभर में आता है। रिफंड रिक्वेस्ट मैनेजमेंट का ज़्यादातर काम यह सुनिश्चित करना है कि कुछ-न-कुछ हमेशा जागता रहे। हमारी Apple refund request management गाइड operational पहलू पर और गहराई से बताती है।
डेवलपर्स के लिए refund processing software, या अपना खुद का कोड
एक backend टीम के साथ, ऊपर बताई गई pipeline एक हफ्ते का काम है और फिर एक लगातार चलने वाली ज़िम्मेदारी, और यही ज़िम्मेदारी असली खर्च है।
अगर आप RevenueCat या Adapty इस्तेमाल करते हैं, तो दोनों अपने SDK द्वारा पहले से इकट्ठे किए गए usage data से Apple के consumption requests का जवाब देते हैं, और Adapty Google का review भी कवर करता है। अगर SDK वैसे भी ऐप में है, तो यह एक सही default विकल्प है।
Refund Sensor बिना किसी SDK के यही काम करता है। आप एक App Store Connect API key और एक notifications URL कनेक्ट करते हैं, और यह रिक्वेस्ट प्राप्त करता है, समय सीमा के भीतर जवाब भेजता है, और हर case के लिए एक timeline रखता है। Setup में कुछ मिनट लगते हैं और pricing flat है। विवरण Refund Sensor की साइट पर मौजूद है।
आप कुछ भी चुनें, कुछ न चुनने के विकल्प को मिलाकर भी, data layer आपकी ही ज़िम्मेदारी है। डेवलपर्स के लिए कोई भी refund processing software वह delivery record नहीं बना सकता जो आपने रखा ही नहीं।
निष्कर्ष
Refund defense को आम तौर पर एक response की समस्या के रूप में देखा जाता है, लेकिन असल में यह एक recording की समस्या का नतीजा है। स्टोर चार सीमित सवाल पूछते हैं, और क्या आप उनका जवाब दे सकते हैं, यह उन फैसलों पर निर्भर करता है जो आपने checkout और delivery के समय लिए थे, यह उससे बहुत पहले की बात है कि किसी को अपना पैसा वापस चाहिए था।
एक identifier अटैच करें, delivery और consumption को timestamps के साथ रिकॉर्ड करें, samples को flag करें, और सब कुछ 90 दिनों तक रखें। यह सब तैयार होने पर, रिफंड रिक्वेस्ट को कैसे प्रोसेस करें, यह सिर्फ एक rule और एक cron job बन जाता है, और refund rate खुद-ब-खुद संभल जाती है।
अक्सर पूछे जाने वाले प्रश्न
Apple आपको CONSUMPTION_REQUEST मिलने के 12 घंटे के भीतर जवाब देने का समय देता है। Google किसी chargeback के लिए pending refund review notification मिलने के 24 घंटे के भीतर जवाब देने का समय देता है। यदि आप यह समय चूक जाते हैं, तो दोनों स्टोर आपके बिना फैसला ले लेते हैं।
पाँच फ़ील्ड: customer consent, delivery status, milliunits में consumption percentage, क्या कोई सैंपल दिया गया था, और आपकी refund preference। account tenure और lifetime spend जैसे पुराने फ़ील्ड अब हटा दिए गए हैं।
ज़्यादातर हाँ, और अगर आपके पास हो तो ज़्यादा विवरण भी। Google एक consumption percentage और 1,000 तक timestamped usage events लेता है, और इसके preference options DECLINE, APPROVE या NEUTRAL हैं।
Apple पर, हाँ। जब तक customerConsented true न हो, submission रिजेक्ट कर दी जाती है, इसलिए यह अनुमति रिक्वेस्ट आने से पहले ही आपकी terms में होनी चाहिए।
नहीं। दोनों स्टोर आपकी preference को सिर्फ एक इनपुट मानते हैं और दोनों के पास कस्टमर की पूरी history भी होती है। जब आपका अपना डेटा delivery fail होना या almost zero use दिखाता है, फिर भी decline करना, उन मामलों में आपकी credibility को नुकसान पहुँचाता है जो वास्तव में मायने रखते हैं।
