सब्सक्रिप्शन रद्द करने की वजहें आमतौर पर रिफ़ंड अनुरोध से पहले आप तक पहुँचती हैं, और Google Play इनके बारे में Apple से कहीं ज़्यादा जानकारी देता है
Google Play अपने cancel survey से सब्सक्रिप्शन रद्द करने की वजहें दर्ज करता है, जबकि Apple सिर्फ़ एक expiration code भेजता है। जानिए हर स्टोर आपको क्या बताता है, कौन से संकेत आने वाले रिफ़ंड या चार्जबैक की ओर इशारा करते हैं, और हर एक की आपको क्या कीमत चुकानी पड़ती है।
मुख्य बातें
- Google Play सब्सक्राइबर से रद्द करते समय पूछता है कि वे क्यों जा रहे हैं, और यह जवाब purchases.subscriptionsv2 में canceledStateContext.userInitiatedCancellation.cancelSurveyResult के ज़रिए डेवलपर तक पहुँचता है।
- Google Play के cancel survey में पाँच जवाब होते हैं जिन्हें डेवलपर पढ़ सकता है: पर्याप्त इस्तेमाल नहीं, तकनीकी समस्याएँ, कीमत से जुड़ी वजह, बेहतर ऐप मिल गया, और अन्य। reasonUserInput में खुला टेक्स्ट तभी आता है जब यूज़र अन्य चुनता है।
- Google Play की SUBSCRIPTION_CANCELED notification में सिर्फ़ purchase token होता है। रद्द करने की वजह purchases.subscriptionsv2.get से लानी पड़ती है, और अगर यूज़र सब्सक्रिप्शन बहाल कर दे तो Google रद्द करने से जुड़े सभी फ़ील्ड मिटा देता है।
- Apple के App Store Server API में कोई cancel survey नहीं है। इसका expirationIntent फ़ील्ड पाँच में से एक code देता है: ग्राहक ने रद्द किया, बिलिंग त्रुटि, कीमत बढ़ने या ऑफ़र रूपांतरण पर सहमति नहीं, प्रोडक्ट उपलब्ध नहीं, या अन्य।
- Apple की DID_CHANGE_RENEWAL_STATUS notification, subtype AUTO_RENEW_DISABLED के साथ, यह भी बता सकती है कि ग्राहक के रिफ़ंड माँगने के बाद App Store ने auto-renewal बंद किया, सिर्फ़ यह नहीं कि ग्राहक ने उसे बंद किया।
- रद्द करने की वजह डेवलपर को रिफ़ंड पर कोई वोट नहीं देती। सबूत सिर्फ़ दो जगह माँगा जाता है: Apple का CONSUMPTION_REQUEST, जिसका जवाब 12 घंटे में देना होता है, और orders.reviewrefund के ज़रिए Google Play का चार्जबैक रिव्यू, जिसका जवाब 24 घंटे में देना होता है।
- तकनीकी समस्याओं की वजह बताकर रद्द करने वाला Google Play सब्सक्राइबर पैसे वापस माँगने की सबसे ज़्यादा संभावना रखता है। August 3, 2026 के बाद दिए गए ऑर्डर पर अगर वह चार्जबैक जीतता है, तो डेवलपर को खरीद कीमत (Play की सर्विस फ़ीस घटाकर) और बैंक की फ़ीस चुकानी पड़ती है।
जिन सब्सक्राइबर को आख़िर में रिफ़ंड मिलता है, उनमें से ज़्यादातर पहले सब्सक्रिप्शन रद्द करते हैं। उस रद्द करने के साथ एक वजह जुड़ी होती है, और दोनों स्टोर आपको उसकी बहुत अलग मात्रा में जानकारी देते हैं। Google Play एक छोटा सर्वे चलाता है और जवाब आपके सर्वर तक भेजता है, खुले टेक्स्ट समेत। Apple एक संख्या वाला code भेजता है जो बताता है कि सब्सक्रिप्शन कैसे ख़त्म हुआ, यह नहीं कि ग्राहक क्यों जाना चाहता था। दोनों को ठीक से पढ़ें, तो आप रिफ़ंड अनुरोध को तब आते देख पाएँगे जब उसके बारे में कुछ करने का समय अभी बचा हो।
Google Play आपको सब्सक्रिप्शन रद्द करने की वजहों के बारे में क्या बताता है
जब कोई यूज़र Play subscriptions center में सब्सक्रिप्शन रद्द करता है, तो Google उससे वजह पूछता है। जवाब उस subscription resource में आता है जो आपको purchases.subscriptionsv2.get से मिलता है, canceledStateContext के अंदर। यह object सिर्फ़ तब मौजूद रहता है जब सब्सक्रिप्शन canceled या expired स्थिति में हो, और यह बताता है कि सब्सक्रिप्शन किसने ख़त्म किया: यूज़र, Google का सिस्टम, आप, या कोई replacement जैसे प्लान बदलना।
जब यूज़र ने रद्द किया हो, तो userInitiatedCancellation object में दो फ़ील्ड होते हैं। cancelTime बताता है कि उन्होंने कब रद्द किया। cancelSurveyResult में सर्वे का जवाब होता है।
| सर्वे की वजह | Google का विवरण | यह अक्सर किस ओर इशारा करता है |
|---|---|---|
| CANCEL_SURVEY_REASON_NOT_ENOUGH_USAGE | सब्सक्रिप्शन का पर्याप्त इस्तेमाल नहीं | कम इस्तेमाल, यानी अकाउंट पर कम लागत लगी |
| CANCEL_SURVEY_REASON_TECHNICAL_ISSUES | ऐप इस्तेमाल करते समय तकनीकी समस्याएँ | रिफ़ंड और चार्जबैक का सबसे मज़बूत संकेत |
| CANCEL_SURVEY_REASON_COST_RELATED | कीमत से जुड़ी समस्याएँ | कीमत को लेकर संवेदनशीलता, कभी-कभी अनचाहा renewal |
| CANCEL_SURVEY_REASON_FOUND_BETTER_APP | यूज़र को बेहतर ऐप मिल गया | प्रतिस्पर्धी जीत गया, विवाद कम ही होता है |
| CANCEL_SURVEY_REASON_OTHERS | अन्य वजहें | reasonUserInput पढ़ें, यूज़र के अपने शब्द |
| CANCEL_SURVEY_REASON_UNSPECIFIED | अनिर्दिष्ट cancel survey वजह | काम लायक कोई जवाब नहीं |
दाईं ओर वाला कॉलम हमारी समझ है, Google की नहीं। पहले दो कॉलम सीधे API reference से लिए गए हैं।
Notification में वजह नहीं होती
रद्द किया गया सब्सक्रिप्शन SUBSCRIPTION_CANCELED real-time developer notification भेजता है, type 3। Google साफ़ कहता है कि ये notifications सिर्फ़ इतना बताती हैं कि purchase की स्थिति बदली। Payload में एक purchase token के अलावा काम की कोई चीज़ नहीं होती, इसलिए सर्वे का जवाब पढ़ने के लिए आपके handler को purchases.subscriptionsv2.get call करना होगा।
Play Console में क्या दिखता है
कुल आँकड़े देखने के लिए आपको code की ज़रूरत नहीं है। Play Console की subscription reports में एक Cancellations card होता है जो churn को voluntary, involuntary और अन्य में बाँटता है, और जवाब देने वाले यूज़र के लिए एक Cancellation survey responses card होता है। अन्य चुनने वाले यूज़र के खुले टेक्स्ट जवाब Other responses card से CSV के रूप में डाउनलोड किए जा सकते हैं। इस डाउनलोड के लिए View financial data permission चाहिए, वही जो आप अपने ऑर्डर पढ़ने वाले किसी टूल को देते हैं।
Apple आपको क्या बताता है, और क्या छोड़ देता है
Apple कोई ऐसा cancellation survey नहीं चलाता जिसकी जानकारी डेवलपर तक पहुँचे। सबसे क़रीबी फ़ील्ड signed renewal info में expirationIntent है, और यह बताता है कि सब्सक्रिप्शन कैसे ख़त्म हुआ, यह नहीं कि ग्राहक क्या सोच रहा था।
| expirationIntent | Apple के अनुसार अर्थ | मेल खाता EXPIRED subtype |
|---|---|---|
| 1 | ग्राहक ने अपना सब्सक्रिप्शन रद्द किया | VOLUNTARY |
| 2 | बिलिंग त्रुटि, जैसे भुगतान की अमान्य जानकारी | BILLING_RETRY |
| 3 | कीमत बढ़ने या ऑफ़र रूपांतरण पर ज़रूरी सहमति नहीं दी | PRICE_INCREASE |
| 4 | renewal के समय प्रोडक्ट ख़रीद के लिए उपलब्ध नहीं था | PRODUCT_NOT_FOR_SALE |
| 5 | कोई अन्य वजह | कोई subtype नहीं |
Code 1 अकेला ऐसा code है जो ग्राहक के लिए गए फ़ैसले को बताता है, और वह भी मकसद के बारे में कुछ नहीं कहता। जो ग्राहक बार-बार ऐप क्रैश होने से गया और जिसने बस अपना प्रोजेक्ट पूरा कर लिया, दोनों एक जैसे दिखते हैं।
AUTO_RENEW_DISABLED में छिपा संकेत
Apple की एक notification पर ध्यान से नज़र डालना ज़रूरी है। subtype AUTO_RENEW_DISABLED के साथ DID_CHANGE_RENEWAL_STATUS का आमतौर पर मतलब होता है कि ग्राहक ने auto-renewal बंद किया। Apple के documentation में एक दूसरा मामला भी है: ग्राहक के रिफ़ंड माँगने के बाद App Store भी auto-renewal बंद कर देता है।
यानी iOS पर renewal बंद होने की घटना रिफ़ंड अनुरोध का पहला निशान हो सकती है। अगर purchase कोई consumable या auto-renewable subscription है, तो इसके बाद CONSUMPTION_REQUEST आ सकता है, और उस पल से आपके पास consumption data भेजने के लिए 12 घंटे होते हैं। अगर renewal बंद होने की घटना आपके ऐप में किसी दिखने वाली गतिविधि के बिना आती है, तो इसे उस अकाउंट का usage data तैयार रखने की चेतावनी मानें।
Apple और Google आमने-सामने
| Google Play | Apple App Store | |
|---|---|---|
| क्या यूज़र से वजह पूछता है | हाँ, एक cancel survey | डेवलपर को दिखने वाला कोई सर्वे नहीं |
| वजह कहाँ मिलती है | purchases.subscriptionsv2 में canceledStateContext | renewal info में expirationIntent |
| खुला टेक्स्ट | reasonUserInput, सिर्फ़ अन्य के लिए | कोई नहीं |
| किसने रद्द किया | यूज़र, सिस्टम, डेवलपर या replacement | code और subtype से अनुमान |
| Notification | SUBSCRIPTION_CANCELED, फिर get call करें | DID_CHANGE_RENEWAL_STATUS, EXPIRED |
| यूज़र दोबारा सब्सक्राइब करे तो मिट जाती है | हाँ, बहाल होने पर मिटा दी जाती है | renewal info मौजूदा स्थिति दिखाता है |
| डैशबोर्ड | Cancellation survey responses card | वजहों के लिए कुछ नहीं |
कहाँ रद्द करना रिफ़ंड में बदल जाता है
रद्द करने से अगला charge रुकता है। पिछला charge वापस नहीं होता। पैसा लौटेगा या नहीं, यह इस पर निर्भर करता है कि ग्राहक आगे किस रिफ़ंड प्रक्रिया तक पहुँचता है, और इनमें से ज़्यादातर प्रक्रियाएँ आपके बिना चलती हैं।
- Google Play पर ख़रीदार ख़रीद के 48 घंटे के भीतर ख़ुद रिफ़ंड ले सकता है, और फ़ैसला Google करता है।
- Google या Apple के support से होने वाले रिफ़ंड का फ़ैसला स्टोर करता है।
- Apple का CONSUMPTION_REQUEST आपसे consumption data माँगता है, 12 घंटे की समय सीमा के साथ।
- Google Play का चार्जबैक रिव्यू orders.reviewrefund के ज़रिए सबूत माँगता है, 24 घंटे की समय सीमा के साथ। चार्जबैक पर बैंक का फ़ैसला अंतिम होता है।
रद्द करने की वजह इनमें से कोई नियम नहीं बदलती। यह बस इतना बदलती है कि आपको कितनी जल्दी पता चलता है कि कौन सा ग्राहक नाख़ुश है, और जब सबूत माँगने वाली दो प्रक्रियाओं में से कोई आए, तो आपका सबूत तैयार है या नहीं।
हर वजह की आपको क्या कीमत पड़ती है
सर्वे का जवाब मोटे तौर पर यह भी बताता है कि किसी अकाउंट को सेवा देने में अब तक कितना खर्च हो चुका है, यानी वह पैसा जो रिफ़ंड के बाद आपकी जेब से जाता है।
तकनीकी समस्याएँ
यह सबसे महँगी वजह है। ग्राहक ने प्रोडक्ट इतना इस्तेमाल किया कि उसे समस्याएँ मिलीं, इसलिए आप उनके sessions के पीछे का compute, उनके requests से हुई model API calls, उनके बनाए content का storage, और जिस creator का content उन्होंने इस्तेमाल किया उसका भुगतान, सब चुका चुके हैं। अगर फिर उन्हें रिफ़ंड मिलता है, तो कीमत वापस चली जाती है और ये खर्च आपके पास रह जाते हैं। अगर वे Google Play पर अपने बैंक के पास जाते हैं, तो August 3, 2026 के बाद दिए गए ऑर्डर पर आपको खरीद कीमत (Play की सर्विस फ़ीस घटाकर) और बैंक की फ़ीस चुकानी पड़ती है।
कीमत से जुड़ी वजह
कीमत की शिकायत जितनी दिखती है उससे कम महँगी पड़ती है, बशर्ते उसके पीछे कोई अनचाहा renewal न छिपा हो। यही चार्जबैक की सबसे आम कहानी है, इसलिए जाँचें कि क्या रद्द करना किसी renewal charge के ठीक बाद हुआ और क्या आपके renewal reminders भेजे गए थे।
पर्याप्त इस्तेमाल नहीं
कम इस्तेमाल का मतलब है सेवा देने की कम लागत, इसलिए यहाँ रिफ़ंड ज़्यादातर वह पैसा लौटाता है जिसे कमाने में आपने ज़्यादा खर्च नहीं किया। यह वही वजह भी है जहाँ ईमानदार consumption data, अगर Apple माँगे, ठीक-ठीक दिखाता है कि ग्राहक ने क्या इस्तेमाल किया और क्या नहीं।
बेहतर ऐप मिल गया
ये ग्राहक शायद ही कभी कोई विवाद करते हैं। वे किसी प्रतिस्पर्धी के पास चले गए। यह वजह प्रोडक्ट से जुड़े फ़ैसलों के लिए उपयोगी है, रिफ़ंड से बचाव के लिए लगभग कभी नहीं।
रद्द करने की वजहें पढ़ने की एक दिनचर्या
- हर Google Play SUBSCRIPTION_CANCELED पर purchases.subscriptionsv2.get call करें और canceledStateContext को purchase token और cancelTime के साथ सेव करें।
- जब वजह अन्य हो, तो reasonUserInput को शब्दशः सेव करें। दोनों स्टोर में से यही अकेला खुला टेक्स्ट है जो आपको मिलता है।
- AUTO_RENEW_DISABLED वाली हर Apple DID_CHANGE_RENEWAL_STATUS पर घटना को log करें और उस अकाउंट का usage निकाल लें, ताकि CONSUMPTION_REQUEST आए तो आप तैयार रहें।
- हर Apple EXPIRED notification पर subtype और expirationIntent दर्ज करें, ताकि voluntary churn और बिलिंग विफलताएँ आपस में न मिलें।
- तकनीकी समस्याओं की वजह बताने वाले Google Play cancels के लिए उस अकाउंट के error logs जाँचें और ग्राहक के बैंक तक पहुँचने से पहले उससे संपर्क करें।
- हर अकाउंट के usage logs रखें, ताकि CONSUMPTION_REQUEST का जवाब 12 घंटे के भीतर और चार्जबैक रिव्यू का जवाब 24 घंटे के भीतर दिया जा सके।
अक्सर पूछे जाने वाले सवाल
- मैं कैसे देखूँ कि किसी Google Play सब्सक्राइबर ने क्यों रद्द किया?
- purchases.subscriptionsv2.get call करें और canceledStateContext.userInitiatedCancellation.cancelSurveyResult पढ़ें। reason फ़ील्ड में सर्वे का जवाब होता है, और जब यूज़र अन्य चुनता है तो reasonUserInput में खुला टेक्स्ट होता है। Play Console भी Cancellation survey responses card में कुल आँकड़े दिखाता है।
- क्या Apple डेवलपर को बताता है कि ग्राहक ने सब्सक्रिप्शन क्यों रद्द किया?
- नहीं। Apple के पास डेवलपर को दिखने वाला कोई cancel survey नहीं है। expirationIntent फ़ील्ड बताता है कि सब्सक्रिप्शन कैसे ख़त्म हुआ, ग्राहक ने रद्द किया, बिलिंग त्रुटि, कीमत बढ़ने पर सहमति नहीं, प्रोडक्ट उपलब्ध नहीं, या अन्य के codes के साथ, लेकिन ग्राहक का मकसद नहीं बताता।
- क्या SUBSCRIPTION_CANCELED notification में रद्द करने की वजह होती है?
- नहीं। Google Play की real-time developer notifications सिर्फ़ इतना बताती हैं कि purchase की स्थिति बदली। वजह पढ़ने के लिए purchases.subscriptionsv2.get से सब्सक्रिप्शन लाएँ, और उसे तुरंत सेव करें, क्योंकि अगर यूज़र सब्सक्रिप्शन बहाल करता है तो Google रद्द करने से जुड़े फ़ील्ड मिटा देता है।
- क्या Apple की AUTO_RENEW_DISABLED notification का मतलब रिफ़ंड अनुरोध हो सकता है?
- हाँ। Apple के documentation के अनुसार AUTO_RENEW_DISABLED subtype दोनों मामलों को कवर करता है: ग्राहक का auto-renewal बंद करना, और ग्राहक के रिफ़ंड माँगने के बाद App Store का उसे बंद करना।
- क्या सब्सक्राइबर के रद्द करने पर मैं access हटा सकता हूँ?
- Google Play पर नहीं, जब तक वे हक़दार हैं। Google कहता है कि रद्द करने वाला सब्सक्राइबर बिलिंग साइकिल ख़त्म होने तक access रखता है, और access पहले हटाना Google Play की subscriptions policy का उल्लंघन है। access कब ख़त्म हो, यह तय करने के लिए expiryTime का इस्तेमाल करें।
स्रोत और आगे की जानकारी
- Google Play Developer API: purchases.subscriptionsv2
- Google Play Billing: Subscription lifecycle
- Google Play Billing: Real-time developer notifications reference
- Play Console Help: Review in-app subscription performance
- Apple Developer: expirationIntent
- Apple Developer: notificationType
- Apple Developer: Send Consumption Information
- Play Console Help: Updates to refund protection and chargeback cost responsibility
RefundHalt
App Store और Google Play के लिए refund ऑटोपायलट
आगे पढ़ें
ज़्यादा रिफ़ंड अनुरोध आपको रिफ़ंड से भी महंगे पड़ सकते हैं, क्योंकि दोनों ऐप स्टोर इन्हें क्वालिटी का संकेत मानते हैं
Apple की गाइडलाइन 5.6.4 ज़्यादा रिफ़ंड अनुरोधों को इस बात का संकेत बताती है कि ऐप क्वालिटी के मानकों पर खरा नहीं उतर रहा, और Google का डिस्ट्रिब्यूशन एग्रीमेंट नए डेवलपर्स के ऐप रिफ़ंड दर के आधार पर हटाने की अनुमति देता है। जानिए हर स्टोर क्या कहता है, ऐप हटने की कीमत क्या है और इससे कैसे बचें।
रिफ़ंड पर कार्रवाई करने से पहले App Store सर्वर नोटिफ़िकेशन सत्यापित करें, क्योंकि आपके webhook URL पर कोई भी पोस्ट कर सकता है
जब तक आप इसके सिग्नेचर की जाँच नहीं करते, रिफ़ंड नोटिफ़िकेशन सिर्फ़ एक HTTPS अनुरोध है। जानिए App Store सर्वर नोटिफ़िकेशन और Google Play RTDN संदेशों को कैसे सत्यापित करें, हर स्टोर क्या साइन करता है, और जाली या गलती से अस्वीकार किया गया रिफ़ंड आपको कितना महँगा पड़ता है।