Apple के फैसला लेने के बाद तीन App Store रिफंड नोटिफिकेशन आते हैं, और REFUND_REVERSED बिक्री वापस दे देता है
Apple App Store Server Notifications V2 के जरिए चार रिफंड संदेश भेजता है, और ज्यादातर ऐप्स केवल दो को संभालते हैं। REFUND आपको एक्सेस रद्द करने को कहता है, REFUND_DECLINED का मतलब है बिक्री रखें, और REFUND_REVERSED बिक्री वापस सौंप देता है और आपसे जो लिया था उसे बहाल करने को कहता है। यहाँ बताया गया है कि हर एक के लिए क्या जरूरी है।
मुख्य बातें
- Apple App Store Server Notifications V2 के जरिए चार रिफंड से जुड़े संदेश भेजता है। CONSUMPTION_REQUEST आपके सबूत माँगता है, और REFUND, REFUND_DECLINED, तथा REFUND_REVERSED तब परिणाम बताते हैं जब Apple पहले ही फैसला कर चुका होता है।
- REFUND नोटिफिकेशन का मतलब है कि App Store ने उस लेनदेन को रिफंड कर दिया। इसमें revocationDate और revocationReason होते हैं, और यह आपके लिए संकेत है कि उस एक लेनदेन से जुड़े एंटाइटलमेंट को रद्द करें, उस उत्पाद की हर खरीद को नहीं।
- revocationReason के दो मान होते हैं। 1 का मतलब है कि रिफंड आपके उत्पाद में किसी समस्या के कारण दिया गया, और 0 का मतलब है कि यह किसी और कारण से दिया गया। समस्या वाला मान एक गुणवत्ता संकेत है जिसे दर्ज करना और उसका रुझान देखना सार्थक है।
- REFUND_DECLINED का मतलब है कि Apple ने ग्राहक के रिफंड को अस्वीकार कर दिया। आप बिक्री रखते हैं और कुछ नहीं बदलते, जो केवल तभी सुरक्षित है जब आपने फैसला अंतिम होने से पहले एक्सेस रद्द नहीं किया था।
- REFUND_REVERSED का मतलब है कि Apple ने पहले दिए गए रिफंड को पलट दिया, आमतौर पर तब जब ग्राहक उस पर विवाद करता है। लेनदेन से revocation फ़ील्ड हट जाते हैं, और Apple का अपना निर्देश यह है कि अगर आपने कंटेंट रद्द किया था, तो आपको उसे बहाल करना होगा।
- चारों नोटिफिकेशन का जवाब HTTP 200 से दें। अगर आपका सर्वर बंद था और कोई छूट गया, तो Get Refund History एंडपॉइंट आपको transaction id से रिफंड किए गए लेनदेन खोजने और मिलान करने देता है।
- किसी बीती हुई सब्सक्रिप्शन अवधि के रिफंड का हमेशा यह मतलब नहीं होता कि एक्सेस समाप्त होनी चाहिए। अगर कोई नई भुगतान की गई अवधि अभी भी सक्रिय है, तो पुराने लेनदेन पर रद्द करने से ऐसे ग्राहक की एक्सेस कट जाती है जो अभी भुगतान कर रहा है।
Apple आपके रिफंड का फैसला करता है, और फिर बात करता रहता है। परिणाम तय होने के बाद, App Store आपके सर्वर को तीन App Store रिफंड नोटिफिकेशन में से एक भेजता है, और हर एक अलग कदम माँगता है। REFUND कहता है कि पैसा जा चुका है और आपको एक्सेस हटा देनी चाहिए। REFUND_DECLINED कहता है कि ग्राहक अनुरोध हार गया और आप बिक्री रखते हैं। REFUND_REVERSED कहता है कि Apple ने पहले दिया गया रिफंड पलट दिया, इसलिए बिक्री फिर आपकी है और आपको जो कुछ हटाया था उसे वापस देना होगा। ज्यादातर ऐप्स पहला वाला जोड़ लेते हैं और बाकी दो को चुपचाप अनदेखा कर देते हैं। इसी तरह एक भुगतान करने वाला ग्राहक उस चीज से बाहर हो जाता है जिसके लिए उसने भुगतान किया।
ये तीनों CONSUMPTION_REQUEST से अलग हैं, जो एकमात्र रिफंड संदेश है जो आपसे जवाब माँगता है। फैसले के बाद वाले नोटिफिकेशन कोई बहस नहीं चाहते। वे एक HTTP 200 और ग्राहक की एक्सेस में सही बदलाव चाहते हैं। यहाँ बताया गया है कि हर एक का क्या मतलब है, कौन से सटीक फ़ील्ड तथ्य ले जाते हैं, और जब आप इन्हें गलत तरीके से संभालते हैं तो पैसा कहाँ रिसता है।
चार रिफंड नोटिफिकेशन, और कौन सा जवाब चाहता है
App Store Server Notifications V2 एक ही फ़ीड है। आप इसे एक URL पर सेट करते हैं और Apple हर नोटिफिकेशन प्रकार उस पर भेजता है, इसलिए आप चारों रिफंड संदेश पहले से पा रहे हैं चाहे आप उन्हें संभालें या न संभालें। इनमें से चार प्रकार रिफंड से जुड़े हैं, और उनमें से केवल एक सवाल है।
| नोटिफिकेशन | Apple आपको क्या बता रहा है | आपकी कार्रवाई | जवाब अपेक्षित |
|---|---|---|---|
| CONSUMPTION_REQUEST | एक ग्राहक ने रिफंड माँगा और Apple आपका डेटा चाहता है | 12 घंटे के भीतर Send Consumption Information भेजें | हाँ, असली डेटा |
| REFUND | App Store ने लेनदेन को रिफंड किया | उस लेनदेन के लिए एंटाइटलमेंट रद्द करें | नहीं, HTTP 200 |
| REFUND_DECLINED | App Store ने रिफंड अस्वीकार किया | एक्सेस रखें, कुछ न बदलें | नहीं, HTTP 200 |
| REFUND_REVERSED | Apple ने दिया गया रिफंड पलट दिया | जो कंटेंट आपने रद्द किया उसे बहाल करें | नहीं, HTTP 200 |
एक REFUND नोटिफिकेशन असल में आपको क्या बताता है
REFUND तब चलता है जब App Store ने किसी ग्राहक को लेनदेन सफलतापूर्वक रिफंड कर दिया हो। यह हर खरीद प्रकार पर लागू होता है: एक consumable, एक non-consumable, एक auto-renewable सब्सक्रिप्शन, और एक non-renewing सब्सक्रिप्शन। नोटिफिकेशन के अंदर हस्ताक्षरित लेनदेन में अब दो फ़ील्ड होते हैं जो रिफंड से पहले नहीं थे, और वही दो फ़ील्ड पूरी कहानी हैं।
revocationDate और revocationReason तथ्य ले जाते हैं
revocationDate वह UNIX समय है, मिलीसेकंड में, जब App Store ने लेनदेन को रिफंड किया या रद्द किया। revocationReason आपको रिफंड की श्रेणी बताता है, और यह ठीक दो मान लेता है।
| revocationReason | Apple का अर्थ | इसमें क्या समझें |
|---|---|---|
| 1 | रिफंड उत्पाद में किसी समस्या के कारण दिया गया | एक गुणवत्ता या डिलीवरी संकेत। इसे दर्ज करें, इसका रुझान देखें, और किसी एक उत्पाद या एक बिल्ड में पैटर्न खोजें |
| 0 | रिफंड किसी और कारण से दिया गया | एक सामान्य रिफंड। एंटाइटलमेंट रद्द करें और आगे बढ़ें |
किसी लेनदेन पर revocationDate की मौजूदगी अपने आप में संकेत है। अगर आप बाद में कोई लेनदेन लाते हैं और उसमें revocationDate है, तो वह खरीद रिफंड हो चुकी है, नोटिफिकेशन हो या न हो। इसके साथ कारण भी पढ़ें ताकि किसी एक रिलीज़ पर value-1 रिफंड की लहर शोर के रूप में आपके पास से न निकल जाए।
उत्पाद के अनुसार नहीं, लेनदेन के अनुसार रद्द करें
यहाँ जाल है बहुत ज्यादा रद्द कर देना। एक REFUND एक लेनदेन का नाम लेता है। यह आपको यह नहीं कहता कि उस product id की हर खरीद को अक्षम कर दें जो ग्राहक ने कभी की। Apple का अपना मार्गदर्शन यह है कि कुछ भी काटने से पहले जाँचें कि ग्राहक के पास अभी भी क्या एक्सेस है, क्योंकि एंटाइटलमेंट आपस में ओवरलैप करते हैं। सबसे आम मामला एक सब्सक्रिप्शन का है: पिछले महीने के नवीनीकरण पर रिफंड आता है जबकि इस महीने का नवीनीकरण सक्रिय और पूरी तरह भुगतान किया हुआ है। उत्पाद पर रद्द करें और आपने अभी एक मौजूदा, भुगतान करने वाले ग्राहक की एक्सेस उस अवधि के रिफंड पर काट दी जो पहले ही समाप्त हो चुकी थी।
REFUND_DECLINED का मतलब है आप पहले ही जीत चुके हैं, इसलिए इसे उलटें नहीं
REFUND_DECLINED तब आता है जब App Store ने ग्राहक के रिफंड अनुरोध को अस्वीकार किया। ग्राहक ने माँगा, Apple ने मना किया, और आप बिक्री रखते हैं। ऊपरी तौर पर करने को कुछ नहीं है, और यही बात है। यह नोटिफिकेशन जो गलती उजागर करता है वह अलग है: एक्सेस जल्दी रद्द कर देना।
अगर आपका कोड Apple के फैसला देने से पहले CONSUMPTION_REQUEST पर प्रतिक्रिया करके ग्राहक की एक्सेस हटा देता है, तो एक REFUND_DECLINED वही पल है जब वह फैसला फट पड़ता है। Apple ने आपका पैसा रखा, और आपने ऐसे ग्राहक की एक्सेस रोक दी जिसका रिफंड अस्वीकार हुआ था। वह ग्राहक अब ऐसे उत्पाद के लिए भुगतान करता है जिसे वह इस्तेमाल नहीं कर सकता, एक सपोर्ट टिकट खोलता है, और इसे याद रखता है। इसका समाधान एक नियम है, कोई फ़ीचर नहीं: REFUND पर रद्द करें, कभी अनुरोध पर नहीं। REFUND_DECLINED बस Apple की पुष्टि है कि जल्दी रद्द करना गलत फैसला होता।
REFUND_REVERSED वह नोटिफिकेशन है जो आपको वापस भुगतान करता है
REFUND_REVERSED वह है जिसे लगभग कोई नहीं संभालता, और यही वह है जो आपको पैसा लौटाता है। Apple इसे तब भेजता है जब वह पहले दिए गए रिफंड को पलटता है, आमतौर पर ग्राहक के उस रिफंड पर विवाद करने के बाद। जो revocation फ़ील्ड एक REFUND ने लेनदेन में जोड़े थे वे फिर हटा दिए जाते हैं, इसलिए खरीद फिर से भुगतान की हुई दिखती है। Apple डेवलपर का काम एक पंक्ति में बताता है: अगर आपके ऐप ने संबंधित रिफंड के परिणामस्वरूप कंटेंट या सेवाएँ रद्द की थीं, तो उन्हें बहाल करना जरूरी है। यह किसी भी खरीद प्रकार पर लागू होता है, एक consumable से लेकर एक auto-renewable सब्सक्रिप्शन तक।
हफ्तों बाद वाली समस्या
डेवलपर जो असली सवाल उठाते हैं, Apple के अपने फ़ोरम पर, वह समय का है। एक REFUND_REVERSED मूल REFUND के हफ्तों बाद आ सकता है, किसी सब्सक्रिप्शन अवधि की समाप्ति के बहुत बाद। क्या आप तब एक्सेस बहाल करते हैं? जो लेनदेन असल में देता है उसे बहाल करें, उस दायरे तक सीमित जो वह लेनदेन कवर करता है। किसी consumable या non-consumable के लिए, अनलॉक वापस चालू करें। जो सब्सक्रिप्शन अवधि पहले ही बीत चुकी है, उसके लिए आप नया समय नहीं दे रहे, आप रिकॉर्ड सही कर रहे हैं ताकि ग्राहक का इतिहास सटीक रहे और कोई भी एंटाइटलमेंट जो अभी भी वैध है फिर से चालू हो जाए। विशिष्ट लेनदेन को बहाल करें, और आपका ओवरलैप तर्क तय करता है कि अभी क्या सक्रिय है।
इसे सही करने में पैसा कहाँ है
इनमें से हर नोटिफिकेशन एक असली संख्या से जुड़ता है, और इसे गलत संभालने की लागत केवल बिक्री की कीमत नहीं है।
REFUND: किसी रिफंड किए गए ग्राहक की सेवा में पैसा खर्च करना बंद करें
REFUND आते ही बिक्री की कीमत चली जाती है। जो आप अभी भी नियंत्रित कर सकते हैं वह है डिलीवरी जारी रखने की लागत। हर घंटे जब एक रिफंड किया गया एंटाइटलमेंट चालू रहता है, आप उन चीजों पर खर्च करते रहते हैं जिनके लिए ग्राहक अब भुगतान नहीं करता: कंप्यूट, मॉडल API कॉल, स्टोरेज, और उनके उपयोग से जुड़ा कोई भी क्रिएटर या पार्टनर भुगतान। REFUND पर तुरंत रद्द करना उस मीटर को रोक देता है। नोटिफिकेशन को अनदेखा करने का मतलब है आप किसी ऐसे व्यक्ति के लिए उत्पाद को फंड करते हैं जिसे स्टोर पहले ही पूरा भुगतान कर चुका है।
REFUND_DECLINED: एक जीत को सद्भावना के रिफंड में मत बदलिए
जब आप जल्दी रद्द करते हैं और रिफंड बाद में अस्वीकार होता है, तो आपने कागज पर बिक्री रखी और व्यवहार में खो दी। जिस ग्राहक ने भुगतान किया वह उत्पाद इस्तेमाल नहीं कर सकता, इसलिए आपको एक सपोर्ट बातचीत विरासत में मिलती है और, अक्सर, इसे ठीक करने के लिए एक विवेकाधीन रिफंड। यह एक ऐसी बिक्री के लिए दो बार भुगतान करना है जो कभी खतरे में थी ही नहीं। REFUND_DECLINED को सही संभालने में कुछ खर्च नहीं होता, और यही वजह है कि REFUND तक एक्सेस को अछूता छोड़ना सबसे सस्ता नियम है जिसे आप अपना सकते हैं।
REFUND_REVERSED: सबसे बुरी जोड़ी है उनका पैसा और उनकी एक्सेस दोनों चले जाना
REFUND_REVERSED को अनदेखा करें और आप बोर्ड पर सबसे बुरे परिणाम तक पहुँच जाते हैं। आपको भुगतान मिल चुका है, और ग्राहक के पास कुछ नहीं है। वे रिफंड पलटने के लिए अपने बैंक से एक बार पहले ही संपर्क कर चुके हैं, और एक व्यक्ति जो ऐसे उत्पाद से बाहर है जिसके लिए उससे अब शुल्क लिया जा रहा है, ऐसा व्यक्ति है जो दूसरी बार बैंक से संपर्क करने की संभावना रखता है। वह अगला विवाद एक कार्ड चार्जबैक बन सकता है, जो बैंक की ओर से अंतिम होता है और बिक्री से कहीं अधिक खर्च कराता है। REFUND_REVERSED आते ही एक्सेस बहाल करना पूरे रिफंड फ्लो में सबसे सस्ता बीमा है।
क्या सेट करना है
मॉडल सही होने पर संभालना छोटा है। एंटाइटलमेंट को transaction id पर आधारित करें ताकि हर नोटिफिकेशन एक खरीद की ओर इशारा करे। CONSUMPTION_REQUEST पर, अपना डेटा 12 घंटे के भीतर भेजें। REFUND पर, उस लेनदेन को रद्द करें। REFUND_DECLINED पर, कुछ न करें। REFUND_REVERSED पर, बहाल करें। इन सभी पर जल्दी HTTP 200 लौटाएँ और एक्सेस का बदलाव अपने समय पर करें।
नोटिफिकेशन जो कमी छोड़ते हैं, उसके लिए Get Refund History एंडपॉइंट का उपयोग करें। अगर आपका सर्वर किसी आउटेज के दौरान बंद था और कोई REFUND छूट गया, तो किसी transaction id के लिए App Store Server API रिफंड लुकअप को कॉल करें, /inApps/v2/refund/lookup/{transactionId} पर, और हस्ताक्षरित लेनदेन को उनके revocationDate और revocationReason के साथ वापस पढ़ें। यह एक बार में एक लेनदेन का मिलान करता है और किसी ग्राहक की रिफंड की गई खरीदों में पेज करता है, इसलिए एक छूटा हुआ वेबहुक स्थायी रूप से गलत सेट एंटाइटलमेंट नहीं बनता।
यह वह हिस्सा है जो RefundHalt आपके लिए चलाता है। यह चारों प्रकार सुनता है, REFUND पर रद्द करता है, REFUND_DECLINED पर एक्सेस को अछूता रखता है, और REFUND_REVERSED पर अपने आप बहाल करता है, हर एक ठीक उस लेनदेन से जुड़ा। एक पलटा गया रिफंड किसी कतार में नहीं बैठा रहता जबकि एक भुगतान करने वाला ग्राहक बाहर रहता है, और एक अस्वीकार किया गया कभी ऐसा रद्द नहीं करता जिसे आपको वापस पलटना पड़े।
अक्सर पूछे जाने वाले सवाल
- REFUND और REFUND_REVERSED में क्या अंतर है?
- REFUND का मतलब है कि App Store ने एक लेनदेन को रिफंड किया और आपको वह एंटाइटलमेंट रद्द करना चाहिए, जबकि REFUND_REVERSED का मतलब है कि Apple ने दिया गया रिफंड पलट दिया और आपको जो कंटेंट रद्द किया था उसे बहाल करना चाहिए। ये दोनों एक जोड़ी हैं: एक खरीद REFUND हो सकती है और फिर, अगर ग्राहक का विवाद पलटा जाता है, REFUND_REVERSED। अपने एक्सेस बदलावों को transaction id पर आधारित करें ताकि हर नोटिफिकेशन सही खरीद पर काम करे।
- क्या मुझे किसी REFUND नोटिफिकेशन के लिए कुछ वापस भेजना पड़ता है?
- नहीं। आप REFUND, REFUND_DECLINED, और REFUND_REVERSED का जवाब एक HTTP 200 और बिना बॉडी के देते हैं। केवल CONSUMPTION_REQUEST आपसे डेटा भेजने को कहता है, और वह Send Consumption Information एंडपॉइंट के जरिए 12 घंटे के भीतर ऐसा करता है। बाकी तीन Apple के एक फैसले की सूचना हैं, कोई सवाल नहीं।
- REFUND_DECLINED नोटिफिकेशन मिलने पर मुझे क्या करना चाहिए?
- कुछ नहीं बदलता, क्योंकि ग्राहक का रिफंड अस्वीकार हो गया और आप बिक्री रखते हैं। REFUND_DECLINED केवल तभी काम पैदा करता है जब आपने Apple के फैसला देने से पहले एक्सेस जल्दी रद्द कर दी हो। CONSUMPTION_REQUEST के बजाय REFUND पर रद्द करें, और एक REFUND_DECLINED इस पुष्टि में बदल जाता है कि एक्सेस को सही ढंग से अछूता छोड़ा गया था।
- जब REFUND_REVERSED रिफंड के हफ्तों बाद आए तो क्या मुझे एक्सेस बहाल करनी चाहिए?
- हाँ, उस विशिष्ट लेनदेन द्वारा दिए गए एंटाइटलमेंट को बहाल करें। Apple कहता है कि अगर आपके ऐप ने संबंधित रिफंड के कारण कंटेंट रद्द किया था, तो उसे बहाल करना जरूरी है। किसी consumable या non-consumable के लिए, अनलॉक वापस चालू करें। जो सब्सक्रिप्शन अवधि पहले ही समाप्त हो चुकी है, उसके लिए आप रिकॉर्ड सही कर रहे हैं, नया समय नहीं दे रहे, इसलिए आपका ओवरलैप तर्क अब भी तय करता है कि अभी क्या सक्रिय है।
- मेरे सर्वर से छूटा हुआ रिफंड नोटिफिकेशन मैं कैसे पकड़ूँ?
- App Store Server API Get Refund History एंडपॉइंट का उपयोग करें, जो किसी ग्राहक के रिफंड किए गए लेनदेन को transaction id से /inApps/v2/refund/lookup/{transactionId} पर खोजता है। यह हस्ताक्षरित लेनदेन revocationDate और revocationReason के साथ लौटाता है, इसलिए किसी आउटेज के बाद आप पहले ही चल चुके नोटिफिकेशन का इंतजार किए बिना एक्सेस का मिलान कर सकते हैं। यह प्रति कॉल एक transaction id संभालता है और ग्राहक की रिफंड की गई खरीदों में पेज करता है।
स्रोत और आगे की जानकारी
RefundHalt
App Store और Google Play के लिए refund ऑटोपायलट
आगे पढ़ें
अब हर Apple रिफंड अनुरोध एक कारण के साथ आता है, और उसे पढ़ने का तरीका consumptionRequestReason है
WWDC24 के बाद से, हर Apple CONSUMPTION_REQUEST एक consumptionRequestReason ले जाता है, यानी रिफंड चाहने के लिए ग्राहक का खुद बताया गया कारण। इसके पाँच मान हैं, UNINTENDED_PURCHASE से LEGAL तक, और हर एक को आपकी 12 घंटे की विंडो के भीतर आपके भेजे जाने वाले जवाब को बदलना चाहिए। यहाँ बताया गया है कि हर एक को कैसे पढ़ें।
Google Play की chargeback समीक्षा आपको जवाबी कार्रवाई के लिए 24 घंटे देती है, यहाँ जानिए क्या भेजना है
जब कोई बैंक Google Play का कोई चार्ज वापस खींचता है, तो Google आपके सर्वर पर एक PendingRefundReviewNotification भेजता है और 24 घंटे की घड़ी शुरू कर देता है। इसका जवाब ReviewRefund API के ज़रिए एक refund प्राथमिकता और असली उपभोग के प्रमाण के साथ दें, वरना विवाद आपके बिना ही तय हो जाएगा। यहाँ पूरी प्रक्रिया है, फ़ील्ड दर फ़ील्ड।