App Store रिफंड कैसे ट्रैक करें और सब्सक्रिप्शन रेवेन्यू कैसे सुरक्षित रखें
फाइनेंस टीम कहती है कि इस महीने रेवेन्यू करीब चार सौ डॉलर कम है। किसी को नहीं पता कि किस वजह से।
ज़्यादातर टीमों का सामना पहले इसी रूप से होता है। एक आंकड़ा बदला, और उसके पीछे की जानकारी कहीं ऐसी जगह पड़ी है जहां डेवलपमेंट टीम आसानी से पहुंच नहीं सकती। कौन सा ट्रांज़ैक्शन? कौन सा ग्राहक? क्या उनके पास अभी भी एक्सेस है? एक प्रोडक्ट या कोई पैटर्न? क्या यह महीनों से हो रहा है?
App Store रिफंड ट्रैकिंग इसी खाई को पाटती है। इसका मकसद रिफंड रोकना नहीं है — रिफंड का फैसला Apple करता है, और आप जो भी बनाएं, वह इसे नहीं बदलता। मकसद है रिफंड इवेंट्स का भरोसेमंद रिकॉर्ड रखना और हर इवेंट को एक ट्रांज़ैक्शन, एक ग्राहक, एक सब्सक्रिप्शन और आपकी रिपोर्टिंग की एक लाइन से जोड़ना।
यह लेख बताता है कि वह रिकॉर्ड कैसे बनाया जाए। इसके आसपास की पूरी प्रक्रिया के लिए, हमारी App Store रिफंड मैनेजमेंट गाइड व्यापक वर्कफ़्लो को कवर करती है।
मुख्य बातें
• रिफंड ट्रैक करना उन्हें रोकने जैसा नहीं है। रिफंड का फैसला Apple करता है; ट्रैकिंग का मतलब है आपकी तरफ़ विज़िबिलिटी।
• सिर्फ़ सर्वर नोटिफिकेशन एक पूरा ट्रैकिंग सिस्टम नहीं हैं। छूटे हुए रिफंड के लिए Apple खास तौर पर एक लुकअप API देता है।
• कोई रिफंड इवेंट तभी काम का है जब वह किसी ट्रांज़ैक्शन, ग्राहक और सब्सक्रिप्शन से जुड़ा हो।
• Entitlement स्टेट में रिफंड झलकना चाहिए, जहां लागू हो वहां आंशिक revocation समेत।
• रिफंड किए गए सब्सक्रिप्शन ट्रांज़ैक्शन रिपोर्टिंग में सामान्य रिन्यूअल की तरह नहीं दिखने चाहिए।
• जैसे-जैसे वॉल्यूम बढ़ता है और ज़्यादा टीमों को एक ही डेटा चाहिए होता है, ऑटोमेशन अपनी जगह बना लेता है।
App Store रिफंड ट्रैकिंग क्या है?
App Store रिफंड ट्रैकिंग का मतलब है आपके ऐप को प्रभावित करने वाले हर रिफंड इवेंट को रिकॉर्ड करना और उसे उससे जुड़ी चीज़ों से जोड़ना: ट्रांज़ैक्शन, ग्राहक खाता, प्रोडक्ट, सब्सक्रिप्शन, entitlement स्टेट और आपकी रेवेन्यू रिपोर्टिंग।
यहां असली काम "जोड़ना" शब्द कर रहा है। अकेला रिफंड इवेंट लगभग बेकार है — revocation date वाला एक ट्रांज़ैक्शन आइडेंटिफ़ायर बस यह बताता है कि कुछ रिफंड हुआ, यह नहीं कि किसे, उन्होंने किस चीज़ का एक्सेस खोया, या इससे कोई फ़र्क़ पड़ा भी या नहीं। ट्रैकिंग सिस्टम ही इवेंट को जवाब में बदलता है।
डेवलपर्स को App Store रिफंड ट्रैक करने की ज़रूरत क्यों है
ज़ाहिर वजह पैसा है, लेकिन App Store रिफंड से होने वाले रेवेन्यू नुकसान के स्वरूप को सटीक समझना ज़रूरी है। रिफंड किया गया ट्रांज़ैक्शन उस रेवेन्यू को पलट देता है जिसे आप पहले ही गिन चुके थे, और अगर वह सब्सक्रिप्शन अवधि थी, तो आम तौर पर उसके साथ रिश्ता भी खत्म हो जाता है — यानी उसके पीछे के रिन्यूअल भी चले जाते हैं। वे रिन्यूअल किसी न किसी के फ़ोरकास्ट में थे।
फिर वह हिस्सा है जो वित्तीय नहीं दिखता। अगर कोई रिफंड आपके सिस्टम तक कभी पहुंचा ही नहीं, तो ग्राहक का एक्सेस बना रहता है। सपोर्ट टीम सवालों का सामना करती है, पर जांचने के लिए कोई रिकॉर्ड नहीं होता। फाइनेंस पेआउट रिपोर्ट हाथ से मिलाता है। और कोई नहीं बता सकता कि क्या कोई एक प्रोडक्ट बाकी से कहीं ज़्यादा रिफंड होता है, क्योंकि क्वेरी करने के लिए कोई इतिहास ही नहीं है। हर समस्या छोटी है; मिलकर ये वजह हैं कि रिफंड की दिक्कतें देर से पकड़ में आती हैं।
App Store रिफंड कैसे ट्रैक करें
डेवलपर्स App Store रिफंड को Apple के सर्वर-साइड नोटिफिकेशन और अपने ट्रांज़ैक्शन रिकॉर्ड के ज़रिए ट्रैक करते हैं, फिर उन इवेंट्स को यूज़र्स, सब्सक्रिप्शन, entitlement और रेवेन्यू रिपोर्टिंग से जोड़ते हैं। सात चरण।
1. संबंधित Apple सर्वर नोटिफिकेशन प्राप्त करें
रिफंड इवेंट आपके कॉन्फ़िगर किए गए URL पर App Store Server Notifications के रूप में पहुंचते हैं। Apple का App Store Server Notifications डॉक्यूमेंटेशन सेटअप और इवेंट टाइप्स को कवर करता है। यहां सबसे अहम है REFUND, जो बताता है कि रिफंड मंज़ूर हुआ। REFUND_REVERSED भी मायने रखता है: Apple पहले दिया गया रिफंड पलट भी सकता है, और आपके रिकॉर्ड में यह दिखना चाहिए।
2. नोटिफिकेशन वेरिफ़ाई करें
नोटिफिकेशन साइन किए गए JWS पेलोड के रूप में आते हैं। अपने डेटाबेस में कुछ भी लिखने से पहले Apple के सर्टिफ़िकेट के आधार पर सिग्नेचर वेरिफ़ाई करें और bundle ID जांचें। जो एंडपॉइंट हर आने वाली चीज़ पर भरोसा करता है, उस पर कोई और भी लिख सकता है।
3. ट्रांज़ैक्शन की पहचान करें
डिकोड किए गए पेलोड में ट्रांज़ैक्शन आइडेंटिफ़ायर होते हैं और, रिफंड किए गए ट्रांज़ैक्शन के लिए, revocationDate और revocationReason। यह reason फ़ील्ड जितना ज़्यादातर टीमें समझती हैं उससे कहीं ज़्यादा उपयोगी है: यह ऐप में किसी समस्या की वजह से दिए गए रिफंड को किसी और वजह से दिए गए रिफंड से अलग करता है। पहली श्रेणी के रिफंड सिर्फ़ रेवेन्यू इवेंट नहीं, प्रोडक्ट सिग्नल हैं।
4. ट्रांज़ैक्शन को यूज़र से मिलाएं
Apple के आइडेंटिफ़ायर आपके अकाउंट ID नहीं हैं। इन्हें जोड़ने का काम appAccountToken करता है: एक UUID जिसे आपका ऐप खरीद के समय जोड़ता है और जो ट्रांज़ैक्शन पेलोड में वापस आता है। इसके बिना आप टाइमिंग और अनुमान के आधार पर मिलान कर रहे होते हैं, जो ठीक उन्हीं मामलों में अविश्वसनीय है जो आपके लिए सबसे ज़्यादा मायने रखते हैं।
5. रिफंड इवेंट रिकॉर्ड करें
इसे खरीद पर लगे फ़्लैग की तरह नहीं, बल्कि अपने अलग रिकॉर्ड के रूप में स्टोर करें। आपको चाहिए इवेंट, उसका टाइमस्टैम्प, Apple ने क्या कहा, और आपने उस पर क्या किया। अगला सेक्शन फ़ील्ड्स को कवर करता है।
6. सब्सक्रिप्शन और entitlement स्टेट अपडेट करें
एक्सेस ट्रांज़ैक्शन से मेल खाना चाहिए। जब रिफंड आए, रिफंड के बाद एक्सेस रद्द करें। जब कोई रिफंड पलटा जाए, तो एक्सेस बहाल करें। Apple प्रोरेटेड रिफंड भी सपोर्ट करता है, जिसमें ट्रांज़ैक्शन का सिर्फ़ एक हिस्सा रद्द होता है और रद्द किया गया प्रतिशत ट्रांज़ैक्शन पेलोड में वापस आता है — इसलिए जो entitlement लॉजिक हर रिफंड को पूरा-या-कुछ-नहीं मानता है, वह इनमें से कुछ को गलत संभालेगा।
7. रिफंड गतिविधि को रेवेन्यू रिपोर्टिंग से जोड़ें
जो रिफंड सिर्फ़ इंजीनियरिंग डेटाबेस में मौजूद है, उसका सफ़र अभी पूरा नहीं हुआ। फाइनेंस को वह सही अवधि में चाहिए; प्रोडक्ट टीम को वह SKU से जुड़ा चाहिए। अगर ये टीमें अलग-अलग आंकड़े पढ़ रही हैं, तो डेटा ट्रैक नहीं हो रहा, बस स्टोर हो रहा है।
हर रिफंड के लिए डेवलपर्स को क्या ट्रैक करना चाहिए?
इसमें से कुछ Apple से आता है। बाकी आप बनाते हैं। यह फ़र्क़ साफ़ रखना ज़रूरी है, क्योंकि सिर्फ़ पहला समूह ही आधिकारिक है।
फ़ील्ड | स्रोत | आपको यह क्यों चाहिए |
transactionId | Apple | खास रिफंड किए गए ट्रांज़ैक्शन की पहचान करता है |
originalTransactionId | Apple | ट्रांज़ैक्शन को सब्सक्रिप्शन की पूरी श्रृंखला से जोड़ता है |
productId | Apple | प्रति-प्रोडक्ट रिफंड विश्लेषण संभव बनाता है |
purchaseDate | Apple | रिफंड को बिक्री के समय से जोड़ता है |
revocationDate | Apple | App Store ने इसे कब रिफंड किया |
revocationReason | Apple | क्या ऐप में किसी समस्या के कारण रिफंड हुआ |
appAccountToken | दोनों | आप इसे जनरेट करते हैं; Apple इसे पेलोड में लौटाता है |
आंतरिक यूज़र ID | आपका सिस्टम | वह अकाउंट जिस पर रिफंड का असल असर पड़ता है |
रिफंड के समय सब्सक्रिप्शन स्टेट | आपका सिस्टम | उस पल ग्राहक के पास क्या था |
प्रोसेसिंग के बाद entitlement स्टेट | आपका सिस्टम | सबूत कि एक्सेस वाकई अपडेट हुआ |
इवेंट प्राप्त / प्रोसेस होने का समय | आपका सिस्टम | Apple के इवेंट और आपकी कार्रवाई के बीच का अंतराल दिखाता है |
लागू रिपोर्टिंग अवधि | आपका सिस्टम | फाइनेंस और इंजीनियरिंग को एक ही आंकड़े पर रखता है |
दोनों टाइमस्टैम्प चुपचाप अपनी अहमियत साबित करते हैं। Apple के इवेंट भेजने और आपके सिस्टम के उस पर कार्रवाई करने के बीच का अंतराल इस बात का सबसे साफ़ पैमाना है कि ट्रैकिंग काम कर रही है या नहीं।
सिर्फ़ नोटिफिकेशन क्यों काफ़ी नहीं हैं
यही वह हिस्सा है जो उन टीमों को चौंकाता है जो सोचती हैं कि उन्होंने यह हल कर लिया। नोटिफिकेशन छूट सकते हैं। आपका एंडपॉइंट डाउन हो जाता है, कोई डिप्लॉय हैंडलर तोड़ देता है, कोई पेलोड पार्स नहीं हो पाता — और आपकी तरफ़ कोई एरर नहीं दिखता, क्योंकि इवेंट कभी पहुंचा ही नहीं। Apple ने इसका ध्यान रखा है: App Store Server API में एक refund history एंडपॉइंट है, और Apple का डॉक्यूमेंटेशन इसे साफ़ तौर पर उन रिफंड नोटिफिकेशन को पाने का तरीका बताता है जो आपसे छूट गए हों, जैसे सर्वर आउटेज के दौरान।
तो एक पूरे ट्रैकिंग सिस्टम के दो हिस्से होते हैं। नोटिफिकेशन इवेंट्स को लगभग रियल टाइम में संभालते हैं; refund history के साथ समय-समय पर रिकॉन्सिलिएशन पास जो कुछ छूटा है उसे पकड़ता है। ज़्यादातर टीमें पहला हिस्सा बनाती हैं और मान लेती हैं कि यही पूरा सिस्टम है। ऐसा नहीं है, और यह विफलता चुपचाप होती है।
डेवलपर्स सब्सक्रिप्शन में Apple रिफंड कैसे ट्रैक करते हैं
सब्सक्रिप्शन दांव बढ़ा देते हैं: ट्रांज़ैक्शन के पीछे सिर्फ़ एक खरीद नहीं, एक रिश्ता होता है।
रिफंड की गई सब्सक्रिप्शन अवधि एक बार का उलटफेर नहीं है। आम तौर पर यह सब्सक्रिप्शन खत्म कर देती है, इसलिए entitlement अवधि जल्दी बंद हो जाती है, रिन्यूअल रुक जाते हैं, और ग्राहक के इतिहास में अब एक ऐसा रिफंड दर्ज है जिसका हिसाब रखना ज़रूरी है।
इसीलिए रिफंड किया गया सब्सक्रिप्शन ट्रांज़ैक्शन आंतरिक रिपोर्टिंग में एक सामान्य सफल रिन्यूअल की तरह नहीं दिखना चाहिए। अगर आपके रेवेन्यू आंकड़े रिफंड ओवरले के बिना रिन्यूअल इवेंट्स से बनते हैं, तो वे चुपचाप ऊपर की ओर खिसकते जाएंगे, और रिकॉन्सिलिएशन तक कोई इसे नहीं पकड़ेगा।
Apple का सर्वर API सब्सक्रिप्शन स्टेटस और ट्रांज़ैक्शन हिस्ट्री एंडपॉइंट भी देता है, जो अपने डेटाबेस पर अनिश्चित काल तक भरोसा करने के बजाय ग्राहक के बारे में अपनी जानकारी को Apple की जानकारी से जांचने के काम आते हैं। ग्राहकों को सपोर्ट करने और रिफंड संभालने पर Apple का सेशन बताता है कि डेवलपर की तरफ़ से ये सब हिस्से कैसे जुड़ते हैं।
App Store रिफंड सब्सक्रिप्शन रेवेन्यू को कैसे प्रभावित करते हैं
रिफंड का असर मूल ट्रांज़ैक्शन से आगे भी जा सकता है, खासकर जब रिफंड की गई खरीद किसी सब्सक्रिप्शन रिश्ते का हिस्सा हो।
सीधा असर है उलटफेर। उसके आगे, उस ग्राहक से भविष्य की सब्सक्रिप्शन वैल्यू शायद न मिले — हालांकि हर रिफंड churn में खत्म नहीं होता, इसलिए मान लेने के बजाय मापें। सकल खरीद पर बनी लाइफटाइम वैल्यू तब तक हकीकत से ज़्यादा दिखती है जब तक रिफंड घटाए न जाएं, और फ़ोरकास्ट को यह गलती विरासत में मिलती है। प्रति रिफंड इनमें से कुछ भी नाटकीय नहीं है। यह अदृश्य रूप से जमा होता जाता है, और यही अनुमान लगाने के बजाय ट्रैक करने की दलील है।
App Store सब्सक्रिप्शन रिफंड ट्रैकिंग रेवेन्यू सुरक्षित रखने में कैसे मदद करती है
साफ़ कर दें कि ट्रैकिंग क्या करती है और क्या नहीं: यह Apple के रिफंड फैसलों को प्रभावित नहीं करती। यह बदलती है कि आप क्या देख सकते हैं और किस पर कार्रवाई कर सकते हैं।
क्वेरी करने लायक रिफंड हिस्ट्री होने पर कई रास्ते खुलते हैं। आप देख सकते हैं कि कौन से प्रोडक्ट या प्राइस पॉइंट असंगत रूप से ज़्यादा रिफंड होते हैं, वह लीकेज ढूंढ सकते हैं जहां रिफंड पाए यूज़र्स का एक्सेस बना रहा, किसी चीज़ के टूटने से हुए रिफंड को बाकी से अलग कर पहली श्रेणी को बग क्यू की तरह ट्रीट कर सकते हैं, देख सकते हैं कि किसी रिलीज़ के बाद रिफंड बढ़े या नहीं, और सपोर्ट व फाइनेंस को एक ही व्यू दे सकते हैं। ये प्रोडक्ट और ऑपरेशनल सुधार हैं, और असल रेवेन्यू सुरक्षा यहीं से आती है।
मैन्युअल App Store रिफंड ट्रैकिंग क्यों टूट जाती है
मैन्युअल ट्रैकिंग कम वॉल्यूम पर काम करती है और वॉल्यूम बढ़ने पर अनुमानित तरीके से विफल हो जाती है।
नोटिफिकेशन रात भर में आते हैं। स्प्रेडशीट का मालिक टीम बदल लेता है। ट्रांज़ैक्शन आइडेंटिफ़ायर एक सिस्टम में और अकाउंट डेटा दूसरे में रहता है, इसलिए हर लुकअप एक छोटा-सा रिसर्च टास्क बन जाता है। ऐतिहासिक डेटा पतला रहता है क्योंकि किसी ने बैकफ़िल नहीं किया। सब्सक्रिप्शन और entitlement स्टेट बिना किसी चेतावनी के अलग-अलग हो जाते हैं। फाइनेंस को विसंगति तिमाही के अंत में मिलती है।
समस्या मेहनत की नहीं है। काम रेवेन्यू के साथ बढ़ता है, जबकि किसी की भूमिका उसके हिसाब से नहीं बढ़ती।
डेवलपर्स को App Store रिफंड ट्रैकिंग कब ऑटोमेट करनी चाहिए?
मोटे तौर पर तब, जब इनमें से कोई भी बात सच हो जाए: रिफंड इवेंट इतनी तेज़ी से आते हैं कि कोई उन्हें प्रोसेस नहीं कर पाता, कई टीमों को एक ही डेटा चाहिए, entitlement अपडेट असंगत हो गए हैं, या फाइनेंस को अगले क्लोज़ से पहले विज़िबिलिटी चाहिए।
ऑटोमेशन तयशुदा हिस्सों को संभालता है — नोटिफिकेशन पाना और वेरिफ़ाई करना, ट्रांज़ैक्शन को अकाउंट से मिलाना, रिकॉर्ड लिखना, refund history से रिकॉन्साइल करना, entitlement अपडेट करना, ट्रेंड सामने लाना। यह आपकी रिफंड दर कम नहीं करेगा, और इसके उलट दावे संदेह के लायक हैं। यह जो बदलता है वह है निरंतरता और लैग।
App Store रिफंड मॉनिटरिंग सॉफ़्टवेयर को क्या करना चाहिए?
काम का सवाल यह है कि क्या कोई टूल ऊपर बताई गई खास कमियों को पूरा करता है। उसे App Store Server Notifications को संभालना और वेरिफ़ाई करना चाहिए, ताकि इवेंट किसी फ़ेल हो रहे एंडपॉइंट में गुम न हों। उसे Apple की refund history से रिकॉन्साइल करना चाहिए, क्योंकि सिर्फ़ नोटिफिकेशन वाली ट्रैकिंग में एक अंधा कोना है। उसे ट्रांज़ैक्शन को अकाउंट से मैप करना चाहिए, क्योंकि मैन्युअल समय यहीं खर्च होता है। और उसे हर रिफंड को एक जैसा मानने के बजाय सब्सक्रिप्शन पर असर ट्रैक करना चाहिए।
फिर: खोजने लायक रिफंड हिस्ट्री, पूर्ण और आंशिक revocation को कवर करने वाले entitlement वर्कफ़्लो, ऐसी रिपोर्टिंग जिसे फाइनेंस और प्रोडक्ट दोनों इस्तेमाल कर सकें, और जब किसी इंसान की ज़रूरत हो तब अलर्ट। फ़ीचर की गिनती से ज़्यादा कवरेज मायने रखती है।
अंतिम विचार
Apple कौन से रिफंड मंज़ूर करता है, यह आप तय नहीं करते। आप यह तय करते हैं कि आप उन्हें देख पाते हैं या नहीं।
अच्छी ट्रैकिंग का मतलब है यह जानना कि क्या रिफंड हुआ, किस ग्राहक पर असर पड़ा, अब उनका एक्सेस क्या होना चाहिए, यह रिपोर्टिंग में कैसे दर्ज होता है, और क्या यह किसी पैटर्न का हिस्सा है। यह एक टेबल और कुछ हैंडलर हैं, कोई वीरतापूर्ण प्रोजेक्ट नहीं।
अगर इसे पढ़ने के बाद आप एक ही काम करें, तो रिकॉन्सिलिएशन पास जोड़ें। नोटिफिकेशन हैंडलिंग वह हिस्सा है जो ज़्यादातर टीमों के पास है; उसे Apple की refund history से जांचना वह हिस्सा है जो बताता है कि यह वाकई काम कर रही है या नहीं।
अगर रिफंड वॉल्यूम मैन्युअल ट्रैकिंग से आगे निकल चुका है
जैसे-जैसे रिफंड गतिविधि बढ़ती है, नोटिफिकेशन को हाथ से जांचना, ट्रांज़ैक्शन मिलाना, सब्सक्रिप्शन पर असर ट्रैक करना और रिफंड हिस्ट्री को अप-टू-डेट रखना व्यावहारिक नहीं रह जाता। RefundSensor उस वर्कफ़्लो के डेवलपर वाले हिस्से को ऑटोमेट और व्यवस्थित करता है, ताकि रिकॉर्ड किसी के हाथ से मेंटेन किए बिना सटीक बना रहे।
अक्सर पूछे जाने वाले प्रश्न
डेवलपर्स Apple के सर्वर नोटिफिकेशन, ट्रांज़ैक्शन रिकॉर्ड और refund history API का इस्तेमाल करते हैं। वे इवेंट वेरिफ़ाई करते हैं, ट्रांज़ैक्शन को यूज़र्स से मिलाते हैं, entitlement अपडेट करते हैं और छूटे हुए रिफंड रिकॉन्साइल करते हैं।
यह रिफंड को रिकॉर्ड करने और उन्हें ट्रांज़ैक्शन, ग्राहकों, प्रोडक्ट, सब्सक्रिप्शन, entitlement और रेवेन्यू रिपोर्टिंग से जोड़ने की प्रक्रिया है।
हां। Apple ट्रांज़ैक्शन और ओरिजिनल ट्रांज़ैक्शन ID देता है, जो रिफंड किए गए ट्रांज़ैक्शन और उसकी सब्सक्रिप्शन श्रृंखला की पहचान करते हैं।
रिफंड रेवेन्यू को पलट देते हैं और भविष्य के रिन्यूअल पर असर डाल सकते हैं। रिफंड ट्रैक करने से यह सुनिश्चित होता है कि रेवेन्यू और लाइफटाइम वैल्यू रिपोर्ट असल नेट रेवेन्यू दिखाएं।
ट्रांज़ैक्शन ID, product ID, खरीद की तारीख, revocation date, revocation reason, यूज़र ID, सब्सक्रिप्शन स्टेट, entitlement स्टेट और प्रोसेसिंग टाइमस्टैम्प ट्रैक करें।
हां। डेवलपर्स नोटिफिकेशन, वेरिफ़िकेशन, ट्रांज़ैक्शन मैचिंग, रिफंड रिकॉर्ड, रिकॉन्सिलिएशन और entitlement अपडेट को ऑटोमेट कर सकते हैं।
नहीं। रिफंड देना है या नहीं, यह Apple तय करता है। ट्रैकिंग सिर्फ़ बाद में एक्सेस, रिपोर्टिंग और रिफंड से जुड़ी इनसाइट्स को मैनेज करने में मदद करती है।
यह ऐसा सॉफ़्टवेयर है जो रिफंड इवेंट ट्रैक करता है, छूटे हुए रिफंड रिकॉन्साइल करता है, ट्रांज़ैक्शन को यूज़र्स से जोड़ता है, सब्सक्रिप्शन पर असर अपडेट करता है और रिफंड रिपोर्टिंग को व्यवस्थित रखता है।
