إجابة سريعة: عندما يطلب عميل من Apple استردادًا لعملية شراء داخل التطبيق أو اشتراك، يرسل App Store إلى خادمك إشعار CONSUMPTION_REQUEST ويمنحك حوالي 12 ساعة للرد ببيانات الاستهلاك عبر نقطة النهاية Send Consumption Information. تأخذ Apple هذه البيانات بعين الاعتبار عند اتخاذ قرارها. إذا لم ترد في الوقت المحدد، تتخذ Apple القرار دون مساهمتك، وغالبًا ما تُمنح طلبات الاسترداد غير المبررة تلقائيًا. أتمتة هذا الرد تعني أن كل طلب يحصل على رد ضمن النافذة الزمنية، في كل مرة.
النسخة المختصرة
تملك Apple مسارات الدفع. عندما يشتري شخص اشتراكًا أو عملية شراء داخل التطبيق في تطبيقك، تجمع Apple الأموال، وتأخذ نسبتها، وتتولى عمليات الاسترداد. لسنوات، لم يكن للمطورين أي رأي في قرارات الاسترداد على الإطلاق.
تغيّر ذلك. تسمح لك Apple الآن بإرسال معلومات الاستهلاك، وهي دليل منظّم حول كيفية استخدام العميل لما اشتراه، وتأخذها في الحسبان عند اتخاذ قرار الاسترداد. لا يمكنك الموافقة على الاسترداد أو رفضه بنفسك؛ لا تزال Apple هي التي تتخذ القرار النهائي. لكن الصمت لا يعطي Apple أي شيء تعمل عليه، بينما يوفر الرد المُعد جيدًا سياقًا مفيدًا.
المشكلة تكمن في التوقيت والاستمرارية. نافذة الاسترداد قصيرة، ومدة الرد على استرداد Apple محدودة، وتُفتح في ساعات غير متوقعة، والقيام بذلك يدويًا مع أي حجم حقيقي من الطلبات أمر مستحيل. هذه هي المشكلة التي تحلها الأتمتة.
كيف تعمل عملية استرداد Apple فعليًا
هذا هو التسلسل الكامل من البداية إلى النهاية:
يطلب العميل استردادًا. ينتقل إلى reportaproblem.apple.com، ويختار عملية الشراء، ويحدد السبب، ثم يقدم الطلب.
تُشعر Apple خادمك. بالنسبة لعمليات الشراء المؤهلة، يرسل App Store إشعار CONSUMPTION_REQUEST عبر App Store Server Notifications V2. تحتوي الحمولة على بيانات معاملة موقّعة تحدد عملية الشراء.
تردّ ببيانات الاستهلاك. تستدعي Send Consumption Information مع معرّف المعاملة الأصلي (original transaction ID) ونص ConsumptionRequest منظم يصف التسليم والاستخدام والموافقة وتفضيلك بشأن الاسترداد.
تتخذ Apple القرار. يزن نظام اتخاذ قرار الاسترداد بياناتك جنبًا إلى جنب مع سجل العميل وعوامل أخرى، ثم يصدر قرارًا.
تُخطر بالنتيجة. يعني إشعار REFUND أن الاسترداد قد تمت الموافقة عليه؛ ويعني إشعار REFUND_DECLINED (للطلبات التي تُبدأ عبر StoreKit API) أنه لم تتم الموافقة عليه.
ما يحتويه إشعار CONSUMPTION_REQUEST، وما ترسله كردّ
يحمل الإشعار نفسه معلومات المعاملة الموقّعة والسبب الذي ذكره العميل (consumptionRequestReason). ردّك هو حيث يحدث العمل الفعلي. تحدد Apple نموذج ConsumptionRequest منظم يتضمن حقولًا من بينها:
هذا هو الجدول المعاد بناؤه من الصورة:
الحقل | ما يخبر به Apple |
customerConsented | هل وافق العميل على مشاركة هذه البيانات. يجب أن تكون القيمة true وإلا ترفض Apple الإرسال. |
consumptionStatus | ما إذا كان المحتوى المُشترى لم يُستهلك، أو استُهلك جزئيًا، أو استُهلك بالكامل. |
deliveryStatus | ما إذا كانت القيمة أو الخدمة داخل التطبيق قد تم تسليمها فعليًا. |
accountTenure | المدة التي يمتلك فيها العميل حسابًا لديك. |
playTime | مقدار الوقت الذي قضاه العميل في التطبيق. |
lifetimeDollarsPurchased | إجمالي ما أنفقه العميل عبر تطبيقاتك. |
lifetimeDollarsRefunded | إجمالي المبالغ التي تم استردادها للعميل سابقًا. |
sampleContentProvided | ما إذا كان يمكن للعميل تجربة المحتوى قبل الشراء. |
userStatus | الحالة الحالية لحساب العميل (نشط، معلّق، إلخ). |
refundPreference | توصيتك إلى Apple: غير معلن (undeclared)، تفضيل الموافقة (prefer grant)، أو تفضيل الرفض (prefer decline). |
توصيتك إلى Apple: غير معلن (undeclared)، تفضيل الموافقة (prefer grant)، أو تفضيل الرفض (prefer decline).
كل حقل هو إشارة. وإذا تُرك فارغًا، فهو سياق لن تحصل عليه Apple أبدًا. نستعرض كل حقل وقيمه المقبولة بالتفصيل في مقال What Is a CONSUMPTION_REQUEST Notification? A Field-by-Field Breakdown.
نافذة الـ 12 ساعة
لديك حوالي 12 ساعة للرد على CONSUMPTION_REQUEST في بيئة الإنتاج. هذا الموعد النهائي لـ consumption_request بالغ الأهمية، لأن تفويته يعني أنك تتنازل عن فرصة تقديم أي مساهمة؛ وتتخذ Apple قرارها بناءً على ما هو متوفر لديها فقط.
المشكلة ليست في طول نافذة الرد على استرداد Apple، بل في وقت فتحها. طلبات الاسترداد لا تنتظر ساعات العمل. يمكن أن تُفتح نافذة الاسترداد في الليل، أو في عطلة نهاية الأسبوع، أو خلال عطلة رسمية، ولا يمكن لطابور مراجعة يدوي تغطية ذلك دون وجود شخص متاح على مدار الساعة. هذا هو السبب الأكثر شيوعًا على الإطلاق لفقدان المطورين لطلبات استرداد كان يمكنهم الاعتراض عليها: ليس بسبب رد سيئ، بل بسبب عدم وجود رد على الإطلاق. نتعمق في هذا الموضوع في مقال The 12-Hour Window: Why Most Developers Lose Refunds by Default.
شرط الموافقة، لا تتجاهل هذا
هذا هو الجزء الذي يعثر فيه الجميع تقريبًا، وهو مسألة قانونية، لا مجرد مسألة تقنية.
لا يخبرك إشعار CONSUMPTION_REQUEST من Apple بما إذا كان العميل قد وافق على مشاركة بياناته. هذا مقصود بالتصميم، فـ Apple تتوقع من تطبيقك، لا من خادمك، جمع وتأكيد الموافقة قبل إرسال أي بيانات استهلاك. يجب عليك ضبط customerConsented على true في استدعاء API الخاص بك، وأنت، المطور، المسؤول الوحيد عن الحصول على موافقة صحيحة، لأنك من يشارك بيانات جمعتها من المستخدم.
إذا أخطأت في هذا، فلن تكون معرضًا لخطر رفض الإرسال فقط، بل ستتعرض لخطر مشكلة امتثال بموجب GDPR أو DPDP. تعامل مع الموافقة بشكل صحيح في شروط تطبيقك وتدفق الشراء قبل أتمتة أي شيء. نغطي بالتفصيل أين وكيف نفعل ذلك في مقال Customer Consent & the Consumption API: What Apple Actually Requires.
ما يتطلبه فعليًا أتمتة هذه العملية
على الورق، تبدو أتمتة الرد كمشروع يمكن إنجازه في عطلة نهاية أسبوع: استقبال الإشعار، تعبئة الحقول، استدعاء نقطة النهاية. لكن في بيئة الإنتاج، إنها بنية تحتية دائمة، وفهم ما ينطوي عليه الأمر فعليًا هو الفارق بين "سنبنيها" و"سنتجاوزها".
يجب على أي نظام رد داخلي موثوق أن يستقبل ويتحقق من إشعارات Apple الموقّعة، ويستخرج بيانات استخدام وفواتير دقيقة ومحدثة لحظيًا لكل عميل فور وصول الطلب، ويطابق تلك البيانات مع قيم ConsumptionRequest الدقيقة الخاصة بـ Apple، ويقدمها ضمن نافذة الرد على استرداد Apple التي تبلغ حوالي 12 ساعة، في أي ساعة، دون وجود شخص يراقب. علاوة على ذلك، يحتاج إلى محاولات إعادة إرسال آمنة من حيث الموعد النهائي، ومعالجة للأعطال، وسجلات (logging) قابلة للتدقيق، ومراقبة لمعرفة ما إذا كان النظام قد تعطل، وصيانة مستمرة في كل مرة تعدّل Apple فيها حمولاتها أو حقولها. لا شيء من هذا هو منتجك. كل هذا بنية تحتية ستملكها إلى أجل غير محدد لأجل مسار عمل لا علاقة له بما يفعله تطبيقك. (نتعمق في طبقة الإشعارات في مقال Setting Up App Store Server Notifications V2.)
هذا هو الحساب الذي تنتهي معظم الفرق إليه: الآليات معروفة، لكن بناء والحفاظ على نظام رد ممتثل وآمن من حيث المواعيد النهائية هو تكلفة دائمة دون أي فائدة تُذكر للتطبيق نفسه. هذا هو تحديدًا نوع الأعمال التقنية غير المميزة (undifferentiated plumbing) التي وُجدت الخدمات المُدارة من أجلها.
هذا ما يقوم به RefundSensor. فهو يتصل بإعدادات App Store Connect الخاصة بك من خلال عنوان webhook واحد، دون SDK، ودون تغييرات في الكود، ودون إعادة تقديم للتطبيق، ثم يردّ على كل CONSUMPTION_REQUEST تلقائيًا ضمن نافذة استرداد Apple، ويطابق الحقول من بياناتك، ويتعامل مع إعادة المحاولات والمراقبة، ويظل محدّثًا مع تغييرات Apple، ويسجل كل نتيجة في لوحة تحكم واحدة. بالنسبة للفرق التي تبحث عن برنامج أتمتة استرداد Apple، يزيل هذا الحاجة إلى بناء وصيانة بنية تحتية كاملة للرد على الاسترداد بنفسك.
هل الرد يقلل فعليًا من عمليات الاسترداد؟
نعم، وإن كانت النتائج متفاوتة وتظل Apple هي من يقرر دائمًا. إرسال بيانات استهلاك دقيقة يعطي نظام Apple سياقًا أكبر، وعادةً ما يرى المطورون الذين يردّون باستمرار عددًا أقل من عمليات الاسترداد المقبولة مقارنة بالمطورين الذين يتركون الطلبات دون رد. اختيار توصية "تفضيل الرفض" (prefer decline)، عندما يدعمها دليلك بالفعل، هو مدخل إضافي تأخذه Apple بعين الاعتبار.
لذلك، يمكن أن يساعد الرد ضمن مدة الرد على استرداد Apple في ضمان حصول Apple على معلوماتك قبل الموعد النهائي لـ consumption_request. وهذا لا يضمن نتيجة معينة، لكنه يمنع أن يصبح عدم الرد سببًا لعدم أخذ معلوماتك بعين الاعتبار.
ما يمكن للأتمتة فعله وما لا يمكنها فعله
كن صادقًا مع نفسك بشأن الحدود القصوى لما يمكن تحقيقه:
لا يمكنها ضمان رفض أي عملية استرداد بعينها. تتخذ Apple القرار النهائي في كل مرة.
لا يمكنها الاعتراض على عمليات الاسترداد التي لا تولّد إشعار CONSUMPTION_REQUEST أصلًا، فليست كل عملية استرداد تفعل ذلك.
يمكنها التأكد من الرد على كل طلب مؤهل ضمن نافذة الرد على استرداد Apple، ببيانات دقيقة ومتسقة، حتى لا تفقد أبدًا عملية استرداد لمجرد أن أحدًا لم يرَ الإشعار.
يمكنها أتمتة كيفية الرد على طلبات استرداد Apple ضمن 12 ساعة، مما يقلل من خطر تفويت الموعد النهائي لـ consumption_request.
هذه النقطة الأخيرة هي حيث تكمن القيمة الحقيقية. أنت لا تتجاوز Apple، بل تتأكد من أنك تحصل دائمًا على فرصتك للتعبير عن رأيك.
لماذا لا يمكن للتعامل اليدوي أن يغلق الفجوة
الفرق التي تحاول التعامل مع هذا يدويًا تنتهي عادةً إلى واحدة من ثلاث حالات:
نهج "سنتحقق في الصباح" — والذي يفوّت كل طلب يصل في الليل أو في عطلة نهاية الأسبوع، أي حصة كبيرة منها.
نظام التناوب على الاستدعاء (on-call) — حيث يكون شخص ما مسؤولًا رسميًا عن مهمة نافذتها 12 ساعة على مدار الساعة، وهي مهمة مرهقة ولا تزال معرضة للخطأ البشري.
نهج "استسلمنا" — الأغلبية الصامتة، التي توقفت عن الرد لأن مواكبة الأمر كانت مستحيلة.
القاسم المشترك: الموعد النهائي بسرعة الآلة، والرد بسرعة الإنسان. لا يمكنك التغلب على ساعة تعمل بينما أنت نائم. كل نهج يدوي هو في الحقيقة مجرد اختيار أي طلبات ستفوّتها.
هذه مشكلة توقيت، لا مشكلة منتج
إعادة الصياغة المهمة هنا: فقدان هذه المبالغ المستردة لا يقول شيئًا عن تطبيقك.
يمكن أن يكون لديك منتج رائع، ومستخدمون راضون، ومعدل استرداد حقيقي منخفض، وما زلت تفقد إيرادات من خلال هذه النافذة، لأن الخسائر لا تتعلق بما إذا كان الاسترداد مستحقًا. إنها تتعلق بما إذا كان هناك من يرد. وهذا، بشكل غريب، خبر جيد. مشكلة المنتج صعبة الحل. أما مشكلة التوقيت فلها حل واضح: التأكد من وجود شيء ما جاهز للرد دائمًا، فورًا، بغض النظر عن الساعة.
ما الذي يحل المشكلة فعليًا
الشيء الوحيد الذي يغلق نافذة بسرعة الآلة هو رد بسرعة الآلة. تردّ الأتمتة على كل CONSUMPTION_REQUEST في اللحظة التي يصل فيها، ببيانات استهلاك دقيقة وتفضيلك بشأن الاسترداد، ضمن نافذة Apple، في الساعة 3 فجرًا يوم الأحد بنفس الموثوقية التي تكون في الساعة 3 عصرًا يوم الثلاثاء.
هذا ما يقوم به RefundSensor. فهو يراقب كل طلب استرداد، ويرد تلقائيًا ضمن النافذة الزمنية، ويتابع النتيجة، حتى لا تفقد مرة أخرى عملية استرداد لمجرد أن أحدًا لم يرَ الإشعار. يستغرق الإعداد حوالي 30 دقيقة دون تغييرات في الكود، ويغطي أيضًا نافذة مراجعة طلبات رد المبالغ (chargeback) في Google Play، التي تواجه نفس مشكلة "تُفتح في أي وقت، وتُغلق بسرعة". (للحصول على الصورة الكاملة، راجع How to Automate Apple Refund Requests و Google Play Refunds & Chargebacks.)
[بيانات المنتج - عنصر نائب: أدرج هنا إحصائية حقيقية من RefundSensor بعد إطلاق Refund Index، مثل نسبة الطلبات التي تصل خارج ساعات العمل، أو المبالغ التي تم الدفاع عنها. لا تخترع رقمًا.]
أنت لا تتحايل على Apple. أنت فقط تتأكد من أنك تحصل دائمًا على فرصتك للتعبير عن رأيك، وهي الفرصة التي يتنازل عنها معظم المطورين دون أن يدركوا ذلك.
المصادر الرسمية {#official-sources}
قد تتغير توقيتات وعمليات Apple، لذا تعامل مع وثائقها الرسمية بصفتها المرجع النهائي:
تُفتح النافذة وقتما يشاء عملاؤك. كن حاضرًا مع ذلك. يرد RefundSensor على كل طلب استرداد من Apple تلقائيًا، ضمن نافذة الـ 12 ساعة، بما في ذلك الساعة 3 فجرًا وعطلات نهاية الأسبوع والعطلات الرسمية، ويتابع كل نتيجة. يستغرق الإعداد حوالي 30 دقيقة، دون تغييرات في الكود. ابدأ مجانًا →
روابط داخلية تُضاف بعد النشر: Apple refund automation cornerstone · CONSUMPTION_REQUEST field-by-field · Google Play refunds cornerstone.
الأسئلة الشائعة
حوالي 12 ساعة في بيئة الإنتاج، تبدأ من لحظة تقديم العميل للطلب. إذا فوّتّ هذه المهلة، تتخذ Apple القرار دون مساهمتك.
تمضي Apple قدمًا بالمعلومات المتوفرة لديها، وهي طلب العميل فقط دون أي شيء منك. غالبًا ما تُمنح الطلبات التي لم يُرد عليها، بما فيها غير المبررة، تلقائيًا.
لا. تحدد Apple هذه النافذة. الطريقة الموثوقة الوحيدة للالتزام بها دائمًا هي الرد تلقائيًا في اللحظة التي يصل فيها الطلب.
غالبًا ليس بسبب الأساس الموضوعي للطلب، بل بسبب التوقيت. تصل الطلبات خارج ساعات العمل، ولا يمكن لعملية يدوية الرد على كل طلب في الوقت المناسب، لذا تُفقد طلبات الاسترداد القابلة للاعتراض تلقائيًا.
لا. تتخذ Apple القرار النهائي دائمًا. تضمن الأتمتة ردّك في كل مرة، لكنها لا تتجاوز قرار Apple.
