Apple पहले से दिया गया रिफंड पलट सकता है, और आपका सर्वर जिस पलटे हुए रिफंड को अनदेखा करता है वह भुगतान कर चुके ग्राहक को बाहर कर देता है

रिफंड हमेशा आख़िरी बात नहीं होती। App Store पहले से दिया गया रिफंड पलट सकता है, ग्राहक द्वारा विवाद उठाने के बाद, और जब वह पलटा हुआ रिफंड आपके सर्वर पर पहुँचता है तो वह एक ही निर्देश लेकर आता है: एक्सेस वापस दे दो। ज़्यादातर टीमें साधारण REFUND नोटिफिकेशन जोड़ती हैं, ग्राहक को काट देती हैं, और वहीं रुक जाती हैं। वे दूसरा आधा हिस्सा कभी नहीं बनातीं। तो जब पलटाव आता है, कुछ नहीं चलता, और एक ग्राहक जो फिर से भुगतान कर रहा है, अपनी खरीदी हुई चीज़ से बाहर बैठा रह जाता है। यहाँ बताया गया है कि App Store और Google Play पर रिफंड नोटिफिकेशन का पूरा समूह कैसे काम करता है, और जब आप हर एक को अनदेखा करते हैं तो उसकी क्या कीमत पड़ती है।

App Store तीन रिफंड नोटिफिकेशन भेजता है, एक नहीं

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

REFUND, वह जिसे हर टीम संभालती है

जब App Store किसी रिफंड को प्रोसेस करता है, तो वह आपके कॉन्फ़िगर किए गए URL पर एक REFUND नोटिफिकेशन भेजता है, और Apple की परिभाषा साफ़ है: यह 'इंगित करता है कि App Store ने किसी उपभोग्य In-App Purchase, किसी गैर-उपभोग्य In-App Purchase, किसी ऑटो-रिन्यूएबल सब्सक्रिप्शन, या किसी नॉन-रिन्यूइंग सब्सक्रिप्शन के लिए किसी ट्रांज़ैक्शन का रिफंड सफलतापूर्वक कर दिया।' आप रिफंड की गई ट्रांज़ैक्शन को स्टोर करते हैं, जो कुछ उसने खरीदा था उसे रद्द करते हैं, और Apple आपसे कहता है कि app में संदर्भ-आधारित मैसेजिंग के साथ ग्राहक को बताएँ कि क्या बदला। यह वही नोटिफिकेशन है जिसे हर कोई सबसे पहले जोड़ता है, और अक्सर एकमात्र।

REFUND_DECLINED, वह जिसे आपसे कुछ नहीं चाहिए

REFUND_DECLINED का ठीक वही मतलब है जो यह कहता है: 'App Store ने एक रिफंड अनुरोध अस्वीकार कर दिया।' ग्राहक ने माँगा, Apple ने ना कहा, और ट्रांज़ैक्शन बनी रहती है। ग्राहक के एक्सेस के बारे में कुछ नहीं बदलता, इसलिए यहाँ आपका एंटाइटलमेंट लॉजिक कुछ नहीं करता। इस नोटिफिकेशन का महत्व लेखा-जोखा रखने में है। यह उस रिफंड अनुरोध का चक्र पूरा करता है जिसका उत्तर आपने शायद किसी CONSUMPTION_REQUEST से दिया था, और यह पुष्टि करता है कि ग्राहक के पास अब भी वह है जिसके लिए उसने भुगतान किया। इसे एक रिकॉर्ड मानें, कोई क्रिया नहीं।

REFUND_REVERSED, वह जो टीमों को चौंका देती है

यह वह नोटिफिकेशन है जिसे ज़्यादातर रिफंड पाइपलाइनें कभी नहीं संभालतीं। Apple की परिभाषा स्पष्ट है: REFUND_REVERSED 'इंगित करता है कि App Store ने ग्राहक द्वारा उठाए गए विवाद के कारण पहले दिया गया कोई रिफंड पलट दिया। यदि आपके app ने संबंधित रिफंड के परिणामस्वरूप कंटेंट या सेवाएँ रद्द कर दी थीं, तो उन्हें बहाल करना ज़रूरी है।' इसे दो बार पढ़ें। Apple ने ग्राहक को रिफंड दिया, आपने एक्सेस रद्द किया, फिर Apple ने तय किया कि रिफंड नहीं टिकना चाहिए और उसे वापस खींच लिया। चार्ज फिर से सक्रिय है। ग्राहक ने भुगतान किया, और यदि आपका सर्वर केवल रद्द करना जानता है, तो वह अब भी बाहर है। पलटा हुआ रिफंड ही एकमात्र रिफंड घटना है जो एक्सेस वापस जोड़ती है, और यही वह है जिसके लिए लगभग कोई नहीं बनाता।

एक पलटा हुआ रिफंड असल में आपको क्या कीमत चुकाता है

छूटा हुआ पलटाव कोई राउंडिंग की गलती नहीं है। पैसे को दोनों दिशाओं में चलाकर देखें, क्योंकि किसी भी आधे को गलत करने की एक कीमत है।

पलटाव चूकें और आप एक भुगतान करने वाले ग्राहक को बाहर रखे रहेंगे। Apple ने चार्ज बहाल कर दिया है, इसलिए ग्राहक की जेब से फिर पैसा गया, और आपका app उसे वह चीज़ देने से मना कर रहा है जो उसने खरीदी। तात्कालिक कीमत है सपोर्ट का समय और एक सद्भावना रिफंड जो शायद अब आप खुद जारी करें, इस बार कोई स्टोर कमीशन वापस आकर उसे नरम नहीं करेगा। धीमी कीमत है समीक्षा और चर्न, और Google Play पर वही बाहर-कर-दिए-जाने की झुंझलाहट ठीक वही है जो एक चार्जबैक में बदल जाती है।

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

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

पलटा हुआ रिफंड और साधारण रिफंड एक ही webhook फ़ीड हैं जो विपरीत दिशाओं की ओर इशारा करते हैं। एक को संभालें और दूसरे को छोड़ें, तो आप दोनों छोर पर कीमत चुकाते हैं।

Apple रिफंड क्यों पलटता है, और revocationReason कैसे पढ़ें

पलटाव यादृच्छिक नहीं होता। Apple इसे 'ग्राहक द्वारा उठाए गए विवाद' से जोड़ता है, यानी ग्राहक बाद में रिफंड के निर्णय को चुनौती देता है। जब रिफंड पहली बार दिया गया, तो ट्रांज़ैक्शन एक revocationDate और एक revocationReason लेकर आई, और डाउनस्ट्रीम में कुछ भी उस पर कार्रवाई करने से पहले वह कारण पढ़ने लायक है।

• revocationReason 1: App Store ने 'आपके app के भीतर किसी वास्तविक या कथित समस्या के कारण' रिफंड किया। यह आपके उत्पाद के बारे में एक संकेत है, केवल इस ग्राहक के बारे में नहीं।
• revocationReason 0: App Store ने 'अन्य कारणों से, उदाहरण के लिए, गलती से की गई खरीद' रिफंड किया। कोई app-गुणवत्ता संकेत संलग्न नहीं।

जब उस ट्रांज़ैक्शन के लिए एक REFUND_REVERSED आता है, तो रद्दीकरण को उलटा जा रहा है। आपके बहाली लॉजिक को मूल ट्रांज़ैक्शन id ढूँढना चाहिए, पुष्टि करनी चाहिए कि आपने उसे रद्द किया था, और एंटाइटलमेंट को ठीक वैसा ही वापस रखना चाहिए जैसा वह था।

Google Play पलटाव नहीं भेजता, इसलिए आप इसके बजाय मिलान करते हैं

Google Play का मॉडल अलग है, और यह अंतर मायने रखता है यदि आप दोनों स्टोर को एक ही webhook हैंडलर से चलाते हैं। REFUND_REVERSED का कोई Google समकक्ष नहीं है। Google की रियल-टाइम डेवलपर नोटिफिकेशन रिफंड घटनाओं को दो संदेशों में बाँटती हैं, और पलटाव को मिलान द्वारा संभाला जाता है, push द्वारा नहीं।

रद्द की गई खरीद का नोटिफिकेशन

जब कोई Google Play खरीद रद्द (void) होती है, तो आपके सर्वर को एक VoidedPurchaseNotification मिलती है। यह purchaseToken और orderId को नाम देती है, subscription या one-time का एक productType, और एक refundType जो या तो पूर्ण void है या मल्टी-क्वांटिटी खरीद पर मात्रा-आधारित आंशिक रिफंड। Google कहता है कि वह डेटा सही खरीद ढूँढने और एंटाइटलमेंट समायोजित करने के लिए पर्याप्त है। इससे अधिक किसी भी चीज़ के लिए, यह आपको Voided Purchases API की ओर इशारा करता है, एक pull मॉडल जो आपके द्वारा क्वेरी की गई टाइमस्टैम्प सीमा के भीतर रद्द किए गए ऑर्डर सूचीबद्ध करता है।

चार्जबैक समीक्षा, और इसकी 24 घंटे की घड़ी

चार्जबैक एक अलग संदेश से आते हैं, PendingRefundReviewNotification। जब कोई ग्राहक अपने बैंक के साथ किसी चार्ज पर विवाद करता है, तो Google Play यह नोटिफिकेशन भेजता है और एक घड़ी शुरू करता है। आपके पास orders.reviewrefund को एक रिफंड प्राथमिकता और किसी भी उपयोग साक्ष्य के साथ कॉल करने के लिए 24 घंटे हैं, ताकि Google आपकी ओर से किसी अवैध चार्जबैक का विरोध कर सके। Google आपकी पहली कॉल दर्ज करता है और बाकी को अनदेखा करता है। यह Apple के CONSUMPTION_REQUEST के समानांतर Google का तरीका है, वह एकमात्र खिड़की जहाँ किसी विवाद में आपका पक्ष गिना जाता है।

चूँकि कोई पलटाव push नहीं है, एक चार्जबैक जिसका Google विरोध करता है और जीतता है, किसी सुव्यवस्थित बहाली घटना के रूप में नहीं आता। आप इसका मिलान Voided Purchases API और अपने रिकॉर्ड के विरुद्ध करते हैं। सबक वही है जो App Store पर है: एक रद्द किया गया ऑर्डर हमेशा स्थायी नहीं होता, और आपकी एंटाइटलमेंट स्थिति को पीछे भी जा पाने में सक्षम होना चाहिए, केवल आगे नहीं।

बिना किसी को बाहर किए हर रिफंड नोटिफिकेशन कैसे संभालें

आपको हर स्टोर के लिए अलग पाइपलाइन की ज़रूरत नहीं है। आपको एक ऐसे हैंडलर की ज़रूरत है जो एक एंटाइटलमेंट को दोनों दिशाओं में ले जा सके और हर संदेश को संभवतः डुप्लिकेट मानकर चले।

• बहाली बनाएँ, केवल रद्दीकरण नहीं। हर उस रास्ते के लिए जो REFUND पर एक्सेस हटाता है, उसका उलटा लिखें जो REFUND_REVERSED पर उसे बहाल करता है, उसी ट्रांज़ैक्शन id से जुड़ा हुआ।
• इसे idempotent बनाएँ। दोनों स्टोर एक ही नोटिफिकेशन एक से अधिक बार डिलीवर कर सकते हैं, इसलिए हर रद्दीकरण और बहाली को ट्रांज़ैक्शन या ऑर्डर id से जोड़ें और दोहराव को no-op बनाएँ।
• कार्रवाई से पहले कारण पढ़ें। app-गुणवत्ता वाले रिफंड को गलती वाले से अलग करने के लिए revocationReason का उपयोग करें, और app-गुणवत्ता वालों को उस व्यक्ति तक पहुँचाएँ जो उत्पाद गुणवत्ता का ज़िम्मेदार है।
• साक्ष्य खिड़कियों का समय पर उत्तर दें। किसी CONSUMPTION_REQUEST के 12 घंटे के भीतर Apple का कंज़म्पशन डेटा भेजें, और किसी PendingRefundReviewNotification के 24 घंटे के भीतर orders.reviewrefund कॉल करें।
• हर घटना स्टोर करें। REFUND_DECLINED और कच्चे नोटिफिकेशन रखें, ताकि बाद में आने वाले किसी पलटाव को उस रिफंड से मिलाया जा सके जिसे वह उलटता है।

इनमें से कुछ भी यह नहीं बदलता कि रिफंड होता है या नहीं। यह यह बदलता है कि पलटे हुए रिफंड के दूसरी ओर वाला ग्राहक कभी यह नोटिस करता है या नहीं कि आपका सर्वर इसे गलत कर बैठा।