Google Play चार्जबैक की पूरी जानकारी: हर डेवलपर को क्या जानना चाहिए

Google Play चार्जबैक की पूरी जानकारी: हर डेवलपर को क्या जानना चाहिए

एक ग्राहक आपका प्रीमियम टियर खरीदता है। कुछ हफ़्तों बाद, वह पैसा आपके पेआउट से बस गायब हो जाता है। न कोई ईमेल। न कोई सपोर्ट टिकट। बस एक छोटा बैलेंस और एक ऐसी लाइन आइटम जिसकी आपने योजना नहीं बनाई थी। यही है Google Play चार्जबैक, और 3 अगस्त 2026 से, इसे हारने की कीमत आपको चुकानी होगी।

सालों तक Google इनमें से ज़्यादातर नुकसान खुद उठाता रहा। अब वह दौर खत्म हो गया है। हारा हुआ चार्जबैक अब सीधे आपके रेवेन्यू से पैसा खींच लेता है। अगर आप Android के लिए बनाते हैं और Play Billing के ज़रिए कुछ भी बेचते हैं, तो यह वह पैसा है जो आपके सोते-सोते भी जा सकता है। अच्छी बात यह है कि आपको जवाब देने का एक नया तरीका भी मिला है, और ज़्यादातर टीमों ने अभी तक इसे सेट नहीं किया है। हमारी Google Play चार्जबैक गाइड सेटअप को कवर करती है, लेकिन यह लेख पहले इसकी कार्यप्रणाली समझाता है।

यह उपभोक्ताओं के लिए लिखा गया लेख नहीं है। यह बताता है कि Google Play चार्जबैक प्रक्रिया असल में आपके खातों और आपके बैकएंड के साथ क्या करती है, और आप इसके बारे में क्या कर सकते हैं।

मुख्य बातें

• Google Play चार्जबैक एक ज़बरन भुगतान वापसी है, जिसे ग्राहक का बैंक शुरू करता है, न कि Google और न ही आपकी सपोर्ट टीम।

• 3 अगस्त 2026 से, हारे हुए चार्जबैक की कीमत है खरीद मूल्य में से Google का सेवा शुल्क घटाकर, साथ में बैंक का चार्जबैक शुल्क।

• जब किसी विवाद में आपके इनपुट की ज़रूरत होती है, तो Google Real-time Developer Notifications के ज़रिए एक PendingRefundReviewNotification भेजता है।

• उस नोटिफिकेशन से 24 घंटे के भीतर आपको ReviewRefund API के ज़रिए जवाब देना होता है।

• सिर्फ़ आपका पहला API रिस्पॉन्स ही मायने रखता है। बाद की कॉल्स नज़रअंदाज़ कर दी जाती हैं, भले ही API अब भी OK लौटाए।

• बैंक के चार्जबैक शुल्क फ़्लैट होते हैं, इसलिए सस्ते प्रोडक्ट्स पर अकेला शुल्क ही बिक्री से ज़्यादा महंगा पड़ सकता है।

• खरीद के समय obfuscated account ID सेट करना ही वह चीज़ है जिससे आप किसी विवाद को असली यूज़र से जोड़ पाते हैं।

• चुप रहने का मतलब है कि आप पूरा नुकसान उठाते हैं और रिकॉर्ड पर आपकी कोई दलील नहीं होती।

Google Play चार्जबैक क्या है?

Google Play चार्जबैक तब होता है जब ग्राहक का बैंक उस भुगतान को उलट देता है जो ग्राहक आपके ऐप या इन-ऐप खरीदारी के लिए पहले ही कर चुका है।

ग्राहक आपसे नहीं पूछता। वह Google से भी नहीं पूछता। वह अपने बैंक या कार्ड जारीकर्ता को कॉल करता है और चार्ज पर विवाद दर्ज करता है। बैंक पैसा वापस खींच लेता है और जांच शुरू कर देता है। यह सामान्य रिफंड से अलग है क्योंकि यह स्टोर के बाहर, बैंकिंग सिस्टम के भीतर शुरू होता है, जहां आपकी कोई सीधी पहुंच नहीं है।

उदाहरण। कोई $40 का वार्षिक सब्सक्रिप्शन खरीदता है। दो हफ़्ते बाद, वह अपने बैंक से कहता है कि उसने इसे कभी अधिकृत ही नहीं किया। बैंक $40 वापस खींच लेता है और चार्ज को विवादित के रूप में चिह्नित कर देता है। हो सकता है आप एक महीने के प्रीमियम फ़ीचर्स पहले ही दे चुके हों। चार्जबैक को इससे कोई फ़र्क नहीं पड़ता कि आपने क्या डिलीवर किया।

Play पर Google ही merchant of record है, इसलिए आप पर सीधा असर वित्तीय होता है, न कि प्रोसेसर की साख की समस्या। फिर भी इसका मतलब है असली पैसा आपके खाते से बाहर जाना।

चार्जबैक रिफंड से अलग क्यों हैं

रिफंड एक अनुरोध है जिसे Google Play के भीतर संभाला जाता है। Google Play चार्जबैक विवाद को बैंक संभालता है।

रिफंड Google के नियमों और आपकी सेटिंग्स के हिसाब से चलता है। चार्जबैक कार्ड नेटवर्क के नियमों और बैंक की समय-सीमाओं के हिसाब से चलता है। आपके पास कहीं कम नियंत्रण होता है, और हिसाब भी बदतर होता है, क्योंकि बैंक उलटी गई बिक्री के ऊपर अपना फ़्लैट शुल्क भी जोड़ देता है। सामान्य रिफंड भी बिना कोई खबर दिए आपके सर्वर से निकल सकता है, और चार्जबैक तो तब तक और भी खामोश रहता है जब तक पैसा जा नहीं चुका होता।

उदाहरण। $10 की खरीद पर रिफंड खरीदार को $10 लौटाता है। उसी $10 की खरीद पर चार्जबैक $10 लौटा सकता है और साथ में फ़्लैट बैंक शुल्क भी जोड़ सकता है। छोटी बिक्री पर, एक विवाद आपको उससे कहीं ज़्यादा पीछे छोड़ सकता है जितना उस बिक्री ने कभी कमाया था।

Google Play चार्जबैक प्रक्रिया कैसे काम करती है

Google Play चार्जबैक प्रक्रिया तब शुरू होती है जब कोई बैंक किसी चार्ज पर विवाद करता है, फिर Google उसकी समीक्षा करता है और, जिन मामलों में आपके इनपुट की ज़रूरत होती है, उनमें एक तय समय-सीमा के भीतर आपसे सबूत मांगता है।

यहां पूरा फ़्लो, चरण दर चरण:

1. ग्राहक अपने बैंक के पास चार्ज पर विवाद दर्ज करता है।

2. बैंक विवाद को merchant of record यानी Google के पास भेजता है।

3. Google उस खरीद पर पहले से मौजूद संकेतों की समीक्षा करता है।

4. जिन विवादों में डेवलपर समीक्षा की ज़रूरत होती है, उनके लिए Google Real-time Developer Notifications के ज़रिए PendingRefundReviewNotification भेजता है।

5. आपके पास ReviewRefund API के ज़रिए अपनी प्राथमिकता और उपयोग के सबूत के साथ जवाब देने के लिए 24 घंटे होते हैं।

6. Google आपके भेजे गए डेटा के आधार पर बैंक के सामने मामले की पैरवी करता है।

उदाहरण। रात 2 बजे आपके Pub/Sub टॉपिक पर एक नोटिफिकेशन आता है। कोई भी क्यू पर नज़र नहीं रख रहा। अगले दिन रात 2 बजे तक विंडो बंद हो चुकी होती है। अगर आपके सिस्टम ने कभी जवाब नहीं दिया, तो Google रिकॉर्ड पर सिर्फ़ ग्राहक के पक्ष के साथ मामले की पैरवी करता है। Google इसे कैसे प्रस्तुत करता है, यह आप उसके आधिकारिक चार्जबैक दस्तावेज़ीकरण में पढ़ सकते हैं।

चार्जबैक नोटिफिकेशन के बाद क्या होता है?

नोटिफिकेशन आने के बाद 24 घंटे की घड़ी शुरू हो जाती है, और ReviewRefund API के ज़रिए सिर्फ़ आपका पहला रिस्पॉन्स ही रिकॉर्ड किया जाता है।

आपके रिस्पॉन्स में ये फ़ील्ड हो सकते हैं:

• pendingRefundToken: नोटिफिकेशन से मिला टोकन। यह ज़रूरी है, और आप इसे वापस भेजते हैं ताकि Google आपके जवाब को विवाद से मिला सके।

• sampleContentProvided: एक true या false फ़्लैग, जो बताता है कि खरीद से पहले आपने मुफ़्त सैंपल, ट्रायल या फ़ंक्शनैलिटी की स्पष्ट जानकारी दी थी या नहीं।

• refundPreference: आपकी प्राथमिकता: APPROVE, DECLINE या NEUTRAL, आपके अपने लॉजिक के आधार पर।

• consumptionPercentageMilliunits: ग्राहक ने कितना इस्तेमाल किया, milliunits में, जहां 45200 का मतलब 45.2 प्रतिशत है।

• consumptionUsageEvents: अधिकतम 1,000 इवेंट, हर एक में टाइमस्टैम्प, IP एड्रेस, अनुमानित लोकेशन और 5,000 अक्षरों तक का विवरण।

एक नियम जो टीमों को उलझा देता है। सिर्फ़ आपकी पहली कॉल ही स्टोर की जाती है। बाद की कॉल्स OK लौटाती हैं लेकिन कुछ नहीं बदलतीं। यानी अधूरा पहला जवाब स्थायी बन जाता है।

उदाहरण। आपका सर्वर उपयोग इवेंट्स के बिना एक जल्दबाज़ी वाला रिस्पॉन्स भेज देता है, यह सोचकर कि उन्हें दूसरी कॉल में भेज देगा। वह दूसरी कॉल चुपचाप खारिज कर दी जाती है। अब वही अधूरा जवाब Google के पास मौजूद एकमात्र जवाब है। फ़ील्ड की पूरी सूची ReviewRefund API रेफ़रेंस में मौजूद है।

डेवलपर्स को कैसे जवाब देना चाहिए

स्वचालित रूप से, विंडो के भीतर, एक स्पष्ट प्राथमिकता और विवादित ऑर्डर से जुड़े असली उपयोग सबूत के साथ जवाब दें।

एक मज़बूत रिस्पॉन्स आम तौर पर चार काम करता है:

• खरीद के समय सेट की गई obfuscated account ID के ज़रिए विवाद को असली यूज़र से मिलाता है।

• आपके अपने लॉजिक, जैसे फ़्रॉड पैटर्न या उपयोग स्तर, के आधार पर प्राथमिकता तय करता है।

• टाइमस्टैम्प, IP एड्रेस और अनुमानित लोकेशन के साथ उपयोग इवेंट्स जोड़ता है।

• यह दर्ज करता है कि खरीद से पहले सैंपल, ट्रायल या फ़ंक्शनैलिटी प्रीव्यू उपलब्ध था या नहीं।

उदाहरण। जिस यूज़र के 60 लॉग किए गए सेशन हों, जिसका IP उसके साइनअप देश से मेल खाता हो, और जिसका उपयोग प्रतिशत स्पष्ट हो, उसे बैंक के लिए अनधिकृत कहना मुश्किल है। यही सबूत Google आपकी ओर से आगे भेजता है। जिस अकाउंट में इनमें से कुछ भी न हो, वह Google को बहस करने के लिए कुछ नहीं देता।

डेवलपर्स की आम गलतियां

सबसे बड़ी गलतियां हैं नोटिफिकेशन को न सुनना, 24 घंटे की विंडो चूक जाना, और विवाद को किसी यूज़र से जोड़ने का कोई तरीका न होना।

यह पैटर्न हर टीम में दोहराया जाता है:

• हर नोटिफिकेशन टाइप के लिए Real-time Developer Notifications को सब्सक्राइब न करना।

• विंडो को सख़्त 24 घंटे की घड़ी के बजाय ऑफ़िस समय की तरह मानना।

• कभी obfuscated account ID सेट न करना, जिससे विवादों को किसी यूज़र से मिलाया नहीं जा सकता।

• अधूरा पहला रिस्पॉन्स भेजना और मान लेना कि फ़ॉलो-अप से यह ठीक हो जाएगा।

• API को छोड़ देना क्योंकि वह तकनीकी रूप से वैकल्पिक है, जबकि हर नुकसान फिर भी झेलना।

उदाहरण। एक टीम मान लेती है कि कोई व्यक्ति काम के घंटों में विवाद संभाल लेगा। शुक्रवार रात एक नोटिफिकेशन आता है। सोमवार तक तीन अलग-अलग मामलों की विंडो बंद हो चुकी होती है, और हर एक अब एक खामोश नुकसान है।

चार्जबैक का रेवेन्यू पर असर

हर हारा हुआ Google Play डेवलपर चार्जबैक आपको बिक्री मूल्य में से Google का सेवा शुल्क घटाकर, साथ में फ़्लैट बैंक शुल्क की कीमत चुकाने पर मजबूर करता है, इसलिए छोटी खरीदारियां घाटे में बदल सकती हैं।

दो छोटे मामले पूरी रेंज दिखाते हैं। $40 का सब्सक्रिप्शन जो विवाद हार जाए, उस पर आपको उस बिक्री का शुद्ध रेवेन्यू और बैंक शुल्क दोनों गंवाने पड़ते हैं। $2 का कॉइन पैक और भी बुरा है: फ़्लैट बैंक शुल्क बिक्री से कहीं बड़ा हो सकता है, इसलिए एक विवाद कई साफ़-सुथरी खरीदारियों का मार्जिन मिटा देता है।

नुकसान बढ़ता भी जाता है। उस खरीद को सर्व करने में आप पहले ही कंप्यूट, स्टोरेज और कभी-कभी सपोर्ट खर्च कर चुके हैं। रेवेन्यू वापस खिंच जाने से वे लागतें वापस नहीं मिलतीं। और बार-बार विवाद करने वाले आपसे एक से ज़्यादा बार वसूलते हैं, यही वजह है कि विवादों को यूज़र पहचान से जोड़ना इतना मायने रखता है।

चार्जबैक रोकथाम के लिए सर्वोत्तम तरीके

आप किसी ग्राहक को उसके बैंक को कॉल करने से नहीं रोक सकते, इसलिए चार्जबैक रोकथाम का मतलब दो चीज़ें हैं: जिन विवादों को कम कर सकते हैं उन्हें कम करें, और जो मिलें उन्हें हमेशा चुनौती दें।

एक व्यावहारिक चेकलिस्ट:

• हर एक खरीद पर obfuscated account ID सेट करें।

• हर नोटिफिकेशन टाइप के लिए Real-time Developer Notifications सब्सक्राइब करें।

• पहले दिन से ही टाइमस्टैम्प, IP एड्रेस और अनुमानित लोकेशन के साथ उपयोग लॉग करें।

• खरीद से पहले बिलिंग शर्तें और ट्रायल विवरण स्पष्ट रखें, जिससे "मैंने अधिकृत नहीं किया" वाले दावे कम होते हैं।

• ReviewRefund रिस्पॉन्स को ऑटोमेट करें ताकि कुछ भी किसी के जागे रहने पर निर्भर न रहे।

एक और कदम है जिसे टीमें भूल जाती हैं। विवाद जीतें या हारें, रिवर्सल के बाद एक्सेस वापस लेना आपका काम है, Google का नहीं। पैसे का जाना और एक्सेस का खत्म होना दो अलग-अलग घटनाएं हैं।

उदाहरण। जो ऐप शुरू से सेशन लॉग करता है और account ID सेट करता है, वह किसी भी विवाद का जवाब सेकंडों में दे सकता है। जिस ऐप ने कुछ लॉग नहीं किया, उसके पास भेजने को कुछ नहीं है, और विंडो दोनों ही हालात में एक जैसे बंद हो जाती है।

कमी को दूर करना

ज़्यादातर टीमों में जो कमी है, वह उस पल के बीच का फ़ासला है जब Google सबूत मांगता है और जब कोई व्यक्ति उस पर ध्यान देता है।

नियम सार्वजनिक हैं। विंडो 24 घंटे पर तय है। असली सवाल सिर्फ़ यह है कि क्या आपका सिस्टम समय रहते असली डेटा के साथ जवाब देता है। मैन्युअल हैंडलिंग यह दौड़ लगभग हर बार हार जाती है, क्योंकि विवाद ऑफ़िस समय का इंतज़ार नहीं करते।

चार्जबैक पहले Google की समस्या थे। अब वे आपकी हैं, लेकिन सबूत और उसे इस्तेमाल करने वाला API भी आपके पास है। जो टीमें इसे सेट कर लेती हैं, वे वह रेवेन्यू बचा लेती हैं जिसे खामोश टीमें चुपचाप लौटा देती हैं।

ये नीतियां कहां दर्ज हैं

ऊपर बताई गई हर बात के पीछे ये प्राथमिक स्रोत हैं। कोई थर्ड-पार्टी ब्लॉग नहीं, सिर्फ़ Google का आधिकारिक दस्तावेज़ीकरण।

• Google Play Billing: चार्जबैक विवाद में Google की मदद करें

• Google Play Developer API: orders.reviewrefund रेफ़रेंस

• Google Play Console सहायता: रिफंड और चार्जबैक लागत की ज़िम्मेदारी

संदर्भ

• Google Play सहायता

• Google Play Billing

• Google Play डेवलपर दस्तावेज़ीकरण