कोई ग्राहक Report a Problem खोलता है, आपका ऐप चुनता है और Apple से अपने पैसे वापस मांगता है। Apple सीधे फैसला नहीं करता। वह पहले आपके सर्वर को पिंग करता है, पूछता है कि आप उस खरीद के बारे में क्या जानते हैं, और जवाब के लिए करीब 12 घंटे इंतज़ार करता है।
यही पिंग Apple CONSUMPTION_REQUEST है। असली IAP रेवेन्यू वाली कई टीमों ने इसके बारे में कभी सुना ही नहीं। और कई ने इसे अपने लॉग में एक बार देखा और वहीं छोड़ दिया। अगर आप भी उनमें से हैं, तो हमारा
Apple CONSUMPTION_REQUEST explainer बताता है कि यह क्या है और क्यों है। यह पोस्ट जवाब देने वाले हिस्से के बारे में है। क्या भेजें, क्या न भेजें, और जिन्होंने कोशिश की उनके साथ क्या हुआ।
मुख्य बातें
जब कोई ग्राहक रिफंड मांगता है तो Apple एक CONSUMPTION_REQUEST भेजता है। आपके पास करीब 12 घंटे होते हैं। उसके बाद वह आपके बिना ही फैसला कर लेता है।
जवाब में पाँच फ़ील्ड होती हैं। पचास नहीं। पाँच।
आपकी refund preference बस एक preference है, इससे ज़्यादा कुछ नहीं। Apple पहले भी इसे नज़रअंदाज़ कर चुका है और आगे भी करेगा।
ग्राहक की सहमति नहीं, तो जवाब नहीं। यह Apple के शब्द हैं, हमारे नहीं।
एक ऐप का रिफंड रेट सिर्फ़ जवाब देना शुरू करने से करीब दो हफ्तों में 3% से घटकर 1.9% हो गया। उसने Apple से कभी कुछ decline करने को कहा ही नहीं।
यह काम कोई भी लंबे समय तक हाथ से नहीं करता। विंडो बहुत छोटी है और रिक्वेस्ट बेवक्त आती हैं।
तो आखिर Apple CONSUMPTION_REQUEST है क्या?
यह एक सर्वर नोटिफिकेशन है, उन कई नोटिफिकेशन में से एक जो Apple App Store Server Notifications V2 के ज़रिए भेजता है। यह तब फायर होता है जब कोई इन-ऐप खरीद पर रिफंड मांगता है। पहले यह सिर्फ़ consumables तक सीमित था। WWDC24 के बाद से इसमें auto-renewable subscriptions भी शामिल हैं, और ज़्यादातर पैसा वहीं है।
पेलोड के अंदर: signed transaction, product ID, और ग्राहक द्वारा चुना गया कारण। Apple का
consumption Request Reason डॉक पाँच कारण बताता है: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL, OTHER.
जो आपको नहीं मिलेगा वह है नाम या Apple ID। बस एक transaction identifier। इसे "यह यूज़र 48213 है और खरीदने के बाद से उसने ऐप 40 बार खोला है" में बदलना आपका काम है, और यह तभी हो पाता है जब आपने checkout के समय appAccountToken जोड़ा हो। हमने
appAccountToken पर एक पूरी पोस्ट लिखी है क्योंकि बहुत सारे लोग इसे छोड़ देते हैं।
Apple पूछता है, आप जवाब देते हैं, Apple फैसला करता है। डेवलपर्स के लिए Apple रिफंड रिक्वेस्ट का यही ढांचा है।
Apple CONSUMPTION_REQUEST का जवाब कैसे दें
आप Apple के Send Consumption Information endpoint पर एक छोटी JSON body PUT करते हैं, path में transaction ID के साथ। यही body वह Apple consumption information है जिसे रिफंड सिस्टम पढ़ता है।
सबसे पहले Customer Consented आता है। True या false। अगर false है, तो रुक जाइए। कुछ भी न भेजें। Apple के डॉक्स कहते हैं कि सहमति के बिना आपको जवाब देना ही नहीं चाहिए। अजीब है, पर नियम यही है।
फिर delivery status। काम हो गया तो DELIVERED। नहीं हुआ तो quality issue, wrong item, server outage और other के लिए UNDELIVERED के अलग-अलग वेरिएंट हैं।
Sample Content Provided एक हाँ या ना है कि ग्राहक खरीदने से पहले आज़मा सकता था या नहीं। Free trial, हाँ। Content preview, हाँ। तीन बुलेट पॉइंट वाला paywall, शायद नहीं।
Consumption Percentage लोगों को उलझा देता है। यह milliunits में है, यानी 100000 का मतलब पूरी तरह consumed और 50000 का मतलब आधा। Auto-renewable subscriptions के लिए इसे छोड़ दें। Apple इसे billing period से खुद निकाल लेता है।
और आखिर में refund Preference। DECLINE, GRANT_FULL या GRANT_PRORATED। Optional। और यही एकमात्र जगह है जहाँ आप बता सकते हैं कि आप क्या चाहते हैं।
पहले से खर्च हो चुके coin pack के लिए एक जवाब:
Apple 202 के साथ जवाब देता है, और कुछ नहीं। कोई फैसला नहीं। डेवलपर फ़ोरम पर एक Apple इंजीनियर ने 2021 में ही कहा था: 202 का मतलब है कि आपका डेटा "ध्यान में रखा जाएगा।" बस, इतना ही वादा है।
हर चीज़ पर DECLINE न भेजें
पता है, लालच होता है। खुद को रोकिए।
पहले कारण पढ़ें। FULFILLMENT_ISSUE का मतलब है अपने delivery logs जांचें। अगर खरीद सच में डिलीवर नहीं हुई, तो मेल खाता UNDELIVERED status GRANT_FULL के साथ भेजें और आगे बढ़ें। वह केस आप जीतेंगे नहीं, और कोशिश करने से आपके बाद के DECLINE कमज़ोर दिखने लगते हैं।
UNINTENDED_PURCHASE usage के बारे में है। 9:02 पर खरीदा, 9:05 पर रिफंड मांगा, बीच में शून्य सेशन? शायद गलती से बटन दब गया। जाने दें। एक हफ्ते तक रोज़ इस्तेमाल किया? DECLINE, अपने असली consumption नंबर के साथ।
UNSATISFIED_WITH_PURCHASE वह जगह है जहाँ Sample Content Provided अपना काम दिखाता है। Trial मिला और 80% इस्तेमाल किया? Decline। मुश्किल से खोला भी? GRANT_PRORATED एक उचित बीच का रास्ता है।
LEGAL और OTHER के लिए सटीक डेटा भेजें और preference छोड़ दें, जब तक कि आपके रिकॉर्ड से फैसला साफ़ न हो।
95% consumption और free trial के ऊपर DECLINE एक मज़बूत जवाब है। नब्बे सेकंड इस्तेमाल हुई चीज़ पर DECLINE बिना सोचे-समझे भेजा हुआ लगता है।
जिन लोगों ने यह किया, उनके साथ असल में क्या हुआ
Dipsea एक ऑडियो ऐप है जिसे RevenueCat ने सितंबर 2024 में खरीदा और अपने refund handler को टेस्ट करने के लिए इस्तेमाल किया। 23 अक्टूबर को उन्होंने consumption requests का जवाब देना शुरू किया, preference "let Apple decide" पर सेट करके। कोई DECLINE नहीं। सिर्फ़ डेटा। करीब 15 दिनों में रिफंड रेट स्थिर 3% से गिरकर 1.9% पर आ गया।
उन्होंने चार्ट प्रकाशित किया।मेरे लिए इस विषय पर यह सबसे उपयोगी डेटा पॉइंट है। सिर्फ़ डेटा ने ही आंकड़ा बदल दिया।
अब दूसरा पहलू। मार्च 2024 में एक गेम स्टूडियो ने Apple Developer Forums पर लिखा कि वे consumption info भेज रहे थे और फिर भी Apple उन coins पर "लगभग सभी" रिफंड मंज़ूर कर रहा था जो खिलाड़ी पहले ही खर्च कर चुके थे। Consumables सबसे मुश्किल केस हैं। Coins एक बार खर्च हो गए तो Apple उन्हें वापस नहीं ले सकता। अगर आप REFUND नोटिफिकेशन के बाद खुद बैलेंस revoke नहीं करते, तो पैसा भी गया और coins भी।
और मई 2025 में r/iOSProgramming पर एक थ्रेड RevenueCat यूज़र्स से भर गया जिन्होंने "always prefer declining" सेट किया था और अचानक हर रिफंड मंज़ूर होते देखा। RevenueCat ने कहा कि यह Apple की तरफ़ से policy change था। कारण जो भी हो, इसने एक पुरानी बहस खत्म कर दी। Refund Preference कोई स्विच नहीं है। हर बार DECLINE भेजना एक पैटर्न है, और Apple उसे नज़रअंदाज़ कर सकता है।
400 वापस पाने के तरीके
Apple body को लेकर सख्त है। ये वे गलतियाँ हैं जो हम बार-बार देखते हैं।
Milliunits वाली बात। कोई "percentage" पढ़ता है, 100 भेजता है, और Apple को बता देता है कि ग्राहक ने एक प्रतिशत का दसवां हिस्सा इस्तेमाल किया। रेंज 0 से 100000 है।
Undelivered आइटम पर non-zero percentage। अगर delivery Status DELIVERED नहीं है, तो Consumption Percentage 0 होना चाहिए, वरना रिक्वेस्ट रिजेक्ट हो जाती है।
Auto-renewable subscription पर कोई भी percentage। Apple के पास इसके लिए एक अलग error है। इसे छोड़ दें।
गलत key। इस कॉल के लिए In-App Purchase key चाहिए, जो App Store Connect में Users and Access, फिर Integrations के तहत बनती है। App Store Connect API key नहीं, भले ही दोनों एक जैसी दिखती हों। गलत key से 401 मिलता है और एक घंटा अपने JWT पर शक करते हुए बीतता है।
सहमति छोड़ देना। यह HTTP error नहीं, compliance error है। लाइव करने से पहले अपनी terms में इसकी भाषा जोड़ लें।
पहले sandbox में टेस्ट करें। एक पेच: Apple का testing डॉक वहाँ आपको बारह घंटे नहीं, पाँच मिनट देता है। अगर आपका सर्वर छह मिनट लेता है, तो टेस्ट आपके डेटा को नज़रअंदाज़ कर देता है। Decline को force करने के लिए refund sheet पर Other चुनें और DECLINE टाइप करें।
जब रिक्वेस्ट बहुत ज़्यादा हों तो डेवलपर App Store रिफंड रिक्वेस्ट कैसे संभालते हैं
साफ़ कहें तो, ज़्यादातर संभालते ही नहीं। रिक्वेस्ट रात 3 बजे आती है। या शनिवार को। या किसी छुट्टी के दिन जब pipeline समझने वाला इकलौता व्यक्ति ऑफ़लाइन है। बारह घंटे बीत जाते हैं। Apple ग्राहक की बात पर फैसला सुना देता है।
डेवलपर के तौर पर Apple रिफंड रिक्वेस्ट कैसे संभालें, यह एक फैसले पर टिका है। पूरी चेन खुद बनाएं (JWS verify करें, यूज़र खोजें, usage निकालें, percentage निकालें, JWT बनाएं, endpoint कॉल करें, लॉग करें, retry करें) और उसे हमेशा चालू रखें। या ऐसा Apple refund management software जोड़ें जो यह सब पहले से करता है।
Refund Sensor उस दूसरे समूह का एक विकल्प है। आप हमारा notification URL App Store Connect में पेस्ट करते हैं, key कनेक्ट करते हैं, और जवाब सेकंडों में चले जाते हैं। इस समय इस पर चल रहे ऐप्स में, 77% eligible रिक्वेस्ट का बचाव किया गया है, हर केस पर करीब $33 सुरक्षित। इसमें कुछ चतुराई नहीं है। असली डेटा वाला जवाब हर बार, समय सीमा से पहले चला जाता है। अगर आप विकल्प देखना चाहते हैं, तो हमारी Apple refund management tools
गाइड बताती है कि क्या पूछना है।
इसीलिए डेवलपर्स के लिए Apple refund automation की बात बार-बार उठती है। बारह घंटे, हर रिक्वेस्ट, हर हफ्ते, यह किसी इंसान का काम नहीं है। आप जो भी चुनें, कुछ तो चुनें। चुप्पी का मतलब है Apple सिर्फ़ एक पक्ष सुनता है।
अक्सर पूछे जाने वाले प्रश्न
Production में बारह घंटे, sandbox में पाँच मिनट। दोनों Apple के डॉक्स में हैं।
नहीं। Apple आपकी consumption information को "कई कारकों में से एक" कहता है। इससे आपकी संभावना बेहतर होती है। यह कुछ तय नहीं करता।
जहाँ ग्राहक ने सहमति दी है, हर एक का, हाँ। उनका भी जहाँ आप GRANT_FULL भेजते हैं क्योंकि आपका सर्वर डाउन था। आसान केस में ईमानदार जवाब ही वजह हैं कि Apple बाद में आपके DECLINE पर भरोसा करता है
deliveryStatus और sampleContentProvided, सटीक रूप से। Percentage छोड़ दें। फिर जाकर अपनी tracking ठीक करें।
हाँ। DECLINE और GRANTFULL हर product type पर काम करते हैं। GRANTPRORATED भी, बस auto-renewable plans के लिए proration का हिसाब Apple खुद करता है।
