आपके dashboard पर एक रिफंड आता है और आपको पता ही नहीं चलता कि क्यों। ग्राहक ने दो हफ्ते तक ऐप इस्तेमाल किया, फिर पैसे वापस चले गए लेकिन उसकी access बनी रही। आपकी कोई राय नहीं ली गई। ज़्यादातर iOS टीमें Apple रिफंड प्रोसेस से इसी तरह मिलती हैं—घटना हो जाने के बाद, बिना किसी संदर्भ के।
Apple रिफंड को मंज़ूर या अस्वीकार कैसे करता है, यह समझना ज़रूरी है क्योंकि इससे आपका असली revenue तय होता है। अंतिम फ़ैसला Apple का ही होता है, लेकिन डेवलपर्स उस फ़ैसले में डेटा दे सकते हैं, और ज़्यादातर टीमें ऐसा कभी करती ही नहीं। अगर आप बचे जा सकने वाले नुकसान को कम करना चाहते हैं, तो हमारी Apple रिफंड गाइड से शुरुआत करें, फिर आगे पढ़ें कि फ़ैसला असल में कैसे लिया जाता है।
यह एक खरीदार के तौर पर रिफंड पाने की गाइड नहीं है। यह बताता है कि Apple रिफंड approval इंजन कैसे काम करता है, और डेवलपर के तौर पर आप इसमें क्या प्रभाव डाल सकते हैं।
मुख्य बातें
• हर App Store खरीद पर अंतिम रिफंड फ़ैसला Apple लेता है, डेवलपर नहीं।
• Apple एक Refund Decisioning System चलाता है जो ट्रांज़ैक्शन की जानकारी, खरीद इतिहास और रिफंड इतिहास को तौलता है।
• योग्य खरीद के लिए, Apple एक CONSUMPTION_REQUEST भेजता है और आपको consumption डेटा के साथ जवाब देने के लिए 12 घंटे देता है।
• अगर आप समय पर जवाब नहीं देते, तो Apple अक्सर डिफ़ॉल्ट रूप से रिफंड मंज़ूर कर देता है।
• App Store Server Notifications आपको नतीजा बताते हैं: मंज़ूर होने पर REFUND, अस्वीकार होने पर REFUND_DECLINED।
• आपके पास सबूत और अपनी प्रतिक्रिया की गति पर नियंत्रण है। अंतिम फ़ैसले पर आपका कोई नियंत्रण नहीं है।
• स्पष्ट बिलिंग, ठीक से काम करने वाली फ़ंक्शनैलिटी, और तेज़ सपोर्ट शुरुआत में ही मिलने वाले रिफंड अनुरोधों को कम कर देते हैं।
जब कोई Apple रिफंड का अनुरोध करता है, तो क्या होता है?
जब कोई ग्राहक App Store रिफंड का अनुरोध करता है, तो वह अनुरोध Apple के पास जाता है, आपके पास नहीं। ग्राहक Apple के अपने report a problem फ़्लो का इस्तेमाल करता है, और Apple का सिस्टम एक रिव्यू शुरू कर देता है। जब तक खरीद का प्रकार डेवलपर इनपुट के योग्य न हो, तब तक आप इस प्रक्रिया में शामिल नहीं होते।
पूरी इनटेक प्रक्रिया Apple ही संभालता है। ग्राहक एक कारण चुनता है, जैसे did not mean to purchase या app did not work। Apple का सिस्टम उस कारण को लॉग करता है और उसे अकाउंट व ट्रांज़ैक्शन के बारे में पहले से मौजूद जानकारी के साथ जांचना शुरू कर देता है।
उदाहरण। एक यूज़र $9.99 का कॉइन पैक खरीदता है, एक घंटे खेलता है, फिर यह कहते हुए रिफंड की फ़ाइलिंग करता है कि यह गलती से हुआ। Apple को यह दावा सबसे पहले मिलता है। क्या आपको इसके बारे में कभी पता चलेगा, यह प्रोडक्ट के प्रकार और Apple के अपने सिग्नल्स पर निर्भर करता है।
Apple रिफंड अनुरोधों की समीक्षा कैसे करता है
Apple एक ऑटोमेटेड सिस्टम के ज़रिए रिफंड अनुरोधों की समीक्षा करता है जो ट्रांज़ैक्शन, ग्राहक के खरीद इतिहास और उनके पिछले रिफंड को तौलता है। Apple ने सार्वजनिक रूप से इसे Refund Decisioning System बताया है। यह केवल सामने मौजूद एक अनुरोध को नहीं, बल्कि पैटर्न को देखता है।
consumable खरीद और कुछ अन्य प्रकारों के लिए, Apple फ़ैसला लेने से पहले आपसे इनपुट भी मांग सकता है। यह अनुरोध एक CONSUMPTION_REQUEST नोटिफ़िकेशन के रूप में आता है। इसके बाद आपके पास ऐसा डेटा भेजने के लिए एक छोटी सी समय-सीमा होती है जो Apple को दावे को परखने में मदद करे।
रिफंड अनुरोध चरण | Apple क्या करता है | डेवलपर क्या कर सकते हैं |
ग्राहक अनुरोध दर्ज करता है | कारण लॉग करता है और रिव्यू शुरू करता है | अभी कुछ नहीं, कोई सिग्नल नहीं भेजा गया |
योग्य खरीद की जांच | लागू होने पर CONSUMPTION_REQUEST भेजता है | अपने सर्वर पर नोटिफ़िकेशन प्राप्त करें |
सबूत की समय-सीमा | आपके डेटा के लिए 12 घंटे तक इंतज़ार करता है | API के ज़रिए consumption जानकारी भेजें |
फ़ैसला | इतिहास, सबूत और कारण को तौलता है | कुछ नहीं, Apple ही तय करता है |
नतीजा भेजा जाता है | REFUND या REFUND_DECLINED भेजता है | entitlements और रिकॉर्ड अपडेट करें |
डेवलपर के लिए सार फ़ैसला Apple ही लेता है, लेकिन CONSUMPTION_REQUEST उसे प्रभावित करने का आपका एकमात्र मौका है। 12 घंटे की समय-सीमा चूक जाने पर आप Apple को केवल ग्राहक का पक्ष सौंप देते हैं। |
Apple रिफंड approval को प्रभावित करने वाले कारक
Apple रिफंड approval बताए गए कारण, ग्राहक के इतिहास, खरीद का कितना हिस्सा इस्तेमाल हुआ, और डेवलपर ने सहायक डेटा भेजा या नहीं—इन सब पर निर्भर करता है। कोई एक कारक अकेले नतीजे की गारंटी नहीं देता। Apple इन सबको एक साथ तौलता है।
Apple के अपने मार्गदर्शन और CONSUMPTION_REQUEST के डिज़ाइन के आधार पर, ये सिग्नल मायने रखते हैं:
• ग्राहक ने जो रिफंड कारण चुना।
• अकाउंट का खरीद और रिफंड इतिहास, जो बार-बार रिफंड लेने वालों को फ़्लैग करता है।
• ग्राहक पहले ही consumable का कितना हिस्सा इस्तेमाल कर चुका है।
• क्या खरीद से पहले कोई फ्री सैंपल, ट्रायल, या स्पष्ट फ़ंक्शनैलिटी उपलब्ध थी।
• वह consumption डेटा जो डेवलपर 12 घंटे की समय-सीमा के भीतर भेजता है।
विश्लेषण। अकाउंट इतिहास वाला हिस्सा ही वजह है कि एक पहली बार खरीदने वाले और बार-बार रिफंड लेने वाले को एक ही दावे पर अलग-अलग जवाब मिल सकते हैं। यह सिस्टम की एक्सपर्ट समझ है, कोई दस्तावेज़ी नियम नहीं, इसलिए इसे एक वादे के बजाय एक पैटर्न के रूप में लें।
App Store Server Notifications डेवलपर्स की मदद कैसे करते हैं
App Store Server Notifications वे मैसेज हैं जो Apple आपके सर्वर को खरीद से जुड़ी घटनाओं के बारे में भेजता है, जिसमें रिफंड भी शामिल हैं। इन्हीं से आपको पता चलता है कि कोई रिफंड हुआ, वह मंज़ूर हुआ या नहीं, और क्यों। इनके बिना, रिफंड आपके बैकएंड के लिए अदृश्य होते हैं।
version 2 नोटिफ़िकेशन ज़्यादा साफ़ हैं क्योंकि हर एक में केवल उस घटना का ट्रांज़ैक्शन होता है। रिफंड के लिए, मुख्य प्रकार हैं: जब Apple को आपका इनपुट चाहिए तो CONSUMPTION_REQUEST, रिफंड मंज़ूर होने पर REFUND, और अनुरोध अस्वीकार होने पर REFUND_DECLINED। एक REFUND payload में revocationReason और revocationDate भी होता है।
एक सामान्य रिफंड चुपचाप चार्ज को रिवर्स कर सकता है जबकि access चालू रहती है, इसलिए ये नोटिफ़िकेशन ही हैं जो आपके सर्वर को किसी भी तरह से प्रतिक्रिया करने देते हैं।
उदाहरण। आपके सर्वर को revocationReason के साथ एक REFUND नोटिफ़िकेशन मिलता है। आप मूल ट्रांज़ैक्शन ID पढ़ते हैं, entitlement रद्द करते हैं, और अपने रिकॉर्ड अपडेट करते हैं। नोटिफ़िकेशन न मिलने का मतलब है कि इनमें से कुछ भी नहीं होता।
डेवलपर्स क्या नियंत्रित कर सकते हैं और क्या नहीं
डेवलपर्स अपनी प्रतिक्रिया की गति और गुणवत्ता, अपनी बिलिंग की स्पष्टता, और अपने प्रोडक्ट अनुभव को नियंत्रित करते हैं। डेवलपर्स Apple के अंतिम फ़ैसले, ग्राहक द्वारा बताए गए कारण, या Apple की आंतरिक स्कोरिंग को नियंत्रित नहीं करते। यह अंतर समझने से आपकी उम्मीदें सही बनी रहती हैं।
डेवलपर इनपुट | Apple रिव्यू | अंतिम नतीजा |
समय पर consumption डेटा भेजें | अकाउंट सिग्नल्स के साथ इसे तौलता है | कमज़ोर दावों को अस्वीकार कर सकता है |
कुछ न भेजें | केवल अपने ही सिग्नल्स का इस्तेमाल करता है | अक्सर डिफ़ॉल्ट रूप से मंज़ूर कर देता है |
स्पष्ट ट्रायल और बिलिंग शर्तें | सैंपल कंटेंट फ़्लैग देखता है | "मैंने अधिकृत नहीं किया" वाले दावे कम |
तेज़ इन-ऐप सपोर्ट | Apple को सीधे नहीं दिखता | Apple तक कम अनुरोध पहुंचते हैं |
वे सामान्य कारण जिनसे Apple रिफंड अस्वीकार कर सकता है
Apple रिफंड को अस्वीकार कर सकता है जब दावा सबूतों से मेल नहीं खाता, जब ग्राहक का रिफंड लेने का एक पैटर्न होता है, या जब मज़बूत consumption डेटा दिखाता है कि खरीद का इस्तेमाल इच्छित तरीके से हुआ। StoreKit के ज़रिए किए गए अनुरोधों के लिए, REFUND_DECLINED नोटिफ़िकेशन इन नतीजों का संकेत देता है।
अनुरोध के अस्वीकार होने की संभावना ज़्यादा होती है जब:
• ग्राहक पहले ही consumable खरीद का ज़्यादातर हिस्सा इस्तेमाल कर चुका हो।
• अकाउंट में कई खरीद पर बार-बार रिफंड की गतिविधि दिखती हो।
• डेवलपर ने सामान्य, अपेक्षित इस्तेमाल के स्पष्ट सबूत भेजे हों।
• कोई सैंपल या ट्रायल उपलब्ध था, जिससे did not know वाला दावा कमज़ोर पड़ता हो।
उदाहरण। ज़्यादातर कॉइन खर्च करने के बाद एक यूज़र कॉइन पैक पर रिफंड मांगता है। डेवलपर उस खर्च को दिखाने वाला consumption डेटा भेजता है। यह सबूत Apple को अस्वीकार करने का स्पष्ट कारण देता है।
डेवलपर्स के लिए बेस्ट प्रैक्टिस
बेस्ट प्रैक्टिस सीधी है: हर रिफंड सिग्नल को कैप्चर करें, असली डेटा के साथ CONSUMPTION_REQUEST का जल्दी जवाब दें, और उन कारणों को कम करें जिनसे लोग रिफंड मांगते हैं। आप फ़ैसला नहीं जीत सकते, लेकिन आप इनपुट्स को आकार दे सकते हैं।
• App Store Server Notifications V2 सेट करें और CONSUMPTION_REQUEST, REFUND, और REFUND_DECLINED को हैंडल करें।
• अपने consumption रिस्पॉन्स को ऑटोमेट करें ताकि यह 12 घंटे की समय-सीमा के भीतर अच्छी तरह से भेजा जाए।
• appAccountToken के साथ खरीद को यूज़र से लिंक करें ताकि आप असली गतिविधि के साथ जवाब दे सकें।
• चेकआउट से पहले बिलिंग शर्तें और ट्रायल की जानकारी स्पष्ट रखें।
• रिफंड मंज़ूर होने पर access रद्द करें, क्योंकि Apple आपके लिए entitlements नहीं हटाता।
अगर आपका volume ज़्यादा है, तो मैन्युअल हैंडलिंग यह रेस हार जाएगी। जो टीमें CONSUMPTION_REQUEST रिस्पॉन्स को ऑटोमेट करती हैं, वे उस revenue को बचा लेती हैं जिसे चुप रहने वाली टीमें डिफ़ॉल्ट रूप से वापस दे देती हैं।
डेवलपर के लिए सार आप Apple के फ़ैसले को नियंत्रित नहीं कर सकते, लेकिन यह ज़रूर नियंत्रित कर सकते हैं कि Apple आपका पक्ष सुने या नहीं। तेज़, सबूत-आधारित जवाब और स्पष्ट बिलिंग ही वे लीवर हैं जो वास्तव में रिफंड के नतीजों को बदलते हैं। |
अंतिम विचार
हर App Store रिफंड का फ़ैसला Apple ही लेता है, और यह नहीं बदलेगा। आपके आंकड़े इस बात से बदलते हैं कि जब Apple इनपुट मांगता है तो आपका सर्वर मौजूद रहता है या नहीं, और कोई पैसे वापस मांगे उससे पहले आपका प्रोडक्ट और बिलिंग कितने साफ़-सुथरे हैं।
रिफंड फ़्लो को एक ऐसे सिस्टम की तरह समझें जिसे आप डेटा देते हैं, न कि एक ऐसे फ़ैसले की तरह जिसका आप इंतज़ार करते हैं। नोटिफ़िकेशन कैप्चर करें, असली डेटा के साथ CONSUMPTION_REQUEST का जवाब दें, और अपने entitlements को सिंक में रखें। जो टीमें ऐसा करती हैं, वे चुपचाप उस revenue को बचा लेती हैं जिसे बाकी लोग जाते हुए कभी नोटिस भी नहीं करते।
अक्सर पूछे जाने वाले प्रश्न
हर रिफंड का फ़ैसला Apple लेता है, डेवलपर नहीं।
डेवलपर्स के पास consumption डेटा भेजने के लिए 12 घंटे होते हैं।
यह Apple का एक नोटिफ़िकेशन है जो किसी योग्य रिफंड अनुरोध के लिए consumption डेटा मांगता है।
Apple एक REFUND या REFUND_DECLINED सर्वर नोटिफ़िकेशन भेजता है।
नहीं। डेवलपर्स केवल Apple के फ़ैसले में मदद के लिए consumption डेटा दे सकते हैं।
हां। खरीद का इस्तेमाल उन कारकों में से एक है जिन पर Apple विचार करता है।
हां। सब्सक्रिप्शन रिफंड का फ़ैसला भी Apple ही लेता है और रिफंड नोटिफ़िकेशन भेजता है।
आपके सर्वर को ग्राहक की access या entitlement रद्द कर देनी चाहिए।
