ज्यादातर "best refund tool" लिस्ट उन लोगों द्वारा लिखी जाती हैं जिन्होंने कभी इसे खुद सेटअप नहीं किया। यहाँ वह वर्शन है जो मैं खुद चाहता था — इस आधार पर कि हर प्लेटफ़ॉर्म वास्तव में Google को क्या भेजता है और चुपचाप क्या मिस कर देता है।
एक छोटा सा फ्रेमिंग, क्योंकि यह लोगों को उलझा देता है। एक google play refund subscription इवेंट और एक chargeback दो अलग-अलग रूलबुक फॉलो करते हैं, और ज्यादातर प्लेटफ़ॉर्म एक को ठीक से हैंडल करते हैं और दूसरे को आधा-अधूरा। आप सिर्फ chargeback को ही contest कर सकते हैं। बाकी सब कुछ, आप केवल detect कर सकते हैं।
अगर आप तुलना को स्किप करना चाहते हैं, Google Play chargeback defense हमारा अपना प्रोडक्ट पेज है और इस पोस्ट का शॉर्ट वर्शन है।
मुख्य बातें
Google आपको सिर्फ chargebacks को contest करने देता है, Review Refund API के माध्यम से, लगभग 24 घंटों के भीतर। यहाँ मौजूद हर प्लेटफ़ॉर्म इसी सीमा के भीतर काम करता है।
Google तीन preferences स्वीकार करता है: APPROVE, DECLINE, NEUTRAL. API के ज़रिए किसी भी प्लेटफ़ॉर्म पर partial refunds संभव नहीं हैं।
असली अंतर evidence का है। कुछ टूल्स usage data भेजते हैं। कुछ सिर्फ एक preference और एक सिंगल boolean भेजते हैं।
Google आपको कभी outcome नहीं बताता। प्लेटफ़ॉर्म इसे poll करते हैं, इसलिए win-rate रिपोर्टिंग हर जगह लेट रहती है।
Detection एक बड़ा गैप है। Refund without revoke, partial refunds और unacknowledged purchases ज्यादातर stacks के लिए अदृश्य ही रहते हैं।
वास्तव में क्या कंपेयर करें
चार बातें। बाकी सब कुछ सिर्फ pricing page का noise है।
क्या यह consumption evidence भेजता है, या सिर्फ एक preference? यही Review Refund API का पूरा मतलब है। Google ने delivery state और item consumption माँगा था ताकि वह बैंक के सामने आपका केस रख सके। जो टूल सिर्फ APPROVE या DECLINE फ़ाइल करता है, वह इस चैनल का शायद एक-तिहाई हिस्सा ही इस्तेमाल कर रहा है।
क्या इसे SDK की ज़रूरत है? अगर हाँ, तो आप refund defense को अपने subscription infrastructure से जोड़ रहे हैं। यह एक असली फैसला है, और हमेशा गलत नहीं होता।
यह क्या detect करता है? Contesting, Google Play refund management का आधा हिस्सा है। यह जानना कि refund हो गया है, और access काटना, दूसरा आधा हिस्सा है।
क्या यह Apple को भी कवर करता है? ज्यादातर टीमें दोनों स्टोर चलाती हैं। एक ही काम के लिए दो vendor रखना ही वह तरीका है जिससे चीज़ें छूट जाती हैं।
RevenueCat Refund Control
अगर आपके subscriptions पहले से ही RevenueCat के माध्यम से चलते हैं तो यह सबसे मजबूत विकल्प है, और कई ऐप्स के लिए ऐसा ही होता है।
Refund Control, project-level policies का इस्तेमाल करता है जिन्हें ऊपर से नीचे evaluate किया जाता है। सबसे पहली मैच करने वाली policy जीतती है। आप Prefer full refund, Prefer no refund, Send consumption data only, या Do not respond में से चुनते हैं। यह आपके लिए Google के orders.reviewrefund endpoint को कॉल करता है।
यह हिस्सा दो बार पढ़ने लायक है। RevenueCat के अपने documentation के मुताबिक, वे Google को जो body भेजते हैं उसमें तीन fields होते हैं: pendingRefundToken, sampleContentProvided जो true पर सेट होता है, और आपका refundPreference। वे साफ़ तौर पर कहते हैं कि वे अभी consumption percentages या usage events नहीं भेजते। यानी आपको preference चैनल मिलता है, evidence चैनल नहीं।
वे detection limits के बारे में भी ईमानदार हैं। Play Console से जारी किया गया रिफंड, जिसमें revoke बॉक्स टिक नहीं किया गया हो, detect नहीं होगा। Partial refunds नहीं आते, और unacknowledged purchases से होने वाले रिफंड भी पकड़ में नहीं आते। जो भी चीज़ Google द्वारा ग्रांट की जाती है, आपके द्वारा नहीं, उसे दिखने में 24 घंटे तक लग सकते हैं।
जहाँ RevenueCat वास्तव में जीतता है वह कुछ ऐसा है जो यहाँ कोई और नहीं करता: आप खुद dashboard से या किसी REST endpoint से Google Play subscription refund जारी कर सकते हैं, और यह उसी कॉल में access revoke कर देता है। अगर support सीधे रिफंड हैंडल करती है, तो यह बात मायने रखती है।
Adapty Refund Saver
Refund Saver अब सिर्फ Apple नहीं, Google Play को भी कवर करता है, और अगर आप इसे पहले से iOS पर इस्तेमाल कर रहे थे तो यह डिफ़ॉल्ट रूप से ऑन रहता है।
यह chargeback reviews पर usage evidence भेजता है, जो इसे उस चीज़ में RevenueCat से आगे रखता है जो वास्तव में outcome को प्रभावित करती है। Google Play सपोर्ट, 3 अगस्त के उस बदलाव के बाद आया जिसने chargebacks को खर्चीला बना दिया।
दो ईमानदार सीमाएँ, दोनों Adapty के अपने docs से। Google सिर्फ decline, approve या no preference स्वीकार करता है, इसलिए Apple साइड का Grant prorated, Google पर कोई समकक्ष नहीं रखता और इसके बजाय Adapty No preference भेजता है। और Google किसी को भी तब सूचित नहीं करता जब कोई review resolve होता है, इसलिए Adapty तब तक order status को poll करता रहता है जब तक वह सेटल न हो जाए। Play के outcomes, Apple वालों से देर से सामने आते हैं।
असली बंदिश SDK है। Refund Saver एक platform feature है, कोई standalone product नहीं। अगर आप subscriptions के लिए Adapty पर नहीं हैं, तो इसे पाने के लिए आपको re-platform करना होगा। कुछ टीमों के लिए यह एक अच्छा सौदा है। ज्यादातर के लिए नहीं।
Refund Sensor
यह हम हैं, तो इसे उस हिसाब से तौलें।
कोई SDK नहीं। Google से Sign in करें, दो Play Console permissions दें (view financial data, manage orders and subscriptions) और यह आपके अपने Google Cloud project में Pub/Sub topic और push subscription प्रोविज़न कर देता है। Play Console में कुछ भी पेस्ट करने की ज़रूरत नहीं, कोई app release नहीं।
यह 24 घंटों के भीतर orders.reviewrefund के ज़रिए delivery और engagement evidence के साथ एक decline recommendation फ़ाइल करता है, और अलग से उन रिफंड्स को ट्रैक करता है जिन्हें आप contest नहीं कर सकते, यही वह हिस्सा है जिसमें ज्यादातर टीमों को कोई विज़िबिलिटी नहीं होती। दोनों स्टोर एक ही dashboard में मौजूद होते हैं।
ईमानदार कमियाँ: यह RevenueCat या Adapty से नया है, और इसमें कोई paywalls, A/B tests या subscription analytics नहीं हैं, क्योंकि यह प्रोडक्ट का मकसद ही नहीं है। subscription infrastructure चाहिए? आपको इनमें से किसी और की भी ज़रूरत पड़ेगी।
RefundHalt
अगर आप एक ब्लैंकेट preference के बजाय per-case rules चाहते हैं तो यह देखने लायक है। कोई SDK नहीं, दोनों स्टोर, और यह आपके सर्वर पर मौजूद एक endpoint से usage evidence खींचता है, इसलिए evidence अनुमानित नहीं बल्कि आपका खुद का होता है।
एक चेतावनी। उनकी कुछ प्रकाशित comparisons, Refund Saver के Google Play सपोर्ट करने से पहले की हैं, इसलिए comparison pages के बजाय वर्तमान docs चेक करें।
इसके बजाय खुद इसे बनाना
यह उचित है, और अगर आप पहले से ही एक backend चलाते हैं तो यह दिखने से ज्यादा सस्ता है।
आपको Monetize के अंदर, फिर Monetization setup में RTDN enable करना होगा। एक Pub/Sub topic। एक consumer जो base64 data field को decode करता है और यह तय करता है कि पाँच notification objects में से कौन-सा आया है। pendingRefundReviewNotification पर आप pendingRefundToken स्टोर करते हैं और 24-घंटे की क्लॉक के साथ रेस लगाते हैं। फिर orders.reviewrefund पर एक कॉल।
जो हिस्सा एक वीकेंड में नहीं बनता: सात हफ्ते पहले खरीदे गए किसी subscription के लिए असली consumption data रखना, साथ ही idempotency, क्योंकि Google retry करता है, साथ ही एक nightly Voided Purchases sweep जो उन चीज़ों को पकड़े जो notifications मिस कर गए। Voided Purchases API versus real-time developer notifications बताता है कि कौन-सा feed क्या करता है।
यही ईमानदार जवाब भी है इस सवाल का कि डेवलपर्स Google Play रिफंड को कैसे automate करें जब वे कोई vendor नहीं चाहते। यह एक webhook consumer है, एक timer है, और एक data problem है।
तो फिर कौन-सा चुनें
पहले से RevenueCat पर हैं और ज्यादातर detection के साथ एक preference चाहिए? Refund Control। इसे आज ही ऑन कर दें।
पहले से Adapty पर हैं और बिना अतिरिक्त मेहनत के evidence भेजना चाहते हैं? Refund Saver। यह शायद पहले से ही enabled है।
दोनों में से किसी पर नहीं हैं, और रिफंड्स को डिफेंड करने के लिए re-platform नहीं करना चाहते? Refund Sensor या RefundHalt।
आपके disputes ज्यादातर fraud की तरफ झुके हुए हैं और आप per-case logic चाहते हैं? RefundHalt, या इसे खुद बना लें।
इनमें से कोई भी नहीं, और रिफंड्स इतने ज्यादा नहीं हैं? अभी कुछ न करें, लेकिन फिर भी RTDN को वायर कर दें। यह फ्री है, और जब वॉल्यूम बढ़ेगा तो आपको यह history चाहिए होगी।
वह हिस्सा जिसे हर प्लेटफ़ॉर्म पेज छोड़ देता है
Google Play subscription refunds को कैसे automate करें, ज्यादातर ऐप्स के लिए यह गलत पहला सवाल है। डेवलपर्स के लिए Google Play रिफंड्स दो हिस्सों में बँट जाते हैं, जिन्हें आप प्रभावित कर सकते हैं और जिन पर आप सिर्फ प्रतिक्रिया दे सकते हैं, और दूसरी लिस्ट लंबी है।
आप एक chargeback review को contest कर सकते हैं। बस यही। Support refunds, 48-घंटे वाले Play refunds और unacknowledged trial conversions, यह सब आपके बिना ही तय हो जाते हैं। वहाँ उपलब्ध एकमात्र automation, उन्हें तेज़ी से detect करना और access काटना है।
इसका मतलब है कि Google Play refund automation वास्तव में एक trench coat में छिपे दो प्रोडक्ट हैं: chargebacks के लिए एक response engine, और बाकी सब के लिए एक detection engine। ज्यादातर vendors किसी एक में मजबूत होते हैं। चेक करें कि आप कौन-सा खरीद रहे हैं। चुनने से पहले Google की अपनी refund protection and chargeback cost announcement पढ़ना फ़ायदेमंद रहेगा, क्योंकि यह बताती है कि response साइड अचानक क्यों मायने रखने लगी।
स्रोत
अक्सर पूछे जाने वाले प्रश्न
सिर्फ chargeback वाला हिस्सा। जब कोई कस्टमर अपने बैंक के साथ dispute करता है तो Google एक review खोलता है, और आपको Review Refund API के ज़रिए जवाब देने के लिए लगभग 24 घंटे मिलते हैं। बाकी हर तरह का रिफंड आपके बिना ही तय होता है, और उसे केवल detect किया जा सकता है।
यह इस पर निर्भर करता है कि आप पहले से क्या इस्तेमाल कर रहे हैं। अगर आपके subscriptions वहाँ हैं तो RevenueCat। अगर आप उनके SDK पर हैं और usage evidence ऑटोमेटिकली भेजना चाहते हैं तो Adapty। अगर आप re-platform किए बिना refund defense चाहते हैं तो Refund Sensor या RefundHalt।
नहीं। Google API के ज़रिए APPROVE, DECLINE या NEUTRAL स्वीकार करता है। Prorated refunds Apple की साइड पर मौजूद हैं लेकिन इनका Google पर कोई समकक्ष नहीं है, इसलिए जो प्लेटफ़ॉर्म इन्हें ऑफर करते हैं वे Play पर इसके बजाय No preference भेजते हैं।
या तो इसे खुद RTDN और orders.reviewrefund के खिलाफ़ बनाएं, या किसी ऐसी सर्विस का इस्तेमाल करें जो Play Console permissions और एक Google Cloud project के ज़रिए कनेक्ट होती है। दोनों तरीकों में app binary को छूने की ज़रूरत नहीं पड़ती।
धीरे-धीरे। जब कोई review resolve होता है तो Google किसी को सूचित नहीं करता, इसलिए प्लेटफ़ॉर्म order status को poll करते हैं। outcome data में देरी की उम्मीद रखें, और किसी टूल को इस आधार पर judge करें कि उसने समय-सीमा के भीतर फ़ाइल किया या नहीं, न कि same-day win rate के आधार पर।
3 अगस्त, 2026 से, एक हारे हुए chargeback की कीमत होती है purchase price माइनस Google की service fee प्लस एक बैंक फीस। किसी सस्ते प्रोडक्ट पर सिर्फ यह फीस ही सेल से ज्यादा हो सकती है। फैसला लेने से पहले अपने ऑर्डर वैल्यूज़ पर खुद गणना करें।
