लंबे समय तक "मैं Apple रिफंड रिक्वेस्ट का जवाब कैसे दूं" का ईमानदार जवाब यही था कि आप नहीं दे सकते। Apple पेमेंट लेता था, रिक्वेस्ट लेता था, फैसला करता था, और डेवलपर को इसकी पहली खबर तब मिलती थी जब पेआउट कम आता था। 2021 से यह सच नहीं रहा, हालांकि अब भी बहुत से लोग ऐसा मानते हैं।
अब फैसला लेने से पहले Apple आपके सर्वर से पूछता है कि उसे पर्चेज़ के बारे में क्या पता है, और जवाब के लिए लगभग 12 घंटे इंतज़ार करता है। हम पहले ही लिख चुके हैं कि CONSUMPTION_REQUEST में वास्तव में क्या होता है, इसलिए मैं पेलोड को फील्ड-बाय-फील्ड दोबारा नहीं बताऊंगा। यह लेख इस बारे में है कि जब यह रिक्वेस्ट आए तो क्या करें।
मुख्य बातें
हर App Store रिफंड का फैसला Apple करता है। आप जो भेजते हैं, उससे यह नहीं बदलता, लेकिन इससे यह बदल जाता है कि फैसला लेते समय Apple को क्या पता होता है।
यह रिक्वेस्ट CONSUMPTION_REQUEST नोटिफिकेशन के रूप में आती है, और सिर्फ consumables और auto-renewable subscriptions के लिए आती है।
आपके पास Send Consumption Information endpoint के ज़रिए जवाब देने के लिए 12 घंटे हैं, जिसमें अब पांच फील्ड चाहिए होते हैं।
जवाब मुख्य रूप से तीन तथ्यों पर आधारित होता है: क्या इसे डिलीवर किया गया, कितना इस्तेमाल हुआ, क्या उन्हें पहले कोई फ्री सैंपल मिला था। साथ ही आपकी प्रेफरेंस।
हमारे अनुभव में, जो रिफंड डेवलपर्स गंवाते हैं, वे ज़्यादातर वही होते हैं जिनका किसी ने जवाब ही नहीं दिया।
Apple App Store रिफंड रिक्वेस्ट क्या है?
Apple App Store रिफंड रिक्वेस्ट तब बनती है जब कोई कस्टमर किसी ऐप या इन-ऐप पर्चेज़ पर अपना पैसा वापस मांगने के लिए Apple से संपर्क करता है। आपसे नहीं। वे reportaproblem.apple.com पर जाते हैं, या इन-ऐप रिफंड शीट का इस्तेमाल करते हैं, एक छोटे मेनू से कारण चुनते हैं, पर्चेज़ चुनते हैं और सबमिट कर देते हैं। Apple का सपोर्ट पेज उन्हें बताता है कि 24 से 48 घंटे में जवाब मिलने की उम्मीद करें।
अगर पर्चेज़ कोई consumable या auto-renewable subscription था, तो Apple आपके सर्वर को पिंग करता है और पूछता है कि आपको क्या पता है, फिर आपके जवाब को कस्टमर के अपने पर्चेज़ और रिफंड हिस्ट्री के साथ जोड़ता है, जिसे वह आपसे कहीं बेहतर जानता है, और फैसला लेता है। आपको कस्टमर का नाम नहीं दिखता और आपको वीटो नहीं मिलता। आपको तथ्य रखने के लिए बस एक छोटी सी खिड़की मिलती है।
डेवलपर्स के लिए Apple रिफंड प्रोसेस कैसे काम करता है
डेवलपर्स के लिए Apple रिफंड प्रोसेस चार चरणों में चलता है, और आप इनमें से सिर्फ एक को छूते हैं।
कस्टमर Apple से रिफंड मांगता है और एक कारण चुनता है।
Apple उस सर्वर URL पर CONSUMPTION_REQUEST भेजता है जो आपने App Store Connect में रजिस्टर किया था। ऐसा सिर्फ consumables और auto-renewable subscriptions के लिए होता है।
आपके पास अपने डेटा के साथ Send Consumption Information endpoint को कॉल करने के लिए 12 घंटे हैं।
Apple फैसला लेता है, फिर आपको REFUND नोटिफिकेशन या REFUND_DECLINED नोटिफिकेशन के ज़रिए बताता है।
अगर आपने App Store Server Notifications के लिए कभी सर्वर URL सेट नहीं किया है, तो दूसरा चरण चुपचाप नहीं होता। Apple सिर्फ कस्टमर के अकाउंट के आधार पर फैसला ले लेता है और आपको इसका पता सेल्स रिपोर्ट से चलता है, अगर आप उसे पढ़ रहे हों।
कस्टमर के रिफंड रिक्वेस्ट करने के बाद क्या होता है?
कस्टमर के सबमिट करने के तुरंत बाद, आपके endpoint को notificationType CONSUMPTION_REQUEST वाला एक साइन किया हुआ JSON पेलोड मिलता है। इसके अंदर होता है: साइन की गई ट्रांज़ैक्शन, प्रोडक्ट ID, ओरिजिनल ट्रांज़ैक्शन ID, और एक consumptionRequestReason। Apple ने यह कारण 2024 में जोड़ा और इसे App Store server APIs पर WWDC24 सेशन में समझाया। पांच संभावित वैल्यू: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL और OTHER।
जो चीज़ गायब है वह है व्यक्ति। आपके रिकॉर्ड्स तक वापस जाने वाला एकमात्र सूत्र ट्रांज़ैक्शन ID है, और अगर आपने पर्चेज़ के समय appAccountToken जोड़ा था तो वह भी। अगर नहीं जोड़ा था, तो यही वह पल है जब आपको इसका अफसोस होगा।
तो यह रिव्यू असल में एक लुकअप है: इसे किसने खरीदा, क्या उन्हें यह मिला, और तब से उन्होंने इसके साथ क्या किया?
Apple रिफंड रिक्वेस्ट का जवाब कैसे दें
"Apple रिफंड रिक्वेस्ट नोटिफिकेशन का जवाब कैसे दें" खोजने वाले ज़्यादातर लोगों को API रेफरेंस मिल जाता है। यहां क्रम में स्टेप्स दिए गए हैं।
1. पेलोड वेरिफाई करें
Apple हर नोटिफिकेशन पर साइन करता है। इस पर एक शब्द भी भरोसा करने से पहले सिग्नेचर चेक करें। Apple की App Store Server Library यह काम Java, Python, Node और Swift में करती है।
2. पर्चेज़ ढूंढें
अपने सिस्टम में पर्चेज़ ढूंढने के लिए ट्रांज़ैक्शन ID या appAccountToken का इस्तेमाल करें। आपको यूज़र, डिलीवरी रिकॉर्ड, और तब से जो भी यूसेज आपने लॉग किया है, वह चाहिए।
3. कारण पढ़ें, फिर उसे जांचें
FULFILLMENT_ISSUE का मतलब है कि कस्टमर कह रहा है कि उसे वह नहीं मिला जिसके लिए उसने पैसे दिए। पहले अपने डिलीवरी लॉग चेक करें, क्योंकि अगर वे सही हैं तो आप चाहेंगे कि यह रिफंड हो जाए।
UNINTENDED_PURCHASE आमतौर पर किसी बच्चे या गलती से हुए टैप की वजह से होता है।
UNSATISFIED_WITH_PURCHASE में आपके यूसेज डेटा का असली महत्व होता है, क्योंकि "मुझे यह पसंद नहीं आया" 2 प्रतिशत इस्तेमाल पर अलग दिखता है और 100 प्रतिशत पर अलग।
4. एक प्रेफरेंस चुनें
Apple GRANT_FULL, GRANT_PRORATED या DECLINE लेता है। वह चुनें जिसे आपका डेटा सपोर्ट करता हो। यह सिर्फ एक प्रेफरेंस है, और Apple ने कई ऐसे रिफंड मंज़ूर किए हैं जिन्हें डेवलपर्स ने अस्वीकार करने को कहा था।
5. इसे भेजें
Call the Send Consumption Information endpoint को कॉल करें। मौजूदा रिक्वेस्ट बॉडी में पांच फील्ड होते हैं: customerConsented, deliveryStatus, consumptionPercentage, sampleContentProvided और refundPreference।
Consumption milliunits में होता है, जो अक्सर लोगों को उलझा देता है: 100000 का मतलब है पूरी तरह इस्तेमाल हो चुका, 45200 का मतलब है 45.2 प्रतिशत।
और customerConsented को true होना ज़रूरी है, इसलिए यूसेज डेटा शेयर करने की अनुमति पहली रिक्वेस्ट आने से बहुत पहले आपके terms में होनी चाहिए।
6. नतीजे पर कार्रवाई करें
REFUND का मतलब है कंटेंट या entitlement को रिवोक करना, आदर्श रूप से एक घंटे के अंदर। REFUND_DECLINED का मतलब है कि कुछ नहीं बदलता। दोनों ही स्थितियों में, नतीजे को केस के खिलाफ रिकॉर्ड करें।
मान लीजिए कोई रात 11 बजे 500-कॉइन पैक खरीदता है, रात भर में उनमें से 470 खर्च कर देता है, और अगली सुबह UNSATISFIED_WITH_PURCHASE के तहत रिक्वेस्ट फाइल करता है। डिलीवर्ड, 94 प्रतिशत इस्तेमाल, कोई ट्रायल नहीं, प्रेफरेंस DECLINE। यह एक पूरा Apple रिफंड रिक्वेस्ट रिस्पॉन्स है। यह कोई निबंध नहीं है।
जवाब देने से पहले डेवलपर्स को कौन सी जानकारी जांचनी चाहिए?
पांच चीज़ें, जिनमें से ज़्यादातर पहले से ही आपके डेटाबेस में होनी चाहिए।
पर्चेज़ रिकॉर्ड
तारीख, प्रोडक्ट, कीमत, और क्या इस अकाउंट ने पहले आपसे खरीदा है। अगर आपके रिकॉर्ड्स कम हैं, तो Apple का Get Transaction History endpoint, शुरुआत के लिए इस कस्टमर की किसी एक ट्रांज़ैक्शन ID के आधार पर, आपके ऐप में इस कस्टमर द्वारा खरीदी गई हर चीज़ लौटा देता है।
डिलीवरी
क्या आपके सर्वर ने वाकई कॉइन दिए, फीचर अनलॉक किया, सब्सक्रिप्शन शुरू किया, और कब? अगर वह कॉल फेल हुई थी, तो आपका deliveryStatus UNDELIVERED वैल्यू में से एक होगा और रिफंड जायज़ है। अपने ही लॉग से बहस न करें।
तब से यूसेज
सेशन, खोले गए चैप्टर, खर्च किए गए कॉइन, आपके प्रोडक्ट के लिए "इस्तेमाल करने" का जो भी मतलब हो। Apple को सिर्फ एक प्रतिशत चाहिए, लेकिन उसके पीछे के इवेंट्स के बिना आप ऐसा कोई आंकड़ा नहीं दे सकते जिसका आप बचाव कर सकें।
क्या उन्हें पहले कोई झलक मिली थी
यानी एक फ्री ट्रायल, एक प्रीव्यू चैप्टर या एक फ्री टियर। Apple इसे सीधे पूछता है, और "हां" जवाब "मुझे नहीं पता था कि मैं क्या खरीद रहा हूं" वाली कहानी को कमज़ोर कर देता है।
आपकी तरफ का अकाउंट
यह कितना पुराना है, क्या आपने पहले इसे रिफंड किया है, क्या कोई खुला सपोर्ट टिकट है। Apple उस हिस्ट्री का App Store वाला आधा हिस्सा देखता है। आप अपना वाला हिस्सा देखते हैं।
यह सब इस बात पर निर्भर करता है कि Apple की ट्रांज़ैक्शन ID को आपके सिस्टम में किसी यूज़र से जोड़ा जाए, और appAccountToken इसी काम के लिए है। यह सबसे आम कमी है जो हमें मिलती है, और अगर आपको सेटअप की जानकारी चाहिए तो हमने इस बारे में लिखा है कि appAccountToken रिफंड डिफेंस के लिए क्यों मायने रखता है।
Apple रिफंड रिक्वेस्ट में डेवलपर्स की आम गलतियां
नोटिफिकेशन कभी आता ही नहीं
App Store Connect में कोई सर्वर URL नहीं है, या है भी तो वह किसी स्टेजिंग बॉक्स की ओर इशारा करता है जिसे मार्च में किसी ने बंद कर दिया था। Apple भेजता रहता है। कोई सुनने वाला नहीं है।
देर से जवाब देना
बारह घंटे काफी लगते हैं, जब तक कि रविवार को रात 2 बजे कोई रिक्वेस्ट न आ जाए और इसे हैंडल करने वाला व्यक्ति सो रहा हो, फिर ब्रंच पर हो, फिर किसी Slack मैसेज के बारे में हल्की सी जानकारी रखता हो। ऑफिस आवर्स के इर्द-गिर्द बनी प्रोसेस डिज़ाइन से ही रिक्वेस्ट का एक हिस्सा छोड़ देती है।
कहने के लिए कुछ न होना
नोटिफिकेशन आता है और कोई डिलीवरी लॉग नहीं है, कोई यूसेज इवेंट नहीं है, कोई appAccountToken नहीं है। Apple कस्टमर की बात पर फैसला लेता है। यह गलती महीनों पहले, चेकआउट के समय हो चुकी थी।
Apple से हर चीज़ अस्वीकार करने को कहना
हमने ऐसे सेटअप देखे हैं जो हर रिक्वेस्ट पर DECLINE भेजते हैं, उन रिक्वेस्ट्स पर भी जहां डेवलपर के अपने लॉग दिखाते हैं कि डिलीवरी फेल हुई थी। Apple इस पैटर्न को देख सकता है, और इससे उन रिक्वेस्ट्स पर आपकी विश्वसनीयता को नुकसान पहुंचता है जहां आपके पास वाकई एक मज़बूत केस होता है।
रिफंड मंज़ूर होने के बाद रिवोक करना भूल जाना
यह वह गलती है जिसकी कीमत दो बार चुकानी पड़ती है। पैसे चले जाते हैं और कस्टमर के पास कंटेंट अब भी रहता है, और इनमें से कुछ लोग इस पर ध्यान भी देते हैं।
प्रोडक्शन में टेस्टिंग करना
Apple आपको एक टेस्ट नोटिफिकेशन endpoint और sandbox रिफंड रिक्वेस्ट देता है। पहली असली रिक्वेस्ट किसी असुविधाजनक समय पर आने से पहले दोनों का इस्तेमाल करें।
Apple रिफंड मैनेजमेंट: मैनुअल बनाम ऑटोमेटेड
Apple रिफंड मैनेजमेंट में उस 12-घंटे की विंडो से जुड़ी हर चीज़ शामिल है: रिक्वेस्ट मिलना, डेटा ढूंढना, प्रेफरेंस चुनना, जवाब भेजना, नतीजा लॉग करना, और ज़रूरत पड़ने पर रिवोक करना।
मैनुअल
मैनुअल तरीके से, इसका मतलब है log access और अलर्ट रखने वाला एक व्यक्ति। महीने में मुट्ठी भर रिक्वेस्ट होने पर यह ठीक काम करता है, बशर्ते वह व्यक्ति कभी एक हफ्ते की छुट्टी न ले।
हफ्ते में लगभग बीस रिक्वेस्ट होने पर यह चूकने लगता है। सौ पर यह एक पूरी नौकरी बन जाती है, और ऐसी नौकरी जो कोई नहीं मांगता।
ऑटोमेटेड
ऑटोमेटेड तरीके में, लुकअप और जवाब उन नियमों पर चलते हैं जो आपने एक बार लिख दिए। पूरी तरह इस्तेमाल हो चुके consumable को DECLINE मिलता है, फेल हुई डिलीवरी वाले FULFILLMENT_ISSUE को GRANT_FULL मिलता है, और कुछ भी असामान्य होने पर इंसान के लिए फ्लैग कर दिया जाता है।
जवाब मिनटों में चले जाते हैं, रात 2 बजे भी उतनी ही भरोसेमंदी से जितना दोपहर 2 बजे।
एक पेच है: ऑटोमेशन उतना ही अच्छा होता है जितना उसके नीचे का डेटा। कमज़ोर डिलीवरी और यूसेज रिकॉर्ड्स सिर्फ "unknown" को तेज़ी से भेजते हैं।
डेवलपर्स को Apple रिफंड मैनेजमेंट सॉफ्टवेयर पर कब विचार करना चाहिए?
ईमानदारी से कहें तो, शुरुआत में नहीं। महीने में दो-तीन रिक्वेस्ट को एक चेकलिस्ट और तेज़ अलर्ट से हैंडल किया जा सकता है, और कुछ को हाथ से करना आपको बहुत कुछ सिखाता है।
यह तब समझ में आने लगता है जब रिक्वेस्ट उस दर से आने लगें जितनी तेज़ी से एक व्यक्ति उन्हें विंडो के अंदर निपटा नहीं सकता, या ऐसे समय पर आएं जब कोई जागा न हो। यह तब भी मदद करता है जब आप कई ऐप्स चलाते हैं, या Apple और Google Play को साथ-साथ मैनेज करते हैं, और तीन लिस्ट की बजाय एक लिस्ट चाहते हैं।
Apple रिफंड मैनेजमेंट सॉफ्टवेयर तब अपनी कीमत वसूल करता है जब मैनुअल प्रोसेस रिक्वेस्ट छोड़ना शुरू कर देती है। आपको पता चल जाएगा कि वह कब है: वह हफ्ता होगा जब आप लगातार तीन रिक्वेस्ट मिस कर देते हैं और इसका पता सिर्फ पेआउट से चलता है।
Apple रिफंड डिफेंस सॉफ्टवेयर: डेवलपर्स को क्या देखना चाहिए?
अगर आप Apple रिफंड डिफेंस सॉफ्टवेयर की तुलना कर रहे हैं, तो शुरुआत बुनियादी ढांचे से करें: क्या यह खुद CONSUMPTION_REQUEST प्राप्त करता है और बिना किसी इंसान के रूटीन केस का जवाब देता है? कितनी तेज़ी से, रात और वीकेंड सहित? सही जवाब है मिनट, और टाइमस्टैंप देखने के लिए कहें।
सबूत
क्या यह आपका डिलीवरी और यूसेज डेटा खींच या प्राप्त कर सकता है, या यह सिर्फ नोटिफिकेशन को एक प्रेफरेंस के साथ वापस भेज देता है? दूसरी तरह का सॉफ्टवेयर ज़्यादा काम का नहीं होता।
इसे App Store Server API और Server Notifications V2 पर बना होना चाहिए, न कि ईमेल पार्स करने पर।
विज़िबिलिटी
जब कोई रिक्वेस्ट आए, जब जवाब भेजा जाए, और जब Apple फैसला ले, तब नोटिफिकेशन।
हर रिक्वेस्ट के लिए एक केस, जिसमें रिस्पॉन्स और नतीजा एक ही जगह हो।
हर ऐप और हर प्रोडक्ट के हिसाब से रिफंड रेट, विन रेट और कारणों की रिपोर्टिंग।
किसने या किसने कौन सा जवाब कब भेजा, इसका एक ऑडिट ट्रेल।
ऐसे नियम जो आप खुद कंट्रोल करते हैं, ताकि अपनी लॉजिक बदलने के लिए डिप्लॉय की ज़रूरत न पड़े।
प्राइसिंग
प्राइसिंग भी अलग-अलग होती है: फ्लैट मंथली फीस, प्रति-रिक्वेस्ट फीस और percentage-of-recovery मॉडल, हर एक अलग-अलग वॉल्यूम पर समझ में आता है।
एक चीज़ जो इनमें से कोई नहीं कर सकता: रिफंड रिक्वेस्ट को होने से रोकना, या यह गारंटी देना कि Apple कैसे फैसला लेगा। जो कोई भी इसके उलट दावा करे, वह कुछ बेच रहा है।
Apple रिफंड रिक्वेस्ट का जवाब देने के लिए बेस्ट प्रैक्टिस
इसे अपने on-call रोटा के पास पिन कर लें।
App Store Server Notifications V2 के लिए एक प्रोडक्शन सर्वर URL रजिस्टर करें, और इसके चुप हो जाने पर अलर्ट लगाएं।
हर पर्चेज़ पर appAccountToken सेट करें। हर एक पर।
डिलीवरी को एक टाइमस्टैंप और नतीजे के साथ लॉग करें, साथ ही मुट्ठी भर ऐसे यूसेज इवेंट्स जिनका मतलब है "उन्होंने इसे इस्तेमाल किया।"
यूसेज डेटा शेयर करने की सहमति अभी अपने terms में डालें।
हर रिक्वेस्ट का जवाब 12 घंटे के अंदर दें, उन रिक्वेस्ट्स सहित जहां जवाब "मंज़ूर कर दें" है।
DECLINE की मांग तभी करें जब आपका डेटा इसका समर्थन करे। Apple पैटर्न को नोटिस करता है।
हर REFUND नोटिफिकेशन पर उसी दिन एक्सेस रिवोक करें।
महीने में एक बार जांचें कि आपने वास्तव में कितने प्रतिशत रिक्वेस्ट का जवाब दिया। यह आंकड़ा किसी भी और चीज़ से ज़्यादा आपके रिफंड रेट को प्रभावित करता है।
क्या Apple रिफंड मैनेजमेंट सॉफ्टवेयर इस्तेमाल करने लायक है?
कम वॉल्यूम पर, शायद नहीं। लेकिन जब रिक्वेस्ट उससे ज़्यादा आने लगें जितनी एक व्यक्ति भरोसे से जवाब दे सकता है, या वर्किंग आवर्स के बाहर आने लगें, तो ऑटोमेटिक जवाब देने वाला सॉफ्टवेयर आमतौर पर अपनी कीमत खुद वसूल कर लेता है।
अगर इस सबसे एक ही आदत सीखनी हो, तो वह है जवाब देना - हर रिक्वेस्ट का, असली डेटा के साथ, समय खत्म होने से पहले। Dipsea, एक सब्सक्रिप्शन ऑडियो ऐप, ने जवाब देना शुरू करने के लगभग दो हफ्तों में अपना रिफंड रेट 3 प्रतिशत से घटाकर 1.9 प्रतिशत कर लिया, और कभी Apple से किसी चीज़ को अस्वीकार करने के लिए नहीं कहा। जो ऐप्स चुप रहते हैं, उन्हें कभी पता नहीं चलता कि वे क्या बचा सकते थे।
अक्सर पूछे जाने वाले प्रश्न
यह तब होता है जब कोई कस्टमर, आमतौर पर reportaproblem.apple.com के ज़रिए, किसी ऐप या इन-ऐप पर्चेज़ पर रिफंड के लिए Apple से संपर्क करता है। Apple कस्टमर्स को 24 से 48 घंटे के अंदर जवाब मिलने की उम्मीद करने के लिए कहता है। consumables और subscriptions के लिए, वह पहले डेवलपर से जानकारी मांगता है।
नोटिफिकेशन को वेरिफाई करें, अपने रिकॉर्ड्स में पर्चेज़ ढूंढें, डिलीवरी और यूसेज चेक करें, एक प्रेफरेंस चुनें, और 12 घंटे के अंदर Apple के Send Consumption Information endpoint को कॉल करें। फिर Apple जो भी फैसला ले, उस पर कार्रवाई करें।
नहीं। आप Apple को बता सकते हैं कि आप चाहते हैं कि वह इसे अस्वीकार करे और इसके समर्थन में डेटा भेज सकते हैं। फैसला फिर भी Apple ही लेता है, और वह ऐसे रिफंड भी मंज़ूर कर सकता है और करता है जिन्हें डेवलपर्स ने अस्वीकार करने को कहा था।
पांच चीज़ें: कि कस्टमर ने डेटा शेयरिंग के लिए सहमति दी है, क्या पर्चेज़ डिलीवर किया गया था, उसमें से कितना इस्तेमाल हुआ, क्या उन्हें कोई फ्री सैंपल या ट्रायल मिला था, और आपकी रिफंड प्रेफरेंस। यही मौजूदा समय में पूरा रिक्वेस्ट बॉडी है।
CONSUMPTION_REQUEST मिलने से बारह घंटे। Apple कहता है कि अगर आप चाहते हैं कि फैसले में आपका डेटा शामिल हो, तो इस विंडो के अंदर जवाब दें।
