إجابة سريعة: قبل إرسال بيانات الاستهلاك إلى Apple ردًا على إشعار CONSUMPTION_REQUEST، يجب أن تحصل على موافقة صالحة من العميل، ويجب أن تضبط customerConsented على true. لا يُخبرك إشعار Apple ما إذا كانت الموافقة موجودة، وهذا أمر مقصود، فـ Apple تتوقع من تطبيقك، لا من خادمك، أن يجمع هذه الموافقة. ولأنك أنت من يُشارك بيانات جمعتها من المستخدم، فإن المسؤولية القانونية عن تلك الموافقة تقع عليك بالكامل، لا على Apple. وإذا أخطأت في ذلك، فستكون المشكلة متعلقة بقانون الخصوصية، وليست مجرد استدعاء API مرفوض.
الثغرة التي يغفل عنها معظم المطوّرين
تحب دلائل أتمتة الاسترداد الحديث عن نافذة الـ12 ساعة وحقول الاستهلاك. لكن القليل منها فقط يتوقف عند التفصيل الوحيد الأكثر احتمالًا لتوريط المطوّر في مشكلة: إشعار CONSUMPTION_REQUEST لا يحتوي على أي إشارة إلى الموافقة.
يُفاجئ هذا الكثيرين. فمن المنطقي أن تفترض أنه إذا كانت Apple تطلب منك بيانات، فقد تعاملت Apple مسبقًا مع إذن مشاركتها. لكن الأمر ليس كذلك. موقف Apple هو العكس تمامًا البيانات التي ترسلها هي بيانات قمتَ أنت بجمعها من مستخدمك، لذا فإن مسؤولية الحصول على إذن مشاركتها تقع عليك. تطلب Apple منك فقط أن تُصادق على ذلك بضبط customerConsented على true، وترفض الطلب إن لم تفعل. هذا هو جوهر متطلبات موافقة Apple Consumption API.
فهذا الحقل ليس مجرد خانة اختيار تُفعّلها لإرضاء API. إنه مصادقة قانونية. وضبطه على true دون الحصول فعليًا على الموافقة ليس تفصيلًا فنيًا، بل إخلالًا بالامتثال في انتظار أن يُكتشف.
لماذا تقع مسؤولية الموافقة على عاتق المطوّر
فكّر فيمن يملك ماذا. تُدير Apple المتجر وقرار الاسترداد. أما مدة الحساب، ووقت اللعب، وحالة التسليم، وسجل الاستخدام التي تضعها في ConsumptionRequest، فهي سجلاتك الخاصة عن مستخدمك، تم جمعها بموجب سياسة خصوصيتك. وعندما ترسلها إلى Apple، فأنت تكشف عن بيانات شخصية لطرف ثالث.
بموجب أنظمة الخصوصية المعمول بها، يحتاج هذا الكشف إلى أساس قانوني مناسب. تتطلب وثائق API الخاصة بـ Apple تحديدًا موافقة صالحة قبل مشاركة البيانات الشخصية عبر Consumption Information API، بينما تختلف المتطلبات القانونية الدقيقة باختلاف الولاية القضائية للمستخدم. وتقول Apple إن المطوّرين هم المسؤولون عن تحديد الامتثال للقوانين المعمول بها.
لهذا السبب يقع العبء على المطوّر، ولهذا السبب لا تُعد عبارة "Apple طلبت ذلك" دفاعًا كافيًا إذا سألتك جهة تنظيمية كيف حصلت على إذن مشاركة بيانات المستخدم. وبالنسبة لسير عمل موافقة استرداد Apple، فإن المهم هو أن تكون الموافقة موجودة قبل مشاركة البيانات.
أين يجب جمع الموافقة
هذا هو الجزء المهم من الناحية العملية: يجب جمع الموافقة داخل تطبيقك، قبل تدفق الاسترداد لا أن يتم استنتاجها على الخادم عند وصول الإشعار.
بحلول الوقت الذي يصل فيه CONSUMPTION_REQUEST إلى خادمك، يكون الوقت قد فات على طلب الموافقة. فلا يوجد مستخدم حاضر، ولا يتبقى سوى نحو 12 ساعة على الساعة. يجب أن تكون الموافقة موجودة مسبقًا، وأن تُجمَع في وقت سابق كجزء من كيفية تهيئة تطبيقك للمستخدمين وكشفه عن ممارسات البيانات، بحيث يمكنك عند وصول الطلب أن تضبط customerConsented على true بصدق.
من الناحية العملية، يعني ذلك أن شروط تطبيقك، وسياسة الخصوصية، وتدفق الشراء أو التهيئة يجب أن تُفصِح بوضوح عن أن بيانات الاستهلاك قد تُشارَك مع Apple لمعالجة طلبات الاسترداد، وأن تحصل على موافقة بطريقة يمكنك الدفاع عنها. فالموافقة الغامضة أو المجمّعة أو المخفية هي تمامًا ما صُمم قانون الخصوصية الحديث لرفضه. وهذا أيضًا أمر محوري في خصوصية استرداد Apple لأن Apple تتطلب تحديدًا موافقة صالحة قبل مشاركة بيانات الاستهلاك.
كيف يرتبط هذا بـ GDPR وDPDP
إذا كان أي من مستخدميك في الاتحاد الأوروبي/المملكة المتحدة (GDPR)، أو الهند (DPDP)، أو كاليفورنيا (CCPA)، أو في قائمة متزايدة من الولايات القضائية الأخرى، فإن مشاركة بيانات الاستهلاك تقع تمامًا ضمن تلك الأطر. وهناك بعض المبادئ التي تنطبق باستمرار:
يجب أن تكون الموافقة مستنيرة ومحددة. يجب أن يفهم المستخدم أن البيانات المتعلقة بالاسترداد قد تُشارَك مع Apple، لا أن يوافق فقط على جدار من النصوص القانونية.
يجب أن تكون الموافقة قابلة للفصل. دمج موافقة مشاركة البيانات مع شروط غير ذات صلة في خانة اختيار إلزامية واحدة هو نمط معروف بسوء الممارسة.
يجب أن تكون قادرًا على إثباتها. في حال الطعن، يجب أن تكون عبارة "كانت لدينا موافقة" قابلة للإثبات، وهذا يعني أن جمع الموافقة يجب أن يكون مسجَّلًا، لا مفترَضًا.
يجب أن تنص سياسة خصوصيتك على ذلك فعليًا. إذا لم تُفصِح سياستك عن مشاركة بيانات الاستهلاك مع Apple لأغراض الاسترداد، فإن الموافقة المرتبطة بها تقف على أرض هشة.
بالنسبة للفرق التي تراجع متطلبات بيانات الاستهلاك بموجب GDPR، فإن النقطة المهمة هي أن Apple نفسها تتطلب موافقة صالحة لهذه الـ API، بينما يمكن أن تختلف المتطلبات القانونية الدقيقة والأساس القانوني باختلاف الولاية القضائية. وتنص إرشادات Apple على أن الموافقة يجب أن تُمنح بحرية، وأن تكون محددة ومستنيرة وغير ملتبسة، وأن المطوّرين مسؤولون عن تحديد الامتثال بموجب القانون المعمول به.
بالنسبة للتطبيقات التي تستهدف الهند، ينبغي أيضًا مراجعة موافقة استرداد التطبيق بموجب DPDP في ضوء المتطلبات المعمول بها، بدلًا من افتراض أن متطلب API الخاص بـ Apple وحده يحل جميع التزامات الخصوصية.
هذا ليس استشارة قانونية، وتفاصيل التزاماتك تعتمد على مستخدميك والولايات القضائية الخاصة بهم، لكن الاتجاه واضح: الموافقة الكامنة خلف حقل customerConsented يجب أن تكون حقيقية ومستنيرة وموثّقة.
كيف يبدو الإعداد الممتثل
وباختصار، يتكوّن الإعداد القابل للدفاع عنه من ثلاثة أجزاء تعمل مسبقًا قبل أي استرداد:
الإفصاح: تنص سياسة خصوصيتك وشروطك بوضوح على أن بيانات الاستهلاك/الاستخدام قد تُشارَك مع Apple لمعالجة طلبات الاسترداد.
الجمع: يحصل تطبيقك على موافقة المستخدم المستنيرة والقابلة للفصل، ويسجّلها.
المصادقة: عند وصول CONSUMPTION_REQUEST، يعكس ردّك تلك الموافقة المسجّلة بصدق في customerConsented.
صُمم RefundSensor مع وضع هذه السلسلة في الحسبان. تتعامل المنصة مع رد الاسترداد ومصادقة customerConsented كجزء من التدفق المؤتمت، وقد نشرنا مجموعة كاملة من وثائق الامتثال سياسة الخصوصية، والشروط، واتفاقية معالجة البيانات (DPA)، وسياسات ملفات تعريف الارتباط والاسترداد المتوافقة مع GDPR وDPDP وCCPA بحيث يكون جانب الإفصاح والمعالجة مُغطّى بدلًا من أن يكون مُرتَجلًا. ويظل جمع الموافقة داخل تطبيقك قرارك الخاص، كما يجب أن يكون، لكن كل ما يأتي بعده يتم التعامل معه.
بالنسبة للفرق التي تُقيّم برامج الامتثال للاسترداد أو أداة أتمتة استرداد Apple، فإن هذا الفصل مهم: يمكن للأتمتة التعامل مع الرد التقني، لكن لا ينبغي لها أن تختلق أو تفترض موافقة العميل.
الأخطاء الأكثر شيوعًا
ضبط customerConsented على true بشكل افتراضي. أسرع طريقة لتحويل ميزة الاسترداد إلى مسؤولية امتثال.
افتراض أن Apple تتعامل مع الموافقة. هي لا تفعل ذلك، وتقول ذلك صريحًا.
محاولة جمع الموافقة وقت الاسترداد. لا يوجد مستخدم ولا نافذة زمنية لذلك، يجب أن تكون موجودة مسبقًا.
عدم الإفصاح عن أي شيء في سياسة الخصوصية. إذا كانت السياسة صامتة بشأن مشاركة البيانات مع Apple، فإن الموافقة الكامنة خلفها يصعب الدفاع عنها.
دمجها في خانة اختيار إلزامية واحدة. الموافقة القابلة للفصل هي المعيار؛ والدمج يقوّضها.
استخدام App Tracking Transparency كآلية للموافقة. تنص وثائق Apple صراحةً على أن الموافقة المطلوبة لـ Consumption Information API منفصلة عن App Tracking Transparency.
المصادر الرسمية
تتغير المتطلبات واللوائح كلتاهما، لذا تعامل مع هذه المصادر باعتبارها المرجع النهائي:
أتمتة استرداد تحترم سلسلة الموافقة. يتعامل RefundSensor مع رد الاسترداد ومصادقة customerConsented كجزء من تدفق مؤتمت، مدعومًا بمجموعة كاملة من وثائق الامتثال المتوافقة مع GDPR وDPDP وCCPA. وبالنسبة للفرق التي تبحث عن أتمتة استرداد التطبيقات، تظل سلسلة الموافقة جزءًا من التنفيذ. ابدأ مجانًا
الأسئلة الشائعة
نعم. يجب أن تحصل على موافقة صالحة ومستنيرة وأن تضبط customerConsented على true. تتطلب Apple هذه المصادقة وترفض الردود التي تخلو منها، وأنت المسؤول قانونيًا عن الحصول على تلك الموافقة.
في تطبيقك، قبل تدفق الاسترداد. فعند وصول CONSUMPTION_REQUEST إلى خادمك، لا يوجد مستخدم حاضر ولا يتبقى سوى نحو 12 ساعة على الساعة، لذا يجب أن تكون الموافقة موجودة ومسجَّلة مسبقًا.
لا. لا يحمل الإشعار أي إشارة إلى الموافقة. تتوقع Apple من تطبيقك أن يكون قد جمعها، وتتوقع منك أن تصادق عليها في ردّك.
يمكن أن تكون متوافقة، إذا تمت سلسلة الموافقة بالشكل الصحيح: إفصاح واضح في سياستك، وموافقة مستنيرة وقابلة للفصل تُجمَع داخل التطبيق وتُسجَّل، ومصادقة صادقة في رد API. تتعامل الأتمتة مع الرد؛ أما جمع الموافقة داخل التطبيق فهو مسؤوليتك.
لن تُعالج Apple بيانات الاستهلاك، وبالتالي تفقد فرصة التأثير في قرار الاسترداد ذلك. الطريقة الصحيحة هي الحصول على موافقة حقيقية مسبقًا بدلًا من إرسال البيانات دونها.
