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

छूटे हुए रिफ़ंड नोटिफ़िकेशन वह चुपचाप तरीका हैं जिससे डेवलपर उन दो रिफ़ंड फ़ैसलों में अपनी आवाज़ खो देता है जिनमें उसे बोलने का मौका मिलता है। Apple का CONSUMPTION_REQUEST और Google Play का चार्जबैक रिव्यू, दोनों एक नोटिफ़िकेशन से शुरू होते हैं और दोनों की घड़ी छोटी है: Apple पर 12 घंटे, Google पर 24 घंटे। अगर संदेश आते समय आपका सर्वर बंद, धीमा या गलत कॉन्फ़िगर है, तो स्टोर आपका इंतज़ार नहीं करता। उसके पास जो जानकारी पहले से है, उसी के आधार पर फ़ैसला कर देता है।

अच्छी बात यह है कि कोई भी स्टोर पहली असफलता पर संदेश फेंक नहीं देता। Apple दोबारा कोशिश करता है और 180 दिनों का इतिहास रखता है जिसे आप क्वेरी कर सकते हैं। Google Pub/Sub के ज़रिए प्रकाशित करता है, जो बिना acknowledge किए संदेशों को कई दिन तक रखता है। बुरी बात यह है कि रीट्राई का समय जवाब देने की समय-सीमा से मेल नहीं खाता, और दोनों में से एक फ़्लो के लिए कोई रिकवरी API है ही नहीं।

हर स्टोर रिफ़ंड नोटिफ़िकेशन कैसे भेजता है

Apple, App Store Server Notifications सीधे उस HTTPS URL पर भेजता है जिसे आप App Store Connect में सेट करते हैं। Google आपके सर्वर को सीधे कॉल नहीं करता। वह Real-time developer notifications को एक Google Cloud Pub/Sub topic पर प्रकाशित करता है, और उस topic पर आपका सब्सक्रिप्शन या तो उन्हें आपके एंडपॉइंट पर push करता है या आपके सर्वर के pull करने का इंतज़ार करता है।

Apple किसे असफलता मानता है

Apple का दस्तावेज़ बिल्कुल साफ़ है। 200 से 206 तक कोई भी स्टेटस लौटाएँ तो डिलीवरी पूरी मानी जाती है। 40x या 50x लौटाएँ तो Apple दोबारा कोशिश करता है। बाकी हर कोड को भी Apple असफल मानता है। हर कोशिश एक sendAttemptResult के साथ दर्ज होती है, और इसके मान असली आउटेज की चेकलिस्ट जैसे लगते हैं: TIMED_OUT, TLS_ISSUE, CIRCULAR_REDIRECT, NO_RESPONSE, PREMATURE_CLOSE, UNSUCCESSFUL_HTTP_RESPONSE_CODE और कुछ और। TIMED_OUT के लिए Apple की अपनी सलाह है कि जाँचें कि आपका सर्वर संदेशों को जवाब देने से पहले ही प्रोसेस तो नहीं कर रहा।

Google किसे असफलता मानता है

push सब्सक्रिप्शन पर आपके एंडपॉइंट का सफलता कोड ही acknowledgement है। pull सब्सक्रिप्शन पर आपके सर्वर को हर pull किए गए संदेश को acknowledge करना होता है, वरना Pub/Sub उसे फिर से भेजता है। डिफ़ॉल्ट acknowledgement डेडलाइन 10 सेकंड है और अधिकतम 600 सेकंड। Google की RTDN गाइड एक और नियम जोड़ती है जो दोहराने लायक है: नोटिफ़िकेशन बस इतना बताता है कि कुछ बदला है, इसलिए पूरी खरीद की स्थिति जानने के लिए आपको फिर भी Google Play Developer API कॉल करना होगा।

Apple का रीट्राई शेड्यूल 12 घंटे की समय-सीमा में क्यों नहीं बैठता

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

Apple कहता है कि CONSUMPTION_REQUEST मिलने के 12 घंटे के भीतर जवाब दें। अगर पहली डिलीवरी और एक घंटे बाद की रीट्राई के समय आपका सर्वर बंद है, तो अगली कोशिश पहली के 13 घंटे बाद आती है। Apple यह नहीं बताता कि रीट्राई पर पहली बार मिले अनुरोध को नए सिरे से 12 घंटे मिलते हैं या नहीं। सावधानी भरी समझ यही है कि पहली कोशिश से घड़ी शुरू मानें, यानी एक घंटे से ज़्यादा देर से छूटे अनुरोध को सिर्फ़ रीट्राई नहीं बचा पाएँगी।

क्या HTTP 400 के बाद Apple दोबारा कोशिश करता है?

हाँ, दस्तावेज़ के अनुसार। Apple 40x और 50x को वे कोड बताता है जिन पर रीट्राई होती है। मार्च 2026 में एक डेवलपर ने Apple के फ़ोरम पर बताया कि 400 जवाबों के बाद रीट्राई रुकती दिखीं, फिर लिखा कि एक या दो दिन बाद डिलीवरी फिर शुरू हो गई, और Apple ने Feedback Assistant रिपोर्ट माँगी। दस्तावेज़ में लिखे व्यवहार को नियम मानें और अपनी मॉनिटरिंग को उसका सबूत।

Get Notification History से छूटे App Store नोटिफ़िकेशन वापस पाएँ

Get Notification History वे version 2 नोटिफ़िकेशन लौटाता है जिन्हें Apple ने आपकी चुनी हुई समय-अवधि में आपके सर्वर पर भेजने की कोशिश की। हर रिकॉर्ड में पूरा साइन किया हुआ payload होता है, इसलिए आप उसे उसी हैंडलर को दे सकते हैं जो लाइव नोटिफ़िकेशन संभालता है। हर रिकॉर्ड में अधिकतम छह एंट्री वाला sendAttempts array भी होता है, एक पहली कोशिश के लिए और एक-एक पाँचों रीट्राई के लिए।

• startDate और endDate ज़रूरी हैं, और startDate प्रोडक्शन में पिछले 180 दिनों के भीतर या sandbox में पिछले 30 दिनों के भीतर होनी चाहिए।
• onlyFailures को true करें ताकि केवल वे नोटिफ़िकेशन मिलें जो आपके सर्वर तक नहीं पहुँचे, साथ में वे जिनकी Apple अभी रीट्राई कर रहा है।
• किसी एक notificationType, जैसे CONSUMPTION_REQUEST या REFUND, या किसी एक ग्राहक के transactionId से फ़िल्टर करें, लेकिन एक ही अनुरोध में दोनों से नहीं।
• हर कॉल अधिकतम 20 रिकॉर्ड लौटाती है। जब तक hasMore true है, paginationToken के साथ कॉल करते रहें, और हर बार वही request body भेजें।

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

V1 नोटिफ़िकेशन इस तरह वापस नहीं मिलते

Get Notification History केवल version 2 को कवर करता है। Apple, V1 नोटिफ़िकेशन की तीन बार रीट्राई करता है, पिछली कोशिश के 6, 24 और 48 घंटे बाद, और अगर सब असफल हों तो दोबारा चलाने के लिए कोई इतिहास नहीं बचता। V1 पर चल रहे किसी भी ऐप को V2 पर ले जाने की यह एक और वजह है।

छूटे Google Play रिफ़ंड नोटिफ़िकेशन वापस पाएँ

Google की सुरक्षा जाल खुद Pub/Sub है। जब तक आपका सब्सक्रिप्शन मौजूद है, जिस संदेश को किसी ने acknowledge नहीं किया वह retention अवधि तक वहीं रहता है, डिफ़ॉल्ट रूप से 7 दिन और बढ़ाने पर 31 दिन तक। आपका एंडपॉइंट वापस आते ही डिलीवरी फिर शुरू हो जाती है। दो सेटिंग इसे चुपचाप बेकार कर सकती हैं।

• dead-letter topic तय संख्या में डिलीवरी असफल होने के बाद संदेश को आपके सब्सक्रिप्शन से हटा देता है। डिफ़ॉल्ट संख्या 5 है, और तुरंत दोबारा भेजने वाली डिफ़ॉल्ट रीट्राई नीति के साथ पाँच कोशिशें जल्दी निकल सकती हैं। अगर आप इसका इस्तेमाल करते हैं, तो dead-letter topic पर दूसरे इनबॉक्स की तरह नज़र रखें।
• जिस सब्सक्रिप्शन पर सब्सक्राइबर की कोई गतिविधि नहीं होती, जैसे खुले कनेक्शन, सक्रिय pull या सफल push, वह डिफ़ॉल्ट रूप से 31 दिन बाद expire हो जाता है। एक महीने तक टूटा रहने वाला एंडपॉइंट खुद सब्सक्रिप्शन खो सकता है, उसमें इंतज़ार कर रहे हर संदेश के साथ।

रद्द हुए रिफ़ंड का 30 दिन का बैकअप है

जो रिफ़ंड पहले ही हो चुके हैं, उनके लिए Voided Purchases API pull आधारित बैकअप है। यह पिछले 30 दिनों की रद्द खरीदों की सूची देता है, हर पेज पर अधिकतम 1,000, और हर ऐप के लिए कोटा प्रति दिन 6,000 क्वेरी और किसी भी 30 सेकंड में 30 क्वेरी है। one-time प्रोडक्ट के साथ सब्सक्रिप्शन भी शामिल करने के लिए type 1 भेजें। इसे रोज़ चलाने से वह हर रिफ़ंड पकड़ में आ जाता है जो आपकी नोटिफ़िकेशन पाइपलाइन से छूट गया, जिससे एंटाइटलमेंट और रेवेन्यू के आँकड़े सही रहते हैं।

चार्जबैक रिव्यू का कोई बैकअप नहीं

PendingRefundReviewNotification अलग है। इसमें वह pendingRefundToken होता है जिसे आपको orders.reviewrefund को देना होता है, और इसे पाने के बाद अपनी रिफ़ंड प्राथमिकता और उपयोग के सबूत भेजने के लिए आपके पास 24 घंटे होते हैं। Google आपकी पहली कॉल दर्ज करता है और बाकी को अनदेखा करता है। Google के दस्तावेज़ में ऐसा कोई एंडपॉइंट नहीं है जो लंबित रिव्यू की सूची दे, इसलिए अगर वह Pub/Sub संदेश खो गया, तो उस चार्जबैक के लिए आपका सबूत भी उसी के साथ खो जाता है।

छूटा रिफ़ंड नोटिफ़िकेशन पैसों में कितना महँगा पड़ता है

जो रिफ़ंड पहले से अंतिम है, उसका छूटा नोटिफ़िकेशन आपको सिर्फ़ हिसाब-किताब का काम देता है। आप उसे बाद में Voided Purchases API या Get Notification History में पाते हैं, अपनी नीति के अनुसार एक्सेस हटाते हैं, और आपकी रिपोर्ट अपडेट हो जाती हैं। झंझट है, पर सस्ता।

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

और खरीद को डिलीवर करने में आपने जो पैसा खर्च किया, वह विवाद शुरू होने से पहले ही जा चुका था।

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

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

एक भरोसेमंद रिकवरी रूटीन

• पहले acknowledge करें। कच्चा payload सहेजें, सफलता कोड लौटाएँ, फिर उसे queue में प्रोसेस करें।
• CONSUMPTION_REQUEST के लिए हर कुछ मिनट में onlyFailures के साथ Apple का Get Notification History poll करें, ताकि आउटेज 12 घंटे की समय-सीमा के कुछ मिनट ही खाए।
• रोज़ एक बार हर प्रकार के लिए पिछले कुछ दिनों पर onlyFailures के साथ Get Notification History चलाएँ, और जो मिले उसे दोबारा प्रोसेस करें।
• हर Google Play ऐप के लिए रोज़ type 1 के साथ Voided Purchases API कॉल चलाएँ, और उसे पहले से दर्ज रिफ़ंड से मिलाएँ।
• Pub/Sub पर message retention 7 दिन या उससे ज़्यादा रखें, अगर dead-letter topic है तो उस पर अलर्ट लगाएँ, और न पहुँचे संदेश जमा होने पर अलर्ट लगाएँ।
• पूरे रास्ते को प्रोडक्शन में भी परखें। Apple का sandbox हर नोटिफ़िकेशन एक बार ही भेजता है, कोई रीट्राई नहीं, और Request a Test Notification के साथ Get Test Notification Status ठीक-ठीक दिखाता है कि आपके सर्वर ने क्या जवाब दिया।

RefundHalt आपके लिए दोनों स्टोर के नोटिफ़िकेशन प्राप्त करता है और CONSUMPTION_REQUEST तथा चार्जबैक रिव्यू का जवाब उनकी समय-सीमा के भीतर अपने आप देता है, ताकि घड़ी पर नज़र रखने का काम आपका न रहे।