अपने सर्वर को पहले से मिल रहे रिफंड कारण कोड को पढ़िए, और यह आपको बताता है कि अपना ऐप ठीक करना है या ग्राहक से लड़ना है

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

रिफंड कारण कोड असल में क्या है

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

Google Play हर void पर एक कारण और एक स्रोत अंकित करता है

Google Play का Voided Purchases API हर पलटी गई खरीद के लिए एक रिकॉर्ड लौटाता है, और हर रिकॉर्ड में दो पूर्णांक होते हैं जो मायने रखते हैं। voidedReason बताता है कि खरीद क्यों void की गई। voidedSource बताता है कि इसे किसने शुरू किया। दोनों मिलकर एक सूखे रिफंड को एक वाक्य में बदल देते हैं: यह ऑर्डर एक चार्जबैक के कारण void किया गया, Google द्वारा शुरू किया गया, या पछतावे के रूप में void किया गया, उपयोगकर्ता द्वारा शुरू किया गया। आप इन्हें API को पोल करके या उस रियल-टाइम डेवलपर नोटिफ़िकेशन की सदस्यता लेकर पढ़ते हैं जो void आने पर ट्रिगर होता है। जो भी तरीका हो, ये दो संख्याएँ ही रखने लायक पेलोड हैं।

Apple आपको एक संकरा संकेत देता है, पर एक तेज़ संकेत

Apple आपको नौ-तरफ़ा कारण नहीं थमाता। रिफंड की गई किसी लेन-देन पर, Apple revocationReason को दो मानों में से एक पर सेट करता है। 1 का अर्थ है कि App Store ने आपके ऐप के भीतर किसी वास्तविक या कथित समस्या के कारण लेन-देन को रिफंड किया। 0 का अर्थ है कि उसने किसी अन्य कारण से रिफंड किया, उदाहरण के लिए एक आकस्मिक खरीद। यह फ़ील्ड केवल उन लेन-देन पर दिखता है जो रिफंड या रद्द किए गए, एक revocationDate के साथ, REFUND App Store Server Notification की हस्ताक्षरित लेन-देन जानकारी के भीतर। दो मान ज़्यादा नहीं हैं, पर जो मायने रखता है, एक 1, वह Apple का आपको यह बताना है कि रिफंड आपके उत्पाद के बारे में था, ग्राहक के दोबारा सोचने के बारे में नहीं।

नौ कारण जो Google Play आपको देता है

Google का voidedReason दोनों में से अधिक समृद्ध है, और हर मान को एक नज़र में पहचानना सार्थक है क्योंकि हर एक किसी अलग जगह की ओर इशारा करता है। यहाँ पूरा सेट है, सीधे VoidedPurchase संसाधन से, इसके साथ कि हर कोड असल में आपको क्या करने को कह रहा है।

voidedSource आपको बताता है कि ट्रिगर किसने खींचा

कारण के बगल में voidedSource बैठता है, और यह एक अलग सवाल का जवाब देता है: इसे किसने पलटा। 0 का अर्थ है उपयोगकर्ता ने किया, स्वयं-सेवा या किसी बैंक के ज़रिए। 1 का अर्थ है डेवलपर ने किया, यानी आप या आपका अपना टूलिंग रिफंड जारी कर रहा है। 2 का अर्थ है Google ने किया, अपने खुद के निर्णय पर, जिसमें अस्वीकृत खरीद के लिए ऑटो-रिफंड शामिल है। जब आप voids का उछाल देखें, तो स्रोत पहली कटौती है। स्रोत 2 की एक दीवार का मतलब है Google आपके खाते पर कार्रवाई कर रहा है, और वह आमतौर पर एक संकेत है जो आपके ग्राहकों के बजाय आपके इंटीग्रेशन की ओर वापस इशारा करता है।

हर रिफंड को ठीक करें, लड़ें, या स्वीकार करें में छाँटिए

एक कोड इसलिए उपयोगी है क्योंकि यह आपको बताता है कि एक रिफंड तीन प्रतिक्रियाओं में से किसका हकदार है। अधिकांश टीमें सभी रिफंड को एक जैसा मानती हैं और उन पर मेहनत जला देती हैं जिन्हें वे कभी जीत नहीं सकतीं। ये कोड साफ-साफ बँट जाते हैं।

ठीक करें: वे रिफंड जो आपके उत्पाद ने पैदा किए

कुछ कोड रिफंड के कपड़े पहने बग रिपोर्ट होते हैं। Google पर दोषपूर्ण (3) और प्राप्त नहीं हुआ (2), और Apple पर revocationReason का 1, सब एक ही बात कहते हैं: ग्राहक ने भुगतान किया और आपके ऐप ने डिलीवर नहीं किया। अस्वीकृत खरीद (8) इनमें सबसे तेज़ है क्योंकि दोष पूरी तरह आपके बिलिंग कोड में है। ये खत्म करने में सबसे सस्ते रिफंड हैं, क्योंकि आप इन्हें किसी को मनाकर नहीं, बल्कि अपनी ही किसी चीज़ को ठीक करके खत्म करते हैं। इस ढेर में बढ़ती गिनती एक उत्पाद दोष है जिसके साथ एक डॉलर का आँकड़ा जुड़ा है।

लड़ें: वे रिफंड जिन पर कोई हाथ चला रहा है

धोखाधड़ी (5), मित्रवत धोखाधड़ी (6), और चार्जबैक (7) विवाद हैं। शुद्ध धोखाधड़ी (5) न आपका ग्राहक है और न ही ऐसा राजस्व जिसे आप कभी रखने वाले थे। मित्रवत धोखाधड़ी (6), जहाँ खरीदार को ठीक वही मिला जिसके लिए उसने भुगतान किया और फिर उसने विवाद कर दिया, वह इकलौता विवाद है जिसे आपका सबूत अब भी हिला सकता है, और चार्जबैक (7) वह जगह है जहाँ वह सबूत प्रस्तुत किया जाता है। जब इनमें से कोई आए तो, यदि आपने पहले नहीं किया तो पहुँच रद्द कर दीजिए, और जहाँ कोई समीक्षा खिड़की खुली हो वहाँ खाते के बारे में आप जो जानते हैं उससे उसका जवाब दीजिए।

स्वीकार करें: वे रिफंड जिन्हें रोकना कभी आपके हाथ में था ही नहीं

पछतावा (1) और आकस्मिक खरीद (4) ग्राहक का अपना मन बदलना है। Apple का 0 वाला revocationReason भी यहीं बैठता है। कोई फ़ीचर विफल नहीं हुआ और कोई धोखाधड़ी नहीं हुई। आप आकस्मिक वाले ढेर को एक अधिक स्पष्ट खरीद पुष्टि से नरम कर सकते हैं, पर आप एक पछतावा रिफंड को बहस से हटा नहीं सकते, और उसे आज़माने में लगाया गया समय ठीक करने वाले ढेर से छीना गया समय है, जहाँ पैसा असल में है।

30 दिन का वह अड़चन जो कारण कोड को खोना आसान बना देता है

Google की तरफ़ एक सख़्त सीमा है जो इसे एक रिपोर्टिंग फ़ीचर से एक समय-सीमा में बदल देती है। अगर आप कोड को लगातार नहीं पकड़ रहे हैं, तो आप उन्हें खो रहे हैं।

Voided Purchases API केवल 30 दिन पीछे तक देखता है

Google स्पष्ट है कि API केवल पिछले 30 दिनों की void की गई खरीदें दिखा सकता है। इससे पुरानी voids नहीं लौटाई जातीं, चाहे आप कोई भी startTime पास करें, और startTime का मान स्वयं 30 दिन पहले से पहले सेट नहीं किया जा सकता। एक भोले इंटीग्रेशन के लिए इससे भी बुरा यह है कि 30 दिन की खिड़की इस आधार पर मापी जाती है कि Google के सिस्टम एक खरीद को कब void के रूप में देखते हैं, न कि खरीद कब हुई या यहाँ तक कि रिकॉर्ड में voidedTimeMillis कब है। तो एक रिफंड कारण कोड जिसे आप उस खिड़की के भीतर नहीं खींचते वह चला जाता है, और किसी भी खाली अंतराल वाला मासिक एक्सपोर्ट जॉब चुपचाप उन voids को गिरा देगा जिन्हें पकड़ने में वह बहुत धीमा रहा।

पैसे में इन कारण कोड का क्या मूल्य है

दो कोड एक विशिष्ट कीमत रखते हैं, और उन्हें पढ़ना ही वह तरीका है जिससे आप उन समस्याओं पर एक संख्या रखते हैं जो अन्यथा एक समग्र रिफंड दर के भीतर छिप जाती हैं।

एक कोड एक बिल है जो आपने खुद लिखा

voidedReason 8, अस्वीकृत खरीद, आपके कारण हुए रिफंड का सबसे साफ़ उदाहरण है। Google Play अपेक्षा करता है कि आपका ऐप एंटाइटलमेंट देने के तीन दिन के भीतर एक खरीद को स्वीकार करे, और अगर आप नहीं करते, तो Google अपने आप ऑर्डर रिफंड कर देता है और आइटम रद्द कर देता है। 8 से चिह्नित हर void एक असली बिक्री है, एक ऐसे ग्राहक की ओर से जो उत्पाद चाहता था, इसलिए वापस कर दी गई क्योंकि खरीद को स्वीकार करने वाली एक कॉल कभी चली ही नहीं। खोई हुई राशि पूरी बिक्री कीमत है, साथ ही वह कंप्यूट, API कॉल, और भंडारण जो आप उसे डिलीवर करने में पहले ही खर्च कर चुके। यह ऐसा रिफंड नहीं है जिस पर आप बातचीत करते हैं। यह एक बग है जिसे आप बंद करते हैं, और यह कोड ही वह तरीका है जिससे आप उसे ढूँढते हैं।

चार्जबैक कोड अब एक शुल्क साथ लाता है

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

Apple और Google कैसे मेल खाते हैं

दोनों स्टोर एक ही सवाल का जवाब अलग-अलग बारीकियों पर देते हैं, इसलिए एक क्रॉस-स्टोर रिफंड रिपोर्ट को उन्हें सामान्यीकृत करना होता है, बजाय यह उम्मीद करने के कि वे मेल खाएँगे।

ये दोनों स्टोर एक ही रिफंड के लिए आपको कभी एक ही कोड नहीं देंगे, और यह ठीक है। जो मायने रखता है वह यह है कि दोनों आपको एक मशीन-पठनीय कारण थमाते हैं, और दोनों उस टीम को पुरस्कृत करते हैं जो उसे पढ़ती है। Apple का एकल बिट आपको बताता है कि एक रिफंड कब आपके उत्पाद की गलती है। Google के नौ कारण और उसका स्रोत ध्वज आपको बताते हैं कि आप किस उत्पाद बग, किस विवाद, और किस स्वयं-आघातित बिलिंग खाई को देख रहे हैं। कोई कोड एक रिफंड नहीं रोकता। दोनों आपको बताते हैं कि क्या करना है ताकि अगला न हो।

RefundHalt हर रिफंड पर कारण कोड को उसके आते ही उसी पल पकड़ लेता है, दोनों स्टोर पर, और उसे Google की 30 दिन की खिड़की के अच्छे-खासे भीतर रखता है ताकि कुछ भी न फिसले। यह हर void को ठीक करें, लड़ें, या स्वीकार करें में छाँटता है, इसलिए कोड 3 दोषपूर्ण में एक उछाल आप तक एक उत्पाद अलर्ट के रूप में पहुँचता है और कोड 8 अस्वीकृत में एक उछाल आप तक एक इंटीग्रेशन बग के रूप में पहुँचता है, न कि राजस्व में एक अस्पष्ट गिरावट के रूप में। यह Apple के CONSUMPTION_REQUEST का जवाब 12 घंटे के भीतर देता है और Google Play की चार्जबैक समीक्षा का 24 के भीतर, और एक रिफंड या चार्जबैक आते ही पहुँच रद्द कर देता है। एक स्टोर एक रिफंड पर जो कोड लगाता है उसे आप बदल नहीं सकते। आप यह सुनिश्चित कर सकते हैं कि आप हर एक को पढ़ें, और उन पर कार्रवाई करें जो असल में ठीक करना आपके हाथ में है।