CONSUMPTION_REQUEST क्या है, यह समझने में बस एक पैराग्राफ़ लगता है। लेकिन ऐसा सिस्टम बनाना जो इसे भरोसेमंद तरीके से हैंडल करे, उसमें काफ़ी ज़्यादा मेहनत लगती है, और जिन हिस्सों में लोग चूकते हैं, वे वैसे नहीं होते जैसी आप उम्मीद करते हैं।
सिग्नेचर वेरिफ़िकेशन उनमें से एक है। सहमति (consent) दूसरा है, क्योंकि यह नोटिफ़िकेशन आने से पहले ही मौजूद होनी चाहिए। और रिट्राई शेड्यूल रिस्पॉन्स विंडो के साथ ऐसे टकराता है कि ज़्यादातर टीमें पहली बार इसे ग़ौर से देखने पर हैरान रह जाती हैं।
यह लेख हैंडलर को शुरू से अंत तक समझाता है — उस पल से जब रिक्वेस्ट आपके एंडपॉइंट पर पहुँचती है, उस एंटाइटलमेंट अपडेट तक जो पूरी प्रक्रिया को समाप्त करता है।
मुख्य बातें
• CONSUMPTION_REQUEST रिफ़ंड समीक्षा के दौरान जानकारी माँगता है। फ़ैसला अब भी Apple ही करता है।
• किसी भी कार्रवाई से पहले साइन किए गए पेलोड को वेरिफ़ाई करें। बिना वेरिफ़ाई किए नोटिफ़िकेशन पर कभी भरोसा न करें।
• सहमति आपके ऐप में पहले से मौजूद होनी चाहिए। रिक्वेस्ट आने के बाद आप इसे नहीं ले सकते।
• Apple नोटिफ़िकेशन के 12 घंटे के भीतर जवाब माँगता है।
• Apple विफल डिलीवरी को एक तय शेड्यूल पर दोबारा भेजता है, और दूसरी रिट्राई रिस्पॉन्स विंडो बंद होने के बाद आती है।
• परिणाम को ट्रैक करें और उसके बाद एंटाइटलमेंट अपडेट करें। जवाब देना आख़िरी कदम नहीं है।
Apple CONSUMPTION_REQUEST नोटिफ़िकेशन क्या है?
Apple CONSUMPTION_REQUEST नोटिफ़िकेशन एक App Store Server Notification है जो आपके सर्वर को बताता है कि किसी ग्राहक ने रिफ़ंड का अनुरोध किया है और Apple आपको उस ख़रीद के बारे में कंज़म्प्शन जानकारी भेजने के लिए आमंत्रित कर रहा है। यह आपके कॉन्फ़िगर किए गए नोटिफ़िकेशन URL पर आता है, संबंधित ट्रांज़ैक्शन साथ लाता है, और जवाब देने के लिए आपको सीमित समय देता है।
यह न तो रिफ़ंड है और न ही कोई फ़ैसला। Apple समीक्षा के बीच में है और संदर्भ जुटा रहा है। आपकी भूमिका है ख़रीद के साथ जो हुआ उसकी सटीक जानकारी देना; फ़ैसला करना Apple की भूमिका है।
Apple CONSUMPTION_REQUEST क्यों भेजता है?
क्योंकि Apple आपके ऐप के अंदर नहीं देख सकता। उसे ट्रांज़ैक्शन, अकाउंट और ख़रीद इतिहास की जानकारी है। उसे यह नहीं पता कि कॉन्टेंट डिलीवर हुआ या नहीं, वह काम कर रहा था या नहीं, या ग्राहक ने उसका कितना इस्तेमाल किया।
कंज़म्प्शन जानकारी इस कमी को पूरा करती है। यह उन कई कारकों में से एक है जिन्हें Apple तौलता है, निर्णायक कारक नहीं, और ज़्यादा कंज़म्प्शन का आँकड़ा रिफ़ंड रोकने का स्विच नहीं है। इसे ऐसा संदर्भ मानें जो आप दे रहे हैं, न कि कोई दलील जो आप लड़ रहे हैं।
CONSUMPTION_REQUEST मिलने पर डेवलपर को क्या करना चाहिए?
नोटिफ़िकेशन को वैलिडेट करें, ट्रांज़ैक्शन और ग्राहक की पहचान करें, सहमति की पुष्टि करें, सटीक कंज़म्प्शन डेटा जुटाएँ, उसे Apple की विंडो के भीतर भेजें, और फिर जो हुआ उसे रिकॉर्ड करें।
व्यवहार में दस कदम:
1. अपने कॉन्फ़िगर किए गए सर्वर एंडपॉइंट पर नोटिफ़िकेशन प्राप्त करें और उसे तुरंत सेव करें।
2. किसी भी फ़ील्ड को सही मानने से पहले साइन किए गए पेलोड को वेरिफ़ाई करें।
3. नोटिफ़िकेशन टाइप पढ़ें और उसे सही जगह रूट करें। कंज़म्प्शन रिक्वेस्ट रिफ़ंड का परिणाम नहीं है।
4. डिकोड किए गए पेलोड से संबंधित ट्रांज़ैक्शन की पहचान करें।
5. अपने सिस्टम में ट्रांज़ैक्शन को ग्राहक अकाउंट से जोड़ें।
6. जाँचें कि उस ग्राहक की सहमति जवाब देने की अनुमति देती है या नहीं।
7. डिलीवरी और उपयोग का डेटा अपने रिकॉर्ड से जुटाएँ, अनुमानों से नहीं।
8. रिस्पॉन्स तैयार करें और उसे फ़ील्ड वैलिडेशन नियमों के अनुसार जाँचें।
9. Apple के कंज़म्प्शन एंडपॉइंट पर सबमिट करें और परिणाम रिकॉर्ड करें।
10. इसके बाद आने वाले रिफ़ंड परिणाम को ट्रैक करें, फिर एंटाइटलमेंट और रिकॉर्ड अपडेट करें।
डेवलपर CONSUMPTION_REQUEST को कैसे वैलिडेट करें?
कॉन्टेंट पर भरोसा करने से पहले सिग्नेचर वेरिफ़ाई करें। नोटिफ़िकेशन साइन किए गए JWS पेलोड के रूप में आते हैं, जिनका विवरण Apple App Store Server Notifications डॉक्यूमेंटेशन में है, और आपके हैंडलर को उन्हें Apple की सर्टिफ़िकेट चेन के विरुद्ध जाँचना चाहिए और पुष्टि करनी चाहिए कि bundle ID आपके ऐप से मेल खाता है।
कारण सीधा है। आपका नोटिफ़िकेशन URL एक सार्वजनिक एंडपॉइंट है। जो इम्प्लीमेंटेशन जो कुछ भी आए उसे पार्स करके उस पर कार्रवाई कर देता है, उसे कोई भी व्यक्ति जो URL ढूँढ ले, चला सकता है।
हैंडलर की तीन बातें सिग्नेचर जितनी ही अहम हैं:
सही स्टेटस कोड के साथ जवाब दें। Apple HTTP 200 से 206 को सफलता मानता है। 40x या 50x App Store को दोबारा कोशिश करने का संकेत देता है। नोटिफ़िकेशन स्टोर करने के बाद सफलता लौटाएँ, प्रोसेसिंग पूरी होने के बाद नहीं — ये दो अलग क्षण हैं, और इन्हें जोड़ने का मतलब है कि कोई धीमा डाउनस्ट्रीम जॉब अनावश्यक रिट्राई ट्रिगर कर सकता है।
डुप्लिकेट हैंडल करें। रिट्राई का मतलब है कि एक ही नोटिफ़िकेशन एक से ज़्यादा बार आ सकता है, और हर एक में एक नोटिफ़िकेशन UUID होता है जिससे आप डुप्लिकेट हटा सकते हैं। दोबारा आए नोटिफ़िकेशन को स्वीकार करें, उस पर एरर न दें; विफलता का जवाब रिट्राई चक्र को फिर से शुरू कर देता है।
याद रखें कि सैंडबॉक्स अलग तरह से व्यवहार करता है। रिट्राई प्रोडक्शन में लागू होते हैं। सैंडबॉक्स में App Store डिलीवरी की केवल एक बार कोशिश करता है, इसलिए जो हैंडलर टेस्टिंग में ठीक दिखता है वह प्रोडक्शन में इवेंट खो सकता है, और इसका उलटा भी सच है।
जवाब देने से पहले डेवलपर को क्या जाँचना चाहिए?
चार चीज़ें, इसी क्रम में।
सबसे पहले सहमति, क्योंकि यही सब कुछ रोक सकती है। Apple ग्राहक का डेटा साझा करने से पहले वैध सहमति की माँग करता है, इसे लेना Apple की नहीं बल्कि आपकी ज़िम्मेदारी है, और नोटिफ़िकेशन में कोई सहमति फ़्लैग नहीं होता। Apple यह भी साफ़ कहता है कि App Tracking Transparency प्रॉम्प्ट यहाँ सहमति का माध्यम नहीं है। अगर सहमति नहीं है, तो मार्गदर्शन यही है कि जवाब न दें।
दूसरा, ट्रांज़ैक्शन की पहचान। आपको पता होना चाहिए कि यह कौन-सी ख़रीद है और इसके पीछे कौन-सा अकाउंट है। यही मैपिंग appAccountToken और Apple रिफ़ंड डिफ़ेंस का विषय है — ट्रांज़ैक्शन से अकाउंट तक स्थिर लिंक के बिना, आप डेडलाइन के दबाव में अनुमान लगा रहे होते हैं।
तीसरा, प्रोडक्ट टाइप, क्योंकि यह तय करता है कि आपके पास कौन-से विकल्प उपलब्ध हैं। और अंत में, क्या आपके पास वास्तव में उपयोगी डेटा है। अगर आपके सिस्टम यह नहीं बता सकते कि कॉन्टेंट डिलीवर हुआ या नहीं, तो रिस्पॉन्स तैयार करना शुरू करने से पहले यह जान लेना ज़रूरी है।
डेवलपर Apple को कौन-सी कंज़म्प्शन जानकारी भेज सकते हैं?
Apple का वर्तमान Send Consumption Information डॉक्यूमेंटेशन पाँच फ़ील्ड परिभाषित करता है। तीन अनिवार्य हैं और दो वैकल्पिक।
फ़ील्ड | अनिवार्य | सरल शब्दों में |
customerConsented | हाँ | क्या ग्राहक इसके लिए सहमत हुआ? true होना ज़रूरी है, वरना रिक्वेस्ट अस्वीकार हो जाती है। |
deliveryStatus | हाँ | क्या आपके ऐप ने वास्तव में एक काम करने वाली ख़रीद डिलीवर की, और अगर नहीं, तो क्यों नहीं? |
sampleContentProvided | हाँ | क्या ग्राहक ख़रीदने से पहले इसे आज़मा सकता था? |
consumptionPercentage | नहीं | उन्होंने कितना इस्तेमाल किया? मिलीयूनिट में — आधा 50000 है, 50 नहीं। |
refundPreference | नहीं | आप क्या पसंद करेंगे: पूरा रिफ़ंड दें, अस्वीकार करें, या आनुपातिक (prorate) करें। |
दो नियम लोगों को उलझाते हैं। अगर डिलीवरी स्टेटस delivered के अलावा कुछ भी है, तो कंज़म्प्शन प्रतिशत शून्य होना चाहिए। और रिफ़ंड प्रेफ़रेंस एक प्राथमिकता है, निर्देश नहीं; Apple इससे अलग फ़ैसला कर सकता है और करता भी है।
यह जाँचना ज़रूरी है कि आप किस एंडपॉइंट पर हैं। Apple Apple का ConsumptionRequestV1 डॉक्यूमेंटेशन भी प्रकाशित करता है, जो बारह-फ़ील्ड वाली बॉडी के साथ पुराना वर्शन है और जिसका वर्णन ज़्यादातर थर्ड-पार्टी लेख अब भी करते हैं। वहाँ Apple का नोट स्टैंडर्ड In-App Purchases को वर्तमान एंडपॉइंट की ओर निर्देशित करता है और V1 को Advanced Commerce API ख़रीदों तक सीमित रखता है। अगर आपका इंटीग्रेशन इस बदलाव से पहले का है, तो सबसे पहले इसी को देखें।
डेवलपर के पास CONSUMPTION_REQUEST का जवाब देने के लिए कितना समय होता है?
Apple का वर्तमान डॉक्यूमेंटेशन नोटिफ़िकेशन के 12 घंटे के भीतर जवाब माँगता है।
यहाँ वह हिस्सा है जिस पर ध्यान देना ज़रूरी है। Apple विफल डिलीवरी को पाँच बार दोबारा भेजता है — पिछली कोशिश के 1, 12, 24, 48 और 72 घंटे बाद। इसे 12 घंटे की विंडो के सामने रखें तो हिसाब असहज हो जाता है: अगर आपका एंडपॉइंट पहली डिलीवरी चूक जाता है, तो पहली रिट्राई एक घंटे बाद आती है और आप सुरक्षित हैं। अगर वह भी चूक जाती है, तो अगली कोशिश लगभग तेरह घंटे बाद आती है — जब विंडो पहले ही बंद हो चुकी होती है।
इसलिए यहाँ एंडपॉइंट की विश्वसनीयता कोई सामान्य रखरखाव का मुद्दा नहीं है। ख़ास तौर पर कंज़म्प्शन रिक्वेस्ट के लिए, लगभग एक घंटे का डाउनटाइम संभाला जा सकता है, आधे दिन का नहीं।
Apple यह नहीं कहता कि विंडो चूकने का मतलब रिफ़ंड अपने आप स्वीकृत हो जाता है, और ऐसा दावा करना गलत होगा। इसका मतलब सिर्फ़ यह है कि Apple उस जानकारी के बिना फ़ैसला करता है जो आप दे सकते थे।
डेवलपर के जवाब देने के बाद क्या होता है?
Apple आपकी जानकारी को अपनी समीक्षा में शामिल करता है, उसे बाकी सब के साथ तौलता है, और फ़ैसला करता है। परिणाम एक अलग नोटिफ़िकेशन के रूप में आता है: स्वीकृत, अस्वीकृत, या रिवर्स्ड — अगर Apple बाद में अपना स्वीकृत रिफ़ंड पलट देता है।
यहाँ तीन अलग-अलग चीज़ें हो रही हैं और इन्हें अलग रखना मददगार है। आपका रिस्पॉन्स जानकारी है। Apple का फ़ैसला एक फ़ैसला है। आपका सिस्टम अपडेट एक स्टेट बदलाव है। इनमें सिर्फ़ बीच वाला Apple का है, और तीसरा तब तक नहीं होता जब तक आप उसे बनाते नहीं।
जवाब के बाद डेवलपर Apple रिफ़ंड कैसे हैंडल करें
परिणाम आने के बाद काम वापस आपके पास आ जाता है।
परिणाम को ट्रांज़ैक्शन और ग्राहक के विरुद्ध रिकॉर्ड करें। सब्सक्रिप्शन स्टेटस अपडेट करें, क्योंकि रिफ़ंड की गई अवधि सामान्यतः सब्सक्रिप्शन को चलते रहने देने के बजाय समाप्त कर देती है। स्वीकृत रिफ़ंड पर एंटाइटलमेंट वापस लें, रिवर्सल पर उसे बहाल करें, और आनुपातिक मामले को हैंडल करें जहाँ ट्रांज़ैक्शन का केवल एक हिस्सा वापस लिया जाता है।
फिर राशि को सही रिपोर्टिंग अवधि में समायोजित करें और रिफ़ंड को खोजे जा सकने वाले इतिहास में रखें। यही इतिहास बाद में बताता है कि कोई एक प्रोडक्ट या प्राइस पॉइंट असंगत रूप से ज़्यादा रिफ़ंड पैदा कर रहा है या नहीं, और यही सपोर्ट टीम को तब चाहिए जब कोई ग्राहक पूछे कि उसकी एक्सेस के साथ क्या हुआ।
CONSUMPTION_REQUEST हैंडल करने में आम गलतियाँ क्या हैं?
जो बार-बार सामने आती हैं:
• नोटिफ़िकेशन को रिफ़ंड मानकर तुरंत एक्सेस वापस ले लेना। अभी कुछ तय नहीं हुआ है।
• सिग्नेचर वेरिफ़िकेशन छोड़ देना क्योंकि टेस्टिंग में पेलोड ठीक दिखता है।
• ठीक उस समय पता चलना कि कोई सहमति फ़्लो ही नहीं है, जब जवाब देना बाकी हो।
• असली आँकड़ों की जगह अनुमानित कंज़म्प्शन आँकड़े भेजना।
• रिक्वेस्ट भेज देना और कभी न जाँचना कि वह सफल हुई या नहीं। बाद में विफल सबमिशन और सफल सबमिशन एक जैसे दिखते हैं।
• कैंसलेशन को रिफ़ंड समझ लेना। ये अलग इवेंट हैं और एक्सेस पर इनका असर अलग होता है।
• स्वीकृत और अस्वीकृत परिणामों को हैंडल करना लेकिन रिवर्सल का मामला भूल जाना, जिससे भुगतान करने वाले ग्राहक बाहर हो जाते हैं।
• 12 घंटे की घड़ी के सामने इस भरोसे पर रहना कि कोई नोटिफ़िकेशन को मैन्युअली देख लेगा।
क्या CONSUMPTION_REQUEST हैंडलिंग को ऑटोमेट किया जा सकता है?
हाँ, और इसका लगभग पूरा हिस्सा ऑटोमेट होना चाहिए, क्योंकि लगभग हर कदम निर्धारित (deterministic) है।
ऑटोमेशन में नोटिफ़िकेशन मॉनिटरिंग और वैलिडेशन, ट्रांज़ैक्शन लुकअप, सहमति जाँच, कंज़म्प्शन-डेटा तैयार करना, सबमिशन, रिस्पॉन्स लॉगिंग, परिणाम ट्रैकिंग, आंतरिक अलर्ट और रिपोर्टिंग शामिल हैं। इनमें से किसी में भी उस पल निर्णय लेने की ज़रूरत नहीं होती।
जो इंसानी काम बचता है वह अपस्ट्रीम है: अपने ऐप में सहमति फ़्लो डिज़ाइन करना, और यह तय करना कि आपकी रिफ़ंड प्रेफ़रेंस नीति क्या होनी चाहिए। और ऑटोमेशन का Apple के फ़ैसले पर कोई असर नहीं होता, चाहे कोई टूल कुछ भी दावा करे।
RefundSensor डेवलपर को Apple रिफ़ंड वर्कफ़्लो हैंडल करने में कैसे मदद करता है
App Store रिफ़ंड मैनेजमेंट इसकी श्रेणी है, और RefundSensor इसका डेवलपर वाला पक्ष संभालता है: Apple रिफ़ंड वर्कफ़्लो की मॉनिटरिंग, कंज़म्प्शन रिक्वेस्ट के लिए समर्थित रिस्पॉन्स पाथ को हैंडल करना, रिफ़ंड इवेंट और परिणामों को ट्रैक करना, और दोहराए जाने वाले कामों को लोगों के कंधों से हटाना।
व्यवहार में, रिस्पॉन्स विंडो के भीतर चले जाते हैं बिना किसी के रात 3 बजे dashboard देखे, और वॉल्यूम बढ़ने पर भी रिफ़ंड रिकॉर्ड सटीक रहते हैं। यह रिफ़ंड को रोकता नहीं है और Apple के फ़ैसले को प्रभावित नहीं कर सकता। यह मैन्युअल मॉनिटरिंग और छूटे हुए कदमों को हटाता है।
ये नियम कहाँ दर्ज हैं
Send Consumption Information — वर्तमान एंडपॉइंट। सहमति की आवश्यकता, 12 घंटे की विंडो, और पाँच रिक्वेस्ट फ़ील्ड। स्टैंडर्ड In-App Purchases के लिए इसी के आधार पर बनाएँ।
Send Consumption Information V1 — बारह-फ़ील्ड बॉडी वाला पुराना एंडपॉइंट। यह पहचानने के लिए उपयोगी कि आपका इंटीग्रेशन कौन-सा वर्शन कॉल करता है, और Advanced Commerce API ख़रीदों के लिए।
App Store Server Notifications — नोटिफ़िकेशन डिलीवरी, साइन किए गए पेलोड का फ़ॉर्मैट, अपेक्षित रिस्पॉन्स कोड, और रिट्राई शेड्यूल।
अगर यह अब भी हाथ से किया जा रहा है
12 घंटे की विंडो, उससे लंबा चल सकने वाला रिट्राई शेड्यूल, और रात भर आते नोटिफ़िकेशन — यह सब मैन्युअल मॉनिटरिंग के लिए बिल्कुल उपयुक्त नहीं है। RefundSensor इन वर्कफ़्लो का डेवलपर वाला पक्ष संभालता है — नोटिफ़िकेशन वैलिडेट करना, विंडो के भीतर रिस्पॉन्स तैयार करके सबमिट करना, और परिणामों को आपके एंटाइटलमेंट रिकॉर्ड तक ट्रैक करना।
अक्सर पूछे जाने वाले प्रश्न
यह एक App Store Server Notification है जो आपके सर्वर को बताता है कि किसी ग्राहक ने रिफ़ंड का अनुरोध किया है और Apple आपको उस ख़रीद के बारे में कंज़म्प्शन जानकारी भेजने के लिए आमंत्रित कर रहा है। यह न रिफ़ंड नोटिफ़िकेशन है और न ही कोई फ़ैसला। Apple अलग से फ़ैसला करता है और आपके जवाब को कई कारकों में से एक इनपुट के रूप में देखता है।
क्योंकि Apple यह नहीं देख सकता कि आपके ऐप के अंदर क्या हुआ। उसे ट्रांज़ैक्शन और अकाउंट इतिहास पता है, लेकिन यह नहीं कि कॉन्टेंट डिलीवर हुआ या नहीं, वह काम कर रहा था या नहीं, या ग्राहक ने उसका कितना इस्तेमाल किया। यह संदर्भ आपके सिस्टम में होता है, इसलिए Apple समीक्षा के दौरान इसे माँगता है।
साइन किए गए नोटिफ़िकेशन को वेरिफ़ाई करें, ट्रांज़ैक्शन और उसके पीछे के ग्राहक की पहचान करें, सहमति की पुष्टि करें, अपने रिकॉर्ड से असली डिलीवरी और उपयोग डेटा जुटाएँ, फिर विंडो के भीतर Apple के कंज़म्प्शन एंडपॉइंट पर सबमिट करें। यह मानने के बजाय कि कॉल सफल रहा, रिस्पॉन्स का परिणाम रिकॉर्ड करें।
वर्तमान एंडपॉइंट पर पाँच फ़ील्ड। तीन अनिवार्य: ग्राहक की सहमति, डिलीवरी स्टेटस, और क्या सैंपल कॉन्टेंट दिया गया था। दो वैकल्पिक: कंज़म्प्शन प्रतिशत और आपकी रिफ़ंड प्रेफ़रेंस। पुराना V1 एंडपॉइंट बारह फ़ील्ड माँगता था, इसीलिए पुराने मार्गदर्शन में लंबी सूची दिखती है।
Apple का वर्तमान डॉक्यूमेंटेशन इस नोटिफ़िकेशन को सभी प्रोडक्ट टाइप के रिफ़ंड अनुरोधों से जोड़कर बताता है, जो पुराने डॉक्स से ज़्यादा व्यापक है। Apple हर मामले के लिए कोई गारंटी प्रकाशित नहीं करता, इसलिए ऐसा हैंडलर बनाएँ जो रिक्वेस्ट आने पर जवाब दे, न कि ऐसा लॉजिक जो मान ले कि रिक्वेस्ट हमेशा आएगी।
Apple नोटिफ़िकेशन के 12 घंटे के भीतर जवाब माँगता है। ध्यान देने योग्य बात यह है कि विफल डिलीवरी के लिए Apple का रिट्राई शेड्यूल 1, 12, 24, 48 और 72 घंटे पर चलता है, इसलिए जो एंडपॉइंट पहली रिट्राई के बाद भी डाउन रहता है, उसे नोटिफ़िकेशन शायद विंडो बंद होने के बाद ही मिले।
Apple इसे अन्य कारकों के साथ तौलता है और फ़ैसला करता है। परिणाम एक अलग नोटिफ़िकेशन के रूप में आता है जो बताता है कि रिफ़ंड स्वीकृत हुआ, अस्वीकृत हुआ, या बाद में रिवर्स किया गया। इसके बाद नई ट्रांज़ैक्शन स्थिति के अनुसार एंटाइटलमेंट, सब्सक्रिप्शन स्टेटस और रेवेन्यू रिकॉर्ड अपडेट करना आपका काम है।
हाँ। वैलिडेशन, ट्रांज़ैक्शन लुकअप, सहमति जाँच, डेटा तैयार करना, सबमिशन, लॉगिंग और परिणाम ट्रैकिंग — ये सब निर्धारित (deterministic) हैं। जो इंसानी काम बचता है वह है सहमति फ़्लो डिज़ाइन करना और अपनी रिफ़ंड प्रेफ़रेंस नीति तय करना। ऑटोमेशन का Apple के रिफ़ंड फ़ैसले पर कोई असर नहीं होता।
