Apple रिफंड रिक्वेस्ट को कैसे ट्रैक करें और समय पर जवाब दें

ज़्यादातर टीमों से पूछिए कि क्या वे Apple रिफंड ट्रैक करती हैं, तो जवाब हाँ होगा। पूछिए कि वे क्या स्टोर करती हैं, तो पता चलता है कि हर रिफंड के लिए बस एक पंक्ति है, जो बाद में लिखी गई, जिसमें एक तारीख और एक रकम है।

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

यह अंतर इसलिए मायने रखता है क्योंकि इस प्रक्रिया के कुछ हिस्से समय के साथ खत्म हो जाते हैं। Apple एक चरण के लिए 12 घंटे की विंडो देता है, और वह बीत जाने के बाद उसे दोबारा खोलने का कोई रास्ता नहीं है। अगर आप ट्रैकिंग की तकनीकी बारीकियों के बजाय बड़ी तस्वीर देखना चाहते हैं, तो मोबाइल ऐप रेवेन्यू खोए बिना App Store रिफंड कैसे मैनेज करें पर हमारी गाइड उसे कवर करती है। यह लेख इस बारे में है कि क्या रिकॉर्ड करना है, और कब कदम उठाना है।

मुख्य बातें

• रिफंड का अंतिम फैसला Apple करता है। डेवलपर रिक्वेस्ट को न अप्रूव करते हैं, न रिजेक्ट।

• एक रिफंड रिक्वेस्ट कई अलग-अलग स्टेट से गुज़रती है। सिर्फ आखिरी स्टेट स्टोर करने से ज़्यादातर उपयोगी जानकारी खो जाती है।

• कुछ रिफंड वर्कफ़्लो में आपको 12 घंटे के भीतर, सहमति के साथ, consumption information भेजने का मौका मिलता है।

• जवाब सबमिट करना और उसका स्वीकार होना दो अलग चीज़ें हैं। कोशिश नहीं, नतीजा ट्रैक करें।

• रिफंड का नतीजा आपके entitlement लॉजिक और रेवेन्यू रिकॉर्ड तक पहुँचना चाहिए, वरना ट्रैकिंग पूरी नहीं हुई।

• ऑटोमेशन मुख्य रूप से छूटे हुए इवेंट और बीत चुकी विंडो को रोकता है। Apple के फैसले पर इसका कोई असर नहीं होता।

Apple रिफंड रिक्वेस्ट ट्रैकिंग क्या है?

Apple रिफंड रिक्वेस्ट ट्रैकिंग का मतलब है किसी रिफंड रिक्वेस्ट को आपकी तरफ़ की हर स्टेट से गुज़रते हुए फ़ॉलो करना, पहले नोटिफ़िकेशन से लेकर उस entitlement अपडेट तक जो उसे बंद करता है। यह रिफंड का रिकॉर्ड नहीं है। यह एक प्रक्रिया का रिकॉर्ड है।

ये स्टेट इसलिए मायने रखती हैं क्योंकि ये वाकई अलग-अलग इवेंट हैं, और टीमें अक्सर इन्हें एक में मिला देती हैं:

सिर्फ आखिरी पंक्ति आपके प्रोडक्ट के बारे में है। उसके ऊपर की हर पंक्ति तय करती है कि आप वह आखिरी पंक्ति सही कर पाते हैं या नहीं। जो टीम सिर्फ “रिफंड अप्रूव हुआ” स्टोर करती है, वह यह नहीं बता सकती कि किसी ग्राहक के पास अब भी एक्सेस क्यों है, या Apple के पूछने पर किसी ने जवाब दिया था या नहीं।

डेवलपर Apple रिफंड रिक्वेस्ट कैसे ट्रैक करते हैं?

डेवलपर Apple की रिफंड गतिविधि को Apple के सर्वर-साइड नोटिफ़िकेशन सिस्टम और अपने ट्रांज़ैक्शन रिकॉर्ड के ज़रिए ट्रैक करते हैं। सटीक रास्ता इवेंट के प्रकार पर और इस पर निर्भर करता है कि Apple इनपुट माँग रहा है या नहीं। इवेंट उस URL पर पहुँचते हैं जिसे आप App Store Server Notifications के ज़रिए कॉन्फ़िगर करते हैं, साइन किए गए payload के रूप में, जिन्हें आपका बैकएंड वेरिफ़ाई और प्रोसेस करता है।

आपके हैंडलर में दो तरह के रिफंड-संबंधी इवेंट अलग रखने लायक हैं। एक आपसे कुछ माँगता है। बाकी आपको बताते हैं कि क्या हुआ।

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

बताने वाला प्रकार नतीजों को कवर करता है: मंज़ूर होने पर REFUND, न होने पर REFUND_DECLINED, और जब Apple पहले मंज़ूर किया गया रिफंड पलट देता है तो REFUND_REVERSED। तीसरा वही है जिसे ज़्यादातर हैंडलर भूल जाते हैं।

इन दोनों के नीचे आपका अपना ट्रांज़ैक्शन स्टोर है, जो इस सबको समझने लायक बनाता है। नोटिफ़िकेशन Apple के आइडेंटिफ़ायर का हवाला देते हैं, इसलिए मिलान के लिए खरीदारी का रिकॉर्ड न हो तो आपके पास एक ऐसा इवेंट रह जाता है जिसे आप किसी से जोड़ नहीं सकते।

डेवलपर को कौन-सी जानकारी ट्रैक करनी चाहिए?

इसे इस आधार पर बाँटें कि जानकारी कहाँ से आती है, क्योंकि इसका सिर्फ एक पक्ष आधिकारिक है।

Apple से, ट्रांज़ैक्शन payload में: transaction identifier और original transaction identifier, product identifier, खरीदारी की तारीख, और रिफंड हुए ट्रांज़ैक्शन के लिए revocation date और revocation reason। यह reason फ़ील्ड ऐप में किसी समस्या की वजह से जारी रिफंड को अन्य कारणों से जारी रिफंड से अलग करती है, जो जितना दिखता है उससे कहीं ज़्यादा उपयोगी है।

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

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

इस सेट में दो टाइमस्टैम्प चुपचाप सबसे उपयोगी फ़ील्ड हैं। Apple के इवेंट और आपकी कार्रवाई के बीच का फ़ासला ही इस बात का एकमात्र ईमानदार पैमाना है कि आपकी ट्रैकिंग काम करती है या नहीं।

App Store रिफंड को स्टेप-बाय-स्टेप कैसे ट्रैक करें

1. रिफंड-संबंधी इवेंट प्राप्त करें

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

2. नोटिफ़िकेशन को वैलिडेट करें

payload पर कार्रवाई करने से पहले Apple की सर्टिफ़िकेट चेन के विरुद्ध सिग्नेचर वेरिफ़ाई करें और bundle ID की पुष्टि करें। जो endpoint हर आने वाली चीज़ पर भरोसा करता है, उस पर कोई और भी लिख सकता है।

3. संबंधित ट्रांज़ैक्शन की पहचान करें

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

4. जाँचें कि Apple इनपुट माँग रहा है या नहीं

नोटिफ़िकेशन के प्रकार के आधार पर ब्रांच करें। consumption request को जवाब देने का रास्ता चाहिए। नतीजे वाले नोटिफ़िकेशन को स्टेट अपडेट चाहिए। दोनों को एक जैसा मानने से ही रिस्पॉन्स विंडो छूटती हैं।

5. समर्थित consumption information इकट्ठा करें

मान अपने रिकॉर्ड से निकालें: खरीदारी डिलीवर हुई या नहीं, सैंपल कंटेंट दिया गया या नहीं, कितना इस्तेमाल हुआ। Apple का Send Consumption Information दस्तावेज़ फ़ील्ड और उनके वैध मान बताता है। इस सबसे पहले, सहमति जाँचें — Apple को डेटा साझा करने के लिए ग्राहक की वैध सहमति चाहिए, उसे लेना डेवलपर की ज़िम्मेदारी है, और बिना सहमति की रिक्वेस्ट सीधे रिजेक्ट कर दी जाती हैं।

6. दस्तावेज़ में बताई गई विंडो के भीतर सबमिट करें

Apple का मौजूदा दस्तावेज़ नोटिफ़िकेशन के 12 घंटे के भीतर जवाब माँगता है। सटीक मान भेजें, और यह मान लेने के बजाय पुष्टि करें कि कॉल सफल हुई।

7. अंतिम नतीजा ट्रैक करें

रिकॉर्ड करें कि कौन-सा नतीजा नोटिफ़िकेशन आया और कब। अगर किसी आउटेज के दौरान आपकी पाइपलाइन ने इवेंट छोड़ दिए, तो Apple का server API रिफंड हिस्ट्री उपलब्ध कराता है जिससे आप छूटा हुआ वापस पा सकते हैं — इसे सिर्फ नोटिफ़िकेशन पर भरोसा करने के बजाय समय-समय पर रीकंसिलिएशन के रूप में चलाना बेहतर है।

8. Entitlement और एक्सेस अपडेट करें

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

9. रेवेन्यू रिकॉर्ड से मिलान करें

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

Apple रिफंड रिक्वेस्ट का जवाब कैसे दें

जब Apple माँगे, तब सहमति के साथ, विंडो के भीतर consumption information भेजकर आप जवाब देते हैं। आप किसी चीज़ को अप्रूव या रिजेक्ट करके जवाब नहीं देते, क्योंकि यह विकल्प डेवलपर के पास है ही नहीं। फैसला Apple करता है।

आप जो भेजें, वह बताए कि खरीदारी के साथ असल में क्या हुआ, आपके रिकॉर्ड से लिया हुआ। न अनुमान, न ही अपनी पसंद के नतीजे की ओर झुकाया गया आँकड़ा — यह बेईमानी तो है ही, साथ ही यह वह डेटा है जिसे सटीक रूप से साझा करने की सहमति आपने ली है।

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

Apple के रिफंड पर फैसला लेने के बाद क्या होता है?

Apple नतीजे को नोटिफ़िकेशन के रूप में भेजता है और अपनी तरफ़ से चार्ज रिवर्स कर देता है। फिर काम आपके पास आ जाता है।

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

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

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

मैन्युअल Apple रिफंड ट्रैकिंग मुश्किल क्यों हो जाती है

लापरवाही की वजह से नहीं। बस यह काम लोगों की उपलब्धता से मेल नहीं खाता।

रिफंड रिक्वेस्ट तब आती हैं जब ग्राहक उन्हें सबमिट करते हैं, और कोई भी रिस्पॉन्स विंडो रात और वीकेंड पर भी चलती रहती है। हर इवेंट के लिए एक लुकअप, अकाउंट मैच, सहमति की जाँच, उपयोग का आँकड़ा, सबमिशन और entitlement अपडेट चाहिए। छोटे काम, लेकिन समयबद्ध और दोहराव वाले, और सही होने पर अदृश्य।

फिर स्केल इसका रूप बदल देता है। कई ऐप, ट्रांज़ैक्शन डेटा एक सिस्टम में और अकाउंट डेटा दूसरे में। ऐतिहासिक रिफंड डेटा कमज़ोर रहता है क्योंकि किसी ने उसे बैकफ़िल नहीं किया, entitlement की गड़बड़ियाँ बिना फ़्लैग हुए जमा होती रहती हैं, और फ़ाइनेंस तिमाही के अंत में अंतर सामने लाता है — उस समय से बहुत बाद, जब रिस्पॉन्स विंडो मायने रखती थी।

क्या Apple रिफंड ट्रैकिंग को ऑटोमेट किया जा सकता है?

हाँ, और इसका ज़्यादातर हिस्सा किया भी जाना चाहिए, क्योंकि लगभग हर चरण डिटरमिनिस्टिक है।

ऑटोमेशन रिफंड इवेंट पर नज़र रख सकता है और उन्हें वेरिफ़ाई कर सकता है, हर रिक्वेस्ट को आते ही रिकॉर्ड कर सकता है, ट्रांज़ैक्शन को अकाउंट से जोड़ सकता है, नोटिफ़िकेशन के प्रकार पर ब्रांच कर सकता है, आपके रिकॉर्ड से consumption डेटा तैयार कर सकता है, रिस्पॉन्स विंडो और सबमिशन नतीजे ट्रैक कर सकता है, entitlement स्टेट अपडेट कर सकता है, और रिफंड हिस्ट्री को क्वेरी करने लायक रख सकता है।

जो यह नहीं कर सकता, वह है Apple को प्रभावित करना। ऑटोमेशन रिफंड की संभावना कम नहीं करेगा और फैसले को किसी भी दिशा में नहीं धकेल सकता। जो बदलता है, वह यह है कि प्रक्रिया का आपका हिस्सा लगातार, और विंडो के भीतर, होता है या नहीं।

RefundSensor Apple रिफंड मैनेजमेंट में कैसे मदद करता है

App Store रिफंड मैनेजमेंट वह श्रेणी है जिसमें यह काम आता है, और RefundSensor इसके डेवलपर वाले पक्ष के लिए बना है: Apple रिफंड वर्कफ़्लो पर नज़र रखना, समर्थित रिस्पॉन्स चरणों को ऑटोमेट करना, और रिफंड इवेंट, नतीजों और रिकॉर्ड को अलग-अलग dashboard में बिखेरने के बजाय एक जगह रखना।

व्यवहार में, जवाब स्टोर की विंडो के भीतर हो जाता है, बिना किसी के नोटिफ़िकेशन पर नज़र रखे, और वॉल्यूम बढ़ने पर भी रिफंड रिकॉर्ड सटीक रहता है।

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

ये नियम कहाँ दस्तावेज़ किए गए हैं

ऊपर के तकनीकी दावों के पीछे Apple के तीन स्रोत हैं। इन्हें सीधे पढ़ें, और समय-समय पर दोबारा देखें — यह क्षेत्र एक से ज़्यादा बार बदल चुका है।

ऐप या कंटेंट के लिए रिफंड का अनुरोध करें — ग्राहक की तरफ़ की प्रक्रिया। यह समझने के लिए उपयोगी कि रिक्वेस्ट कहाँ से शुरू होती हैं, ग्राहकों को 24 से 48 घंटे में अपडेट की जो उम्मीद बताई जाती है, और Apple का यह नोट कि पात्रता देश या क्षेत्र के अनुसार अलग होती है।

Send Consumption Information — डेवलपर रिस्पॉन्स वर्कफ़्लो: सहमति की ज़रूरत, 12 घंटे की विंडो, और रिक्वेस्ट फ़ील्ड। कोई भी रिस्पॉन्स हैंडलिंग बनाने से पहले इसे पढ़ें।

App Store Server Notifications — रिफंड इवेंट आपके बैकएंड तक कैसे पहुँचते हैं, साइन किए गए payload का फ़ॉर्मेट, और नोटिफ़िकेशन के प्रकार, जिनमें CONSUMPTION_REQUEST, REFUND, REFUND_DECLINED और REFUND_REVERSED शामिल हैं।

अगर रिफंड इवेंट अब भी हाथ से देखे जा रहे हैं

मैन्युअल ट्रैकिंग उस दिन तक चलती है जब तक कोई नोटिफ़िकेशन रात 2 बजे नहीं आता और किसी के dashboard खोलने से पहले विंडो बंद नहीं हो जाती। यह विफलता खामोश होती है, और यही इसे महँगा बनाता है।

अगर यह आपके सेटअप जैसा लगता है, तो RefundSensor Apple रिफंड वर्कफ़्लो का डेवलपर वाला पक्ष संभालता है इवेंट पर नज़र रखना, जवाबों को विंडो के भीतर रखना, और यह सुनिश्चित करना कि नतीजे आपके रिकॉर्ड और entitlement लॉजिक तक पहुँचें।