रिफ़ंड पर कार्रवाई करने से पहले App Store सर्वर नोटिफ़िकेशन सत्यापित करें, क्योंकि आपके webhook URL पर कोई भी पोस्ट कर सकता है

जिसे भी आपका webhook URL पता चल जाए, वह उस पर रिफ़ंड भेज सकता है। हर App Store सर्वर नोटिफ़िकेशन और हर Google Play Real-time developer notification के पीछे यही असहज सच्चाई है: जब तक आप इसे सत्यापित नहीं करते, संदेश बस कुछ JSON वाला एक HTTPS POST है। अगर आपका सर्वर किसी अनुरोध में REFUND लिखा होने भर से subscription रद्द करता है, क्रेडिट वापस लेता है या खाता बंद करता है, तो आपने यह ताक़त हर उस व्यक्ति को दे दी है जो एक curl कमांड लिख सकता है।

दोनों स्टोर जाँच का तरीका देते हैं। Apple नोटिफ़िकेशन को खुद साइन करता है, इसलिए आप सिर्फ़ Apple के root सर्टिफ़िकेट से App Store सर्वर नोटिफ़िकेशन सत्यापित कर सकते हैं। Google Play अलग रास्ता अपनाता है। संदेश साइन नहीं होता, लेकिन Pub/Sub डिलीवरी साइन की जा सकती है, और Google वैसे भी कहता है कि हर बदलाव की पुष्टि उसकी API से करें। यहाँ बताया गया है कि हर तरीका क्या साबित करता है, और किसी भी दिशा में गलती होने पर उसकी क्या कीमत चुकानी पड़ती है।

हर स्टोर वास्तव में क्या साइन करता है

App Store सर्वर नोटिफ़िकेशन कैसे सत्यापित करें

Apple के दस्तावेज़ signedPayload को बिंदुओं से अलग किए गए तीन Base64URL-encoded हिस्सों की स्ट्रिंग बताते हैं: एक header, एक payload और एक signature, जो JSON Web Signature specification के अनुसार साइन होती है। payload को decode करना आसान है। उस पर भरोसा करने के लिए चार जाँचें चाहिए।

• decode किए गए header से x5c array पढ़ें। Apple क्रम बताता है: पहले signing key वाला सर्टिफ़िकेट, फिर एक Apple intermediate सर्टिफ़िकेट, फिर एक Apple root सर्टिफ़िकेट।
• उस चेन को उस Apple root के विरुद्ध सत्यापित करें जो आपने खुद Apple की PKI साइट से डाउनलोड किया है, व्यवहार में Apple Root CA - G3। संदेश के अंदर आए root पर कभी भरोसा न करें, क्योंकि जालसाज़ वहाँ कोई भी सर्टिफ़िकेट रख सकता है।
• पुष्टि करें कि intermediate में Apple Worldwide Developer Relations एक्सटेंशन 1.2.840.113635.100.6.2.1 है, फिर leaf सर्टिफ़िकेट की public key से JWS सिग्नेचर सत्यापित करें।
• decode किए गए डेटा को अपने ऐप से मिलाएँ: bundleId, production में appAppleId, और environment। किसी दूसरे डेवलपर के ऐप पर, या आपके production endpoint पर आई sandbox खरीद पर, Apple का वैध सिग्नेचर भी आपका रिफ़ंड नहीं है।

फिर अंदर की सामग्री के लिए यही दोबारा करें। data ऑब्जेक्ट में signedTransactionInfo और signedRenewalInfo होते हैं, और हर एक अपनी x5c चेन वाला अलग JWS है। जो REFUND handler लिफ़ाफ़े को सत्यापित करता है लेकिन transaction को बिना सत्यापित किए पढ़ लेता है, उसने बीच में एक छेद छोड़ दिया है।

खुद लिखने के बजाय Apple की library इस्तेमाल करें

Apple, Swift, Java, Python और Node के लिए App Store Server Library प्रकाशित करता है। इसका SignedDataVerifier आपके root सर्टिफ़िकेट, एक online-checks flag, environment, आपका bundle ID और production के लिए आपका appAppleId लेता है। Node का source दिखाता है कि यह क्या लागू करता है: चेन में ठीक तीन सर्टिफ़िकेट, Apple leaf एक्सटेंशन 1.2.840.113635.100.6.11.1 और intermediate एक्सटेंशन, सर्टिफ़िकेट की वैधता की तारीखें, और मेल खाते bundle ID, app ID और environment। online checks चालू होने पर यह OCSP responder से यह भी पूछता है कि leaf और intermediate सर्टिफ़िकेट रद्द तो नहीं हुए।

क्या IP allow list काफ़ी है?

नहीं। Apple कहता है कि अगर आपके सर्वर को allow list चाहिए, तो 17.0.0.0/8 subnet जोड़ें, और यह sandbox और production दोनों पर लागू होता है। इससे शोर कम होता है। यह साबित नहीं करता कि संदेश असली है, और जैसे ही Apple का नेटवर्क किसी ऐसे तरीके से बदलता है जिसकी आपको खबर नहीं मिली, यह टूट जाता है। असली दरवाज़ा सिग्नेचर जाँच को ही रखें।

Google Play रिफ़ंड नोटिफ़िकेशन कैसे सत्यापित करें

Google Play, RTDN संदेशों को आपके अपने Pub/Sub topic पर प्रकाशित करता है, और उस पर Pub/Sub Publisher भूमिका सिर्फ़ google-play-developer-notifications@system.gserviceaccount.com service account के पास होनी चाहिए। फिर आपकी subscription दो में से किसी एक तरीके से संदेश पहुँचाती है, और हर तरीके का अपना प्रमाण है।

• Pull subscription: आपका सर्वर Pub/Sub से एक authenticated कनेक्शन खोलता है और संदेश लाता है। कोई सार्वजनिक endpoint नहीं है, इसलिए किसी अजनबी के पास पोस्ट करने के लिए कुछ नहीं है।
• authentication चालू वाली Push subscription: Pub/Sub एक JSON Web Token साइन करता है और उसे Authorization header में Bearer टोकन के रूप में भेजता है। Google की गाइड कहती है कि टोकन के सिग्नेचर को सत्यापित करें और जाँचें कि उसके email और audience claims आपकी कॉन्फ़िगर की गई वैल्यू से मेल खाते हैं, और उसका sample code यह भी माँगता है कि email_verified true हो। टोकन एक घंटे तक पुराना हो सकता है।
• authentication के बिना Push subscription: जो कुछ भी URL तक पहुँच सकता है, वह RTDN जैसा दिखने वाला संदेश भेज सकता है।

Google क्यों चाहता है कि आप API से पुष्टि करें

पूरी तरह authenticated RTDN में भी पूरी कहानी नहीं होती। Google की setup गाइड साफ़ कहती है कि ये नोटिफ़िकेशन सिर्फ़ इतना बताते हैं कि किसी खरीद की स्थिति बदली है, और पूरी स्थिति जानने के लिए आपको Google Play Developer API कॉल करनी होगी। voidedPurchaseNotification के लिए इसका मतलब है कि कुछ भी रद्द करने से पहले Voided Purchases API में खरीद खोजें, या उसकी मौजूदा स्थिति लाएँ। API कॉल आपके अपने service account से authenticated होती है, इसलिए उसका जवाब ऐसा है जिसे कोई जालसाज़ नकली नहीं बना सकता।

जाली या अस्वीकार किए गए रिफ़ंड की पैसों में कीमत

जिस जाली रिफ़ंड नोटिफ़िकेशन पर आप भरोसा करते हैं, उसकी कीमत एक भुगतान करने वाला ग्राहक है। आप ऐसे व्यक्ति को बाहर कर देते हैं जिसका पैसा अभी भी आपके पास है, वह support ticket खोलता है, और कुछ लोग स्टोर जाकर वही रिफ़ंड माँगेंगे जो आपके सिस्टम ने देने का दिखावा पहले ही कर दिया था। जाली खरीद या renewal की कीमत उल्टी दिशा में पड़ती है: आप ऐसी आमदनी के बदले GPU compute, सशुल्क third-party API कॉल, storage और creator payouts देते हैं जो कभी थी ही नहीं।

उल्टी विफलता शांत होती है और अक्सर बड़ी। जो verifier गलत appAppleId, production में sandbox सेटिंग या पुराने root सर्टिफ़िकेट की वजह से असली संदेश अस्वीकार करता है, वह ठीक वे दो रिफ़ंड प्रक्रियाएँ गिरा देता है जहाँ आपके सबूत मायने रखते हैं। Apple, CONSUMPTION_REQUEST के 12 घंटे के भीतर consumption डेटा माँगता है। Google, orders.reviewrefund के ज़रिए chargeback समीक्षा का जवाब देने के लिए 24 घंटे देता है, और August 3, 2026 के बाद दिए गए ऑर्डर पर हारा हुआ Google Play chargeback आपको खरीद मूल्य में से Play की सेवा फ़ीस घटाकर, साथ में खरीदार के बैंक की फ़ीस जितना पड़ता है।

सत्यापन के बग को समय-सीमा न निगलने दें

• सत्यापित करने से पहले raw अनुरोध सहेजें, ताकि अस्वीकार किया गया संदेश कभी सचमुच खो न जाए।
• हर सत्यापन विफलता पर अलर्ट करें। एक जाली संदेश शोर है। एक साथ हर संदेश का विफल होना आपका अपना बग है।
• Apple पर, आप अस्वीकार किए गए संदेश दोबारा चला सकते हैं। Get Notification History पिछले 180 दिनों का मूल signedPayload लौटाता है, इसलिए verifier ठीक करें और सहेजे या वापस पाए गए payloads को उससे फिर से गुज़ारें।
• Google पर, लंबित chargeback समीक्षा सिर्फ़ अपने नोटिफ़िकेशन में होती है, इसलिए गलत कॉन्फ़िगर push audience का मतलब एक छूटी हुई समीक्षा है। हर बदलाव के बाद Play Console में Send Test Message से इसकी जाँच करें।

RefundHalt दोनों स्टोर के नोटिफ़िकेशन सत्यापित करता है, कुछ भी बदलने से पहले स्टोर की APIs से रिफ़ंड की पुष्टि करता है, और CONSUMPTION_REQUEST और chargeback समीक्षाओं का जवाब उनकी समय-सीमा के भीतर देता है, ताकि कोई नकली संदेश आपसे ग्राहक न छीन सके और कोई असली संदेश छूट न जाए।