App Store का हर रिफंड Apple का फैसला होता है, लेकिन Apple यह फैसला बिना जानकारी के नहीं लेना चाहता। रिफंड की मांग आने पर प्रक्रिया रुक जाती है, आपके सर्वर से एक सवाल पूछा जाता है, और खरीद के बारे में तथ्यों के साथ जवाब देने के लिए एक तय समय-सीमा खुल जाती है। ठोस जवाब दें तो अनुचित दावे खारिज हो जाते हैं। चुप रहें तो ग्राहक का खाता ही वह एकमात्र पक्ष बन जाता है जो Apple सुनता है।
मुख्य बातें
App Store पर रिफंड की मांग आने पर Apple आपके सर्वर को एक CONSUMPTION_REQUEST सूचना भेजता है, फिर फैसला लेने से पहले सबूत का इंतजार करते हुए 12 घंटे तक रुकता है।
जवाब देने का मतलब है Send Consumption Information endpoint को एक संक्षिप्त payload के साथ कॉल करना: सहमति, डिलीवरी की स्थिति, कोई सैंपल मौजूद था या नहीं, कितना उपयोग हुआ, और आप किस नतीजे के पक्ष में हैं।
कुछ न भेजना भी अपने आप में एक जवाब है। Apple केवल ग्राहक के दावे और उसके खाते के इतिहास के आधार पर आगे बढ़ता है।
सहमति एक सख्त शर्त के रूप में काम करती है। Apple के दस्तावेज़ में स्पष्ट रूप से कहा गया है कि यदि ग्राहक ने अपना consumption data साझा करने पर सहमति नहीं दी है, तो आपको बिलकुल भी जवाब नहीं देना चाहिए।
ऑटो-रिन्यूएबल सब्सक्रिप्शन के लिए consumption percentage Apple खुद बीते हुए समय से निकालता है, और आपके द्वारा दिया गया कोई भी आंकड़ा एरर उत्पन्न करता है।
इस समय-सीमा के भीतर कोई भी मैनुअल प्रक्रिया फिट नहीं हो सकती। इसका फायदा उन्हीं डेवलपर्स को मिलता है जिनका जवाब स्वचालित रूप से तैयार होकर दर्ज किया जाता है।
App Store पर हर रिफंड एक जैसी शुरुआत से होता है: कोई व्यक्ति reportaproblem.apple.com पर जाता है, एक खरीद चुनता है, और एक वजह बताता है।
वह सूचना जिसका ज़्यादातर जवाब नहीं दिया जाता
जो ऐप्स App Store Server Notifications V2 के लिए कॉन्फ़िगर हैं, उन्हें रिफंड की मांग आने के साथ ही एक CONSUMPTION_REQUEST सूचना मिलती है। उस payload में ट्रांजैक्शन, प्रोडक्ट, और 2024 से, ग्राहक द्वारा चुनी गई वजह मौजूद होती है: UNINTENDED_PURCHASE, FULFILLMENT_ISSUE, UNSATISFIED_WITH_PURCHASE, LEGAL, या OTHER।
वहां से बारह घंटे शुरू होते हैं, जिनके दौरान आप Send Consumption Information endpoint को कॉल करके अपना पक्ष दर्ज कर सकते हैं। यह endpoint जो मांगता है वह जानबूझकर बेहद सीमित है, पांच फ़ील्ड जिनमें सिर्फ फ्लैग और नंबर होते हैं।
customerConsented Apple को बताता है कि क्या ग्राहक ने अपना usage data साझा करने पर सहमति दी थी। एक सामान्य वैल्यू true है।
deliveryStatus Apple को बताता है कि क्या खरीद पहुंची और काम करती रही। एक सामान्य वैल्यू DELIVERED है।
sampleContentProvided Apple को बताता है कि क्या पहले से कोई फ्री सैंपल या ट्रायल उपलब्ध था। एक सामान्य वैल्यू true है।
consumptionPercentage Apple को बताता है कि कितना हिस्सा उपयोग हुआ, जिसे milliunits में दर्शाया जाता है, जहां 100000 का मतलब 100 प्रतिशत होता है। एक सामान्य वैल्यू 67500 है।
refundPreference Apple को बताता है कि आप किस नतीजे के पक्ष में हैं, चाहे वह grant हो, decline हो, या कोई प्राथमिकता न हो। एक सामान्य वैल्यू DECLINE है।
consumptionPercentage का दायरा सीमित है: consumables, one-time purchases, और non-renewing subscriptions। ऑटो-रिन्यूएबल सब्सक्रिप्शन के लिए इसे Apple बिलिंग पीरियड के भीतर बीते समय से खुद निकालता है, और आपके द्वारा दिया गया कोई भी वैल्यू खारिज कर दिया जाता है।
आप जो भेजते हैं, Apple उसका क्या करता है
Consumption information को Apple स्पष्ट रूप से इस बात के इनपुट के रूप में इस्तेमाल करता है कि रिफंड का फैसला कैसे होगा। कुछ न भेजें तो फैसला पूरी तरह ग्राहक के दावे और उसके खाते के इतिहास से होता है। सबूत भेजें तो विवादित रिफंड अक्सर खारिज हो जाते हैं।
जवाब देने का पूरा सिस्टम खुद बनाना, शुरू से आखिर तक
इस पूरी प्रक्रिया में कुछ भी गुप्त नहीं है। फिर भी, यह सब कुछ रात के तीन बजे भी बिना किसी की निगरानी के काम करना चाहिए।
1. सूचनाएं आना सुनिश्चित करें
App Store Connect के भीतर, अपने ऐप का App Information पेज खोलें और App Store Server Notifications के नीचे Version 2 चुनते हुए एक Production Server URL सेट करें। Consumption requests V1 के ज़रिए नहीं पहुंचती। इसके बाद हर सूचना, रिफंड सहित, उस URL पर POST के ज़रिए एक signed JWS payload के रूप में पहुंचती है।
2. सही key जनरेट करें
जवाबों के लिए प्रमाणीकरण में एक In-App Purchase key इस्तेमाल होती है, जो Integrations सेक्शन में Users and Access के अंतर्गत बनाई जाती है। यह एक अलग तरह की key है, और इसके बगल में रखी App Store Connect API key इन कॉल्स को प्रमाणित नहीं करेगी। .p8 फ़ाइल सिर्फ एक बार डाउनलोड होती है, जिसके बाद आप हर रिक्वेस्ट के लिए एक अल्पकालिक ES256 JWT बनाते हैं।
3. सत्यापित करें, मिलान करें, फिर फैसला लें
आने वाली CONSUMPTION_REQUEST सूचनाओं की JWS signature chain को Apple के root certificates के विरुद्ध सत्यापित करना ज़रूरी है, इससे पहले कि आप इसकी सामग्री के किसी भी हिस्से पर भरोसा करें। इसके बाद, ट्रांजैक्शन को किसी यूज़र से जोड़ें, आदर्श रूप से खरीद के दौरान आपके द्वारा जोड़े गए appAccountToken UUID के ज़रिए, और उनका वास्तविक उपयोग पता करें। फिर एक प्राथमिकता तय करें: सद्भावना वाले मामलों में छूट दें, और उन मामलों में विरोध करें जहां प्रोडक्ट स्पष्ट रूप से इस्तेमाल हो चुका था।
4. समय-सीमा खत्म होने से पहले इसे दर्ज करें
उन पांच फ़ील्ड को उस transaction id के साथ, 12 घंटे के भीतर, Send Consumption Information endpoint पर PUT करें। लगभग हर कोई दो गलतियों में फंसता है। percentage को milliunits नियंत्रित करते हैं, इसलिए 100% का मतलब 100000 होता है, न कि एक मिलियन। और सहमति इस पूरी प्रक्रिया की शर्त है, क्योंकि Apple के अपने दस्तावेज़ में कहा गया है कि ग्राहक की सहमति के बिना आपको बिलकुल भी जवाब नहीं देना चाहिए। इसे लागू करने से पहले अपनी terms of service में यह सहमति वाली भाषा ज़रूर शामिल करें।
इतने सारे डेवलपर्स यह मौका क्यों खो देते हैं
किसी भी इंसानी प्रक्रिया के लिए आधा दिन बहुत कठोर समय-सीमा है। सूचनाएं शनिवार की रात तीन बजे भी आ सकती हैं। इन्हें चाहिए एक ऐसा सर्वर जो Apple की JWS signature chain को सत्यापित कर सके, ट्रांजैक्शन को किसी यूज़र से जोड़ सके, milliunits में consumption percentage निकाल सके, और एक JWT-authenticated API को कॉल कर सके। हर एक रिक्वेस्ट के लिए। बिना रुके।
व्यावहारिक रूप से, चेकलिस्ट इस तरह है:
App Store Server Notifications V2 सेट करें, जिसके बिना रिक्वेस्ट आप तक कभी नहीं पहुंचती।
signed payload पर भरोसा करने से पहले उसे Apple की certificate chain के विरुद्ध सत्यापित करें।
ट्रांजैक्शन को अपने सिस्टम में किसी यूज़र से जोड़ें, आमतौर पर खरीद के समय जोड़े गए appAccountToken के ज़रिए।
अनुमान लगाने के बजाय वास्तविक रूप से दर्ज किए गए उपयोग से consumption percentage निकालें।
समय-सीमा खुली रहते हुए एक In-App Purchase key का इस्तेमाल करके Send Consumption Information को कॉल करें।
Refund Sensor इसी भार को उठाने के लिए मौजूद है, जो बिना किसी को जगाए समय-सीमा के भीतर एक पूर्ण, सबूत-आधारित जवाब दर्ज करता है।
ये नियम कहां दर्ज हैं
अक्सर पूछे जाने वाले प्रश्न
रिफंड का फैसला फिर भी हो जाता है, बस अब यह पूरी तरह ग्राहक के दावे और उसके खाते के इतिहास पर आधारित होता है। आप यह दिखाने का इकलौता मौका खो देते हैं कि खरीद पहुंची थी और उसका व्यापक रूप से इस्तेमाल हुआ था। व्यवहार में, जिन रिक्वेस्ट का जवाब नहीं दिया जाता वे काफी ज़्यादा स्वीकृत हो जाती हैं।
हां, ज़रूरी है। customerConsented का true होना चाहिए, और इस फ्लैग के पीछे की सहमति असली होनी चाहिए, जो आमतौर पर आपके उन कानूनी दस्तावेज़ों में दर्ज होती है जो data sharing को कवर करते हैं। Apple का अपना गाइडेंस डेवलपर्स को बताता है कि जहां ऐसी सहमति मौजूद न हो, वहां सूचना का जवाब बिलकुल न दें।
सिर्फ non-renewing तरह के सब्सक्रिप्शन के लिए। ऑटो-रिन्यूएबल सब्सक्रिप्शन के लिए consumption को Apple मौजूदा बिलिंग पीरियड के भीतर बीते समय से खुद निकालता है, और API आपके द्वारा दिया गया कोई भी percentage खारिज कर देता है। बावजूद इसके, आपकी refund preference का महत्व बना रहता है।
एक In-App Purchase key, जो App Store Connect में Users and Access के अंतर्गत, Integrations में जनरेट की जाती है। यह App Store Connect API key से अलग होती है, और इसकी .p8 फ़ाइल बनाए जाने के समय सिर्फ एक बार डाउनलोड की जा सकती है।
Production में सूचना मिलने के बाद 12 घंटे का समय मिलता है। Sandbox में सिर्फ 5 मिनट मिलते हैं, जो यह साफ संकेत देता है कि Apple क्या चाहता है: एक इंसान नहीं बल्कि automation।
