ऐप के अधिकांश चार्जबैक को बैंक के शामिल होने से पहले रोका जा सकता है, और एक को अभी रोकना बिक्री से ज़्यादा बचाता है

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

यहाँ वह हिस्सा है जो आपकी मदद करता है। ऐप चार्जबैक का एक बड़ा हिस्सा परिष्कृत धोखाधड़ी नहीं है। वे ऐसे ग्राहक से शुरू होते हैं जो नहीं बता पाता कि शुल्क किस लिए है, या ऐसी खरीद से जो पहले कभी पास होनी ही नहीं चाहिए थी। दोनों ऐसी चीज़ें हैं जिन पर आप कार्रवाई कर सकते हैं। बाकी सब एक रणनीति है: एक हारा हुआ विवाद असल में कितना महंगा पड़ता है, कौन से विवाद आप रोक सकते हैं, कौन सी धोखाधड़ी आप स्रोत पर रोक सकते हैं, और वे दो छोटी विंडो जो बैंक के फ़ैसला करते समय आपकी एकमात्र बात हैं।

चार्जबैक रिफ़ंड से ज़्यादा महंगा क्यों पड़ता है

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

App Store और Google Play बिल को अलग-अलग तरीकों से बाँटते हैं

App Store पर, कार्ड चार्जबैक बैंक और Apple के बीच सुलझता है, और Apple व्यवस्था संभालता है। Google Play पर नियम बदल गए। August 3, 2026 के बाद किए गए ऑर्डर के लिए, Google केवल वही सेवा शुल्क कवर करता है जो उसने पहले ही वसूल कर लिया है, और डेवलपर खरीद मूल्य में से वह सेवा शुल्क घटाकर, साथ ही बैंक जो भी चार्जबैक शुल्क लगाए, वह वहन करता है। Google इस कदम को Play को बाकी भुगतान उद्योग के अनुरूप लाने के रूप में बताता है।

जो लागत आप पहले ही खर्च कर चुके हैं वह वापस नहीं आती

रिफ़ंड या विवादित राशि केवल दिखने वाला नुकसान है। आप उस खरीद की सेवा के लिए पहले ही भुगतान कर चुके हैं। जिस कंप्यूट ने जनरेशन चलाया, तीसरे पक्ष के API कॉल जिनका आपको बिल आया, जो स्टोरेज आपने आवंटित किया, और किसी क्रिएटर को भेजा गया कोई भी भुगतान, ये शुल्क के पलटने पर नहीं पलटते। किसी कम कीमत वाले उपभोज्य पर, बैंक का स्थिर चार्जबैक शुल्क अकेले ही उससे ज़्यादा हो सकता है जितना ग्राहक ने चुकाया, और सेवा की डूबी हुई लागत उसके ऊपर बैठती है। इसीलिए एक रोका गया चार्जबैक अपनी अंकित कीमत से ज़्यादा कीमती है।

बैंक के शामिल होने से पहले चार्जबैक कैसे रोकें

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

भ्रम धोखाधड़ी से ज़्यादा विवाद पैदा करता है

जब कोई ग्राहक स्टेटमेंट स्कैन करता है और किसी पंक्ति को पहचान नहीं पाता, तो कई लोग आपसे संपर्क करने का सोचने से पहले बैंक को फ़ोन कर देते हैं। जो लेबल आप नियंत्रित कर सकते हैं वह पतला है। Apple हर खरीद पर apple.com/bill छापता है और इसे बदलने के लिए कोई सेटिंग नहीं देता, इसलिए आपके ऐप का नाम कभी नहीं दिखता। Google Play GOOGLE उपसर्ग लगाता है और फिर वह स्टेटमेंट नाम दिखाता है जो आप Play Console में सेट करते हैं, जो एकमात्र विवरण फ़ील्ड है जो कोई भी स्टोर आपको देता है। इसे ऐसे नाम पर सेट करें जिसे आपके ग्राहक जानते हों।

शुल्क को हर दूसरी जगह पहचानने योग्य बनाएँ

चूँकि आप Apple के विवरण को ठीक नहीं कर सकते, उसके आसपास की हर चीज़ ठीक करें। अप्रत्याशित शुल्क एक क्लासिक विवाद है, इसलिए स्टेटमेंट तक पहुँचने से पहले आश्चर्य को हटा दें।

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

इनमें से हर एक संभावित चार्जबैक को सपोर्ट बातचीत या एक साधारण रिफ़ंड में बदल देता है, और रिफ़ंड पर कोई बैंक शुल्क नहीं होता।

धोखाधड़ी वाली खरीद को स्रोत पर रोकें

जिन विवादों से आप बात करके नहीं बच सकते वे वही हैं जहाँ खरीद शुरू से ही धोखाधड़ी वाली थी। उन्हें आप पास होने से पहले, अपने सर्वर पर, उन उपकरणों से रोकते हैं जिन्हें दोनों स्टोर प्रलेखित करते हैं।

हर खरीद की पुष्टि अपने ही सर्वर पर करें

क्लाइंट के कहने पर कभी अधिकार न दें। खरीद टोकन अपने बैकएंड को भेजें, उसे स्टोर के मुकाबले पुष्टि करें, और उसे संग्रहीत करें। Google Play purchaseToken को विश्व स्तर पर अद्वितीय बनाता है, इसलिए आप इसे प्राथमिक कुंजी के रूप में उपयोग कर सकते हैं और किसी भी टोकन को अस्वीकार कर सकते हैं जिसे आपने पहले देखा है, जो रीप्ले और रसीद साझा करने को खत्म कर देता है। कुछ भी अनलॉक करने से पहले Play Developer API से पुष्टि करें, और App Store पर हस्ताक्षरित लेनदेन को उसी तरह मान्य करें।

ऐसी खरीद कभी न दें जो अब भी लंबित है

लंबित खरीद हाथ में पैसा नहीं है। Google Play आपको अधिकार तभी देने को कहता है जब खरीद की स्थिति PURCHASED हो, कभी नहीं जब वह PENDING हो, क्योंकि लंबित शुल्क अब भी विफल हो सकता है। जल्दी दे दें तो आपने उत्पाद ऐसे भुगतान पर दे दिया जो शायद कभी न आए, और यह एक नुकसान है जो आपने बनाया, कोई विवाद नहीं जिससे आप लड़ सकें।

हर खरीद को खरीदार से जोड़ें

दोनों स्टोर आपको खरीद के साथ एक खाता पहचानकर्ता जोड़ने देते हैं, जो उन्हें संदिग्ध पैटर्न पहचानने में और आपको विवाद को किसी उपयोगकर्ता से मिलाने में मदद करता है। Google Play पर, बिलिंग फ़्लो में अस्पष्ट खाता आईडी और प्रोफ़ाइल आईडी को setObfuscatedAccountId और setObfuscatedProfileId से सेट करें। App Store पर, एक appAccountToken सेट करें, जो एक UUID होना चाहिए। स्टोर को अच्छे संकेत दें और वह लेनदेन पूरा होने से पहले कुछ धोखाधड़ी रोक देता है।

वापस वसूलें और बार-बार दुरुपयोग करने वालों को काट दें

जब कोई खरीद रद्द, निरस्त, या चार्जबैक होती है, तो Google Play की Voided Purchases API आपको बता देती है, ताकि आप बिना उपयोग की गई वस्तु वापस वसूल सकें या बैलेंस नकारात्मक कर सकें। पहली बार करने वाले को चेतावनी दें, फिर उस खाते के लिए खरीद या पहुँच अक्षम कर दें जो दोबारा ऐसा करता है। एक सिलसिलेवार रिफ़ंड लेने वाला जो अपनी पहुँच बनाए रखता है, अगले विवाद का न्योता है।

जब विवाद पहले ही दर्ज हो चुका हो, तो विंडो का जवाब दें

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

Apple आपको 12 hours देता है

जब कोई ग्राहक किसी उपभोज्य या स्वतः-नवीनीकृत सदस्यता पर रिफ़ंड का अनुरोध करता है, तो Apple आपके सर्वर को CONSUMPTION_REQUEST भेजता है और उपभोग डेटा के लिए 12 hours तक प्रतीक्षा करता है: क्या आपने वितरित किया, कितना उपयोग हुआ, और क्या आप रिफ़ंड को मंज़ूर या अस्वीकार किया जाना पसंद करेंगे। फ़ैसला फिर भी Apple करता है, लेकिन आपका जवाब उस फ़ैसले में एक प्रलेखित इनपुट है।

Google Play आपको 24 hours देता है

किसी विवादित Play खरीद के लिए जिसे समीक्षा की ज़रूरत है, Real-time Developer Notifications के ज़रिए एक PendingRefundReviewNotification आता है और 24 घंटे की घड़ी शुरू कर देता है। orders.reviewrefund API के ज़रिए अपनी पसंद और अपने सबूतों के साथ जवाब दें, और Google इसका उपयोग आपकी ओर से बैंक के साथ नाजायज़ चार्जबैक का विरोध करने के लिए करता है। विंडो को चुपचाप बंद होने दें और विवाद आपके बिना आगे बढ़ जाता है।

आप बैंक के सबूत खुद क्यों दर्ज नहीं कर सकते

भुगतान टीमें Visa Compelling Evidence 3.0 की बात करती हैं, एक नियम जो किसी व्यापारी को एक ही क्रेडेंशियल पर दो पूर्व अविवादित लेनदेन दिखाकर, जिनमें से हर एक 120 और 365 दिन के बीच पुराना हो, और IP पता या डिवाइस आईडी जैसे मिलते-जुलते डेटा के साथ, दोस्ताना-धोखाधड़ी विवाद को हराने देता है। आपकी इन-ऐप बिक्री के लिए आप रिकॉर्ड के व्यापारी नहीं हैं। Apple और Google हैं। इसलिए स्टोर, आप नहीं, उस तरह के सबूत जुटाता है, और आपका डेटा लड़ाई तक पहुँचने का एकमात्र रास्ता ऊपर बताई गई समीक्षा विंडो है। यही व्यावहारिक कारण है कि 12 घंटे और 24 घंटे की घड़ियाँ इतनी मायने रखती हैं। वे मेज़ पर आपकी पूरी सीट हैं।

विवाद-पूर्व चेकलिस्ट

इसमें कुछ भी असामान्य नहीं है। यह एक छोटी सूची है जिसे आप अपने अगले बिलिंग चक्र से पहले लागू कर सकते हैं।

• Google Play का एक पहचानने योग्य स्टेटमेंट नाम सेट करें, और हर दूसरी जगह ब्रांडेड रसीदें भेजें।
• सालाना और ऊँची कीमत वाले शुल्कों से पहले नवीनीकरण अनुस्मारक भेजें।
• सदस्यता प्रबंधन और रिफ़ंड अनुरोध को ऐप के भीतर एक टैप पर रखें।
• हर खरीद की पुष्टि अपने सर्वर पर करें और टोकन को एक अद्वितीय कुंजी के रूप में संग्रहीत करें।
• अधिकार केवल PURCHASED स्थिति पर दें, कभी PENDING पर नहीं।
• हर खरीद के साथ एक खाता आईडी या एक UUID appAccountToken जोड़ें।
• Apple और Google नोटिफ़िकेशन फ़ीड को प्रावधानित करें और हर उपभोग अनुरोध और रिफ़ंड समीक्षा का विंडो के भीतर जवाब दें।