त्वरित उत्तर: CONSUMPTION_REQUEST के जवाब में Apple को consumption data भेजने से पहले, आपके पास ग्राहक की वैध सहमति (consent) होनी चाहिए, और आपको customerConsented को true सेट करना होगा। Apple का notification यह नहीं बताता कि सहमति मौजूद है या नहीं, यह जानबूझकर किया गया है, Apple यह अपेक्षा रखता है कि आपका ऐप, न कि आपका सर्वर, इसे collect करे। और क्योंकि आप ही वह व्यक्ति हैं जो उपयोगकर्ता से collect किए गए data को शेयर कर रहे हैं, उस सहमति की कानूनी जिम्मेदारी पूरी तरह से आपकी है, Apple की नहीं। इसे गलत करने पर यह सिर्फ एक rejected API call नहीं, बल्कि एक privacy-law समस्या बन जाती है।
वह अंतर जो ज़्यादातर डेवलपर्स नज़रअंदाज़ कर देते हैं
Refund automation गाइड्स को 12 घंटे की विंडो और consumption fields के बारे में बात करना बहुत पसंद है। लेकिन शायद ही कोई उस एक डिटेल पर रुकता है जो किसी डेवलपर को सबसे ज़्यादा मुसीबत में डाल सकती है: CONSUMPTION_REQUEST notification में सहमति का कोई संकेत नहीं होता।
यह बात लोगों को चौंका देती है। आप स्वाभाविक रूप से यह मान लेते हैं कि अगर Apple आपसे data माँग रहा है, तो उसे शेयर करने की अनुमति का इंतज़ाम Apple ने पहले ही कर लिया होगा। असल में ऐसा नहीं है। Apple का रुख़ इसके उलट है जो data आप भेजेंगे वह data आपने अपने user से collect किया है, इसलिए उसे शेयर करने की अनुमति होने की जिम्मेदारी आप पर है। Apple सिर्फ यह माँग करता है कि आप customerConsented को true सेट करके इसकी पुष्टि (attest) करें, और अगर आप ऐसा नहीं करते तो वह submission को reject कर देता है। यही Apple Consumption API consent requirements का मूल है।
तो यह फ़ील्ड कोई ऐसा checkbox नहीं है जिसे आप सिर्फ API को खुश करने के लिए टिक कर दें। यह एक कानूनी पुष्टि (legal attestation) है। जब आपने वास्तव में सहमति नहीं ली है और फिर भी इसे true सेट कर देते हैं, तो यह कोई तकनीकी औपचारिकता नहीं है यह एक compliance failure है जो पकड़े जाने का इंतज़ार कर रही है।
सहमति की जिम्मेदारी डेवलपर की क्यों है
सोचिए कि किसके पास क्या है। Apple स्टोर चलाता है और refund का फ़ैसला लेता है। लेकिन account tenure, play time, delivery status, और usage history जो आप ConsumptionRequest में डालते हैं, वे आपके records हैं, आपके user के बारे में, जो आपकी privacy policy के तहत इकट्ठा किए गए हैं। जब आप उन्हें Apple को भेजते हैं, तो आप एक तीसरे पक्ष (third party) को personal data disclose कर रहे होते हैं।
लागू होने वाले privacy नियमों के तहत, इस disclosure के लिए एक उपयुक्त कानूनी आधार (legal basis) ज़रूरी है। Apple का विशिष्ट API documentation यह माँग करता है कि Consumption Information API के ज़रिए personal data शेयर करने से पहले वैध सहमति हो, जबकि सटीक कानूनी आवश्यकताएँ user के jurisdiction पर निर्भर करती हैं। Apple कहता है कि लागू कानूनों का पालन सुनिश्चित करने की जिम्मेदारी डेवलपर्स की है।
यही वजह है कि यह ज़िम्मेदारी डेवलपर पर आती है, और यही वजह है कि "Apple ने माँगा था" कोई बचाव नहीं है अगर कोई regulator पूछे कि आपके पास user का data शेयर करने की अनुमति कैसे थी। किसी apple refund consent workflow के लिए सबसे अहम बात यह है कि data शेयर होने से पहले सहमति मौजूद हो।
सहमति कहाँ collect की जानी चाहिए
यह वह हिस्सा है जो practically सबसे ज़्यादा मायने रखता है: सहमति आपके ऐप में, refund flow से पहले collect की जानी चाहिए, न कि notification आने पर सर्वर पर अनुमान (infer) लगाई जानी चाहिए।
जब तक एक CONSUMPTION_REQUEST आपके सर्वर पर पहुँचता है, तब तक पूछने में बहुत देर हो चुकी होती है। वहाँ कोई user मौजूद नहीं होता, और घड़ी में लगभग 12 घंटे बचे होते हैं। सहमति पहले से ही मौजूद होनी चाहिए, जो इस बात के हिस्से के रूप में पहले ही collect की गई हो कि आपका ऐप किस तरह onboard करता है और data practices को disclose करता है, ताकि जब request आए तो आप ईमानदारी से customerConsented को true सेट कर सकें।
व्यावहारिक रूप से इसका मतलब है कि आपके ऐप की terms, privacy policy, और purchase या onboarding flow में साफ़ तौर पर यह बताना होगा कि refund requests को process करने के लिए consumption data Apple के साथ शेयर किया जा सकता है, और इस तरह से सहमति लेनी होगी जिसके पीछे आप खड़े रह सकें। अस्पष्ट (vague), bundled, या छुपी हुई (buried) सहमति वही है जिसे आधुनिक privacy कानून ख़ारिज करने के लिए बनाया गया है। यह apple refund privacy के लिए भी केंद्रीय है, क्योंकि Apple विशेष रूप से यह माँग करता है कि consumption data शेयर करने से पहले वैध सहमति हो।
यह GDPR और DPDP से कैसे जुड़ता है
अगर आपके कोई भी users EU/UK (GDPR), भारत (DPDP), कैलिफ़ोर्निया (CCPA), या बढ़ती हुई सूची में शामिल अन्य jurisdictions में हैं, तो consumption data को शेयर करना पूरी तरह से उन frameworks के दायरे में आता है। कुछ सिद्धांत जो लगातार लागू होते हैं:
सहमति informed और specific होनी चाहिए। user को यह समझना चाहिए कि refund-संबंधी data Apple के साथ शेयर किया जा सकता है, न कि सिर्फ कानूनी शब्दों की एक दीवार पर सहमत होना चाहिए।
सहमति separable होनी चाहिए। data-sharing की सहमति को असंबंधित terms के साथ एक ही mandatory checkbox में bundle करना एक मान्यता प्राप्त anti-pattern है।
आपको इसे साबित करने में सक्षम होना चाहिए। यदि चुनौती दी जाए, तो "हमारे पास सहमति थी" को साबित करने योग्य होना चाहिए, जिसका मतलब है कि आपकी consent capture को record किया जाना चाहिए, न कि सिर्फ मान लिया जाना चाहिए।
आपकी privacy policy में इसका वास्तव में उल्लेख होना चाहिए। अगर आपकी policy refunds के लिए Apple के साथ consumption data शेयर करने का खुलासा नहीं करती, तो उसके लिए आपकी सहमति कमज़ोर आधार पर खड़ी है।
gdpr consumption data requirements की जाँच करने वाली टीमों के लिए महत्वपूर्ण बात यह है कि Apple खुद इस API के लिए वैध सहमति की माँग करता है, जबकि सटीक कानूनी आवश्यकताएँ और lawful basis jurisdiction के अनुसार बदल सकते हैं। Apple की guidance कहती है कि सहमति freely given, specific, informed और unambiguous होनी चाहिए, और लागू कानून के तहत compliance सुनिश्चित करने की जिम्मेदारी डेवलपर्स की है।
भारत-केंद्रित ऐप्स के लिए, dpdp app refund consent की भी लागू आवश्यकताओं के आधार पर समीक्षा की जानी चाहिए, बजाय यह मान लेने के कि केवल Apple की API requirement ही सभी privacy obligations को हल कर देती है।
यह कानूनी सलाह नहीं है, और आपके obligations की बारीकियाँ आपके users और jurisdictions पर निर्भर करती हैं, लेकिन दिशा स्पष्ट है: customerConsented फ़ील्ड के पीछे की सहमति असली, informed, और documented होनी चाहिए।
एक compliant setup कैसा दिखता है
सब कुछ मिलाकर, एक defensible setup में किसी भी refund से पहले काम करने वाले तीन हिस्से होते हैं:
Disclosure: आपकी privacy policy और terms साफ़ तौर पर बताते हैं कि refund requests को संभालने के लिए consumption/usage data Apple के साथ शेयर किया जा सकता है।
Capture: आपका ऐप user की informed, separable सहमति लेता है, और उसे record करता है।
Attestation: जब एक CONSUMPTION_REQUEST आता है, तो आपका response उस recorded सहमति को customerConsented में ईमानदारी से दर्शाता है।
RefundSensor को इसी chain को ध्यान में रखकर बनाया गया है। यह platform automated flow के हिस्से के रूप में refund response और customerConsented attestation को संभालता है, और हमने compliance documents का एक पूरा सूट प्रकाशित किया है, privacy policy, terms, DPA, cookie और refund policies, जो GDPR, DPDP, और CCPA के अनुरूप हैं, ताकि disclosure और processing का पहलू तैयार रहे, न कि तात्कालिक (improvised) तरीके से बनाया गया हो। आपके ऐप में consent capture आपका ही फ़ैसला रहता है, जैसा कि होना चाहिए, लेकिन उसके बाद का सब कुछ संभाला जाता है।
refund compliance software या किसी Apple refund automation tool का मूल्यांकन करने वाली टीमों के लिए, यह अलगाव (separation) महत्वपूर्ण है: automation तकनीकी response को संभाल सकता है, लेकिन उसे customer consent को खुद से बना लेना या मान लेना नहीं चाहिए।
सबसे सामान्य गलतियाँ
customerConsented को डिफ़ॉल्ट रूप से true सेट करना। refund feature को compliance liability में बदलने का सबसे तेज़ तरीका।
यह मान लेना कि Apple सहमति को संभालता है। वह नहीं संभालता, और यह बात साफ़ तौर पर कहता भी है।
refund के समय सहमति collect करने की कोशिश करना। उस वक़्त न कोई user होता है और न ही इसके लिए कोई window, इसे पहले से मौजूद होना ज़रूरी है।
privacy policy में कुछ भी खुलासा न करना। अगर policy Apple के साथ data शेयर करने के बारे में कुछ नहीं कहती, तो उसके पीछे की सहमति का बचाव करना मुश्किल होता है।
इसे एक mandatory checkbox में bundle करना। Separable सहमति ही standard है; bundling इसे कमज़ोर कर देती है।
App Tracking Transparency को consent mechanism के रूप में उपयोग करना। Apple का documentation स्पष्ट रूप से कहता है कि Consumption Information API के लिए ज़रूरी सहमति App Tracking Transparency से अलग है।
आधिकारिक स्रोत
Requirements और regulations दोनों बदलते रहते हैं, इसलिए इन्हें अंतिम प्रमाण (final authority) मानें:
Refund automation जो consent chain का सम्मान करता है। RefundSensor एक automated flow के हिस्से के रूप में refund response और customerConsented attestation को संभालता है, जिसे एक पूर्ण GDPR/DPDP/CCPA-aligned compliance document suite का समर्थन मिलता है। app refund automation की खोज कर रही टीमों के लिए, consent chain implementation का हिस्सा बनी रहती है। मुफ़्त में शुरू करें
अक्सर पूछे जाने वाले प्रश्न
हाँ। आपके पास वैध, informed सहमति होनी चाहिए और customerConsented को true सेट करना होगा। Apple इस attestation की माँग करता है और इसके बिना response को reject कर देता है, और सहमति लेने की कानूनी जिम्मेदारी आपकी होती है।
आपके ऐप में, refund flow से पहले। जब एक CONSUMPTION_REQUEST आपके सर्वर पर पहुँचता है, तब वहाँ कोई user मौजूद नहीं होता और घड़ी में लगभग 12 घंटे बचे होते हैं, इसलिए सहमति पहले से ही मौजूद और record होनी चाहिए।
नहीं। notification में सहमति का कोई संकेत नहीं होता। Apple यह अपेक्षा रखता है कि आपके ऐप ने इसे पहले ही collect कर लिया हो, और आप अपने response में इसकी पुष्टि करें।
यह हो सकता है, बशर्ते consent chain सही तरीके से पूरी की जाए, आपकी policy में स्पष्ट खुलासा हो, ऐप में informed और separable सहमति ली और record की गई हो, और API response में ईमानदार attestation हो। Automation response को संभालता है; ऐप में consent capture की जिम्मेदारी आपकी है।
Apple consumption data को process नहीं करेगा, इसलिए आप उस refund फ़ैसले को प्रभावित करने का मौका खो देते हैं। सही तरीका यह है कि आगे बढ़कर असली सहमति लें, न कि इसके बिना data भेज दें।
