يفتح أحدهم «الإبلاغ عن مشكلة»، ويختار تطبيقك، ويطلب من Apple استرداد أمواله. لا تقرر Apple مباشرة. بل تُرسل إشعارًا إلى خادمك أولًا تسأل فيه عما تعرفه عن عملية الشراء، وتنتظر نحو 12 ساعة للحصول على إجابة.
هذا الإشعار هو Apple CONSUMPTION_REQUEST. كثير من الفرق التي تحقق إيرادات حقيقية من عمليات الشراء داخل التطبيق لم تسمع به قط. وكثير غيرها رأته مرة في سجلاتها وتركته هناك. إن كنت واحدًا منهم، فإن
شرحنا لـ Apple CONSUMPTION_REQUEST يغطي ماهيته وسببه. أما هذا المقال فيتناول جزء الرد. ماذا ترسل، وماذا لا ترسل، وماذا حدث لمن جرّبوا.
أبرز النقاط
ترسل Apple إشعار CONSUMPTION_REQUEST عندما يطلب عميل استرداد أمواله. أمامك نحو 12 ساعة. بعدها تقرر Apple من دونك.
الرد يتكون من خمسة حقول. لا خمسين. خمسة.
تفضيلك بشأن الاسترداد هو مجرد تفضيل. تجاوزته Apple من قبل وستفعل ذلك مجددًا.
لا موافقة من العميل، لا رد. هذا كلام Apple لا كلامنا.
انخفض معدل الاسترداد في أحد التطبيقات من 3% إلى 1.9% في نحو أسبوعين لمجرد أنه بدأ بالرد. ولم يطلب من Apple رفض أي شيء قط.
لا أحد يفعل هذا يدويًا لفترة طويلة. المهلة قصيرة جدًا والطلبات تصل في أوقات غير مناسبة.
إذًا ما هو Apple CONSUMPTION_REQUEST تحديدًا؟
هو إشعار خادم، واحد من إشعارات كثيرة ترسلها Apple عبر App Store Server Notifications V2. يُطلق هذا الإشعار عندما يطلب أحدهم استرداد أمواله عن عملية شراء داخل التطبيق. كان يقتصر سابقًا على المنتجات الاستهلاكية. ومنذ WWDC24 صار يشمل الاشتراكات التلقائية التجديد أيضًا، وهناك يوجد معظم المال.
داخل الحمولة: المعاملة الموقّعة، ومعرّف المنتج، والسبب الذي اختاره العميل. وتسرد وثيقة
consumption Request Reason من Apple خمسة أسباب: UNINTENDED_PURCHASE وFULFILLMENT_ISSUE وUNSATISFIED_WITH_PURCHASE وLEGAL وOTHER.
ما لن تجده هو اسم أو Apple ID. مجرد معرّف معاملة. وتحويله إلى «هذه هي المستخدمة رقم 48213 وقد فتحت التطبيق 40 مرة منذ الشراء» هو مهمتك، ولا ينجح إلا إذا أرفقت App AccountToken عند الدفع. كتبنا
مقالًا كاملًا عن appAccountToken لأن كثيرين يتجاهلونه.
تسأل Apple، وتجيب أنت، وتقرر Apple. هذا هو شكل طلبات استرداد Apple بالنسبة للمطورين.
كيف ترد على Apple CONSUMPTION_REQUEST
ترسل طلب PUT بجسم JSON صغير إلى نقطة نهاية Send Consumption Information لدى Apple، مع معرّف المعاملة في المسار. هذا الجسم هو معلومات الاستهلاك التي يقرؤها نظام الاسترداد في Apple.
يأتي Customer Consented أولًا. true أو false. إن كان false، فتوقف. لا ترسل شيئًا. تقول وثائق Apple إنه من دون موافقة لا ينبغي لك الرد إطلاقًا. أمر غريب، لكنه القاعدة.
ثم حالة التسليم. DELIVERED إذا نجح الأمر. وإن لم ينجح، فهناك أنواع من UNDELIVERED لمشكلة الجودة، والعنصر الخاطئ، وانقطاع الخادم، وغير ذلك.
Sample Content Provided هو نعم أو لا بشأن ما إذا كان بإمكان العميل التجربة قبل الشراء. تجربة مجانية، نعم. معاينة محتوى، نعم. جدار دفع بثلاث نقاط، على الأرجح لا.
Consumption Percentage يربك الناس. فهو بوحدات الميلي، أي أن 100000 تعني استهلاكًا كاملًا و50000 تعني النصف. أسقطه في الاشتراكات التلقائية التجديد. Apple تستنتجه من فترة الفوترة.
وأخيرًا refund Preference. DECLINE أو GRANT_FULL أو GRANT_PRORATED. اختياري. وهو أيضًا المكان الوحيد الذي تقول فيه ما تريده.
رد لحزمة عملات أُنفقت بالفعل:
ترد Apple بـ 202 ولا شيء غير ذلك. لا حكم. قال مهندس في Apple على منتديات المطورين عام 2021: 202 تعني أن بياناتك «ستؤخذ في الحسبان». هذا هو الوعد كله.
لا ترسل DECLINE على كل شيء
أعلم أن الإغراء كبير. قاومه.
اقرأ السبب أولًا. FULFILLMENT_ISSUE يعني أن تراجع سجلات التسليم. إذا لم تصل عملية الشراء فعلًا، فأرسل حالة UNDELIVERED المناسبة مع GRANT_FULL وامضِ قدمًا. لن تكسب هذه، والمحاولة تجعل ردود DECLINE اللاحقة تبدو أضعف.
UNINTENDED_PURCHASE يتعلق بالاستخدام. شراء في 9:02، وطلب استرداد في 9:05، وصفر جلسات بينهما؟ على الأرجح ضغطة خاطئة. دعها تمر. استخدام يومي لمدة أسبوع؟ DECLINE، مع رقم الاستهلاك الحقيقي مرفقًا.
UNSATISFIED_WITH_PURCHASE هو حيث يثبت Sample Content Provided قيمته. حصل على تجربة واستخدم 80%؟ ارفض. بالكاد فتحه؟ GRANT_PRORATED حل وسط عادل.
أما LEGAL وOTHER، فأرسل بيانات دقيقة وتجاوز التفضيل ما لم تجعل سجلاتك القرار واضحًا.
DECLINE فوق استهلاك بنسبة 95% وتجربة مجانية رد قوي. أما DECLINE على شيء استُخدم لتسعين ثانية فيبدو رد فعل تلقائيًا.
ما حدث فعلًا لمن فعلوا ذلك
Dipsea تطبيق صوتي اشترته RevenueCat في سبتمبر 2024 واستخدمته لاختبار معالج الاسترداد الخاص بها. في 23 أكتوبر بدأوا بالرد على طلبات الاستهلاك مع ضبط التفضيل على «دع Apple تقرر». لا DECLINE. مجرد بيانات. وفي نحو 15 يومًا انخفض معدل الاسترداد من 3% ثابتة إلى 1.9%.
وقد نشروا الرسم البياني.بالنسبة لي هذه أكثر نقطة بيانات مفيدة في هذا الموضوع. البيانات وحدها حرّكت الرقم.
ثم الجانب الآخر. في مارس 2024 نشر استوديو ألعاب على Apple Developer Forums أنهم كانوا يرسلون معلومات الاستهلاك وما زالت Apple توافق على «كل» عمليات الاسترداد تقريبًا لعملات أنفقها اللاعبون بالفعل. المنتجات الاستهلاكية هي الحالة الصعبة. فبمجرد أن تُنفق العملات لا تستطيع Apple استرجاعها. وإذا لم تُلغِ الرصيد بنفسك بعد إشعار REFUND، فستخسر المال والعملات معًا.
وفي مايو 2025 امتلأ موضوع على r/iOSProgramming بمستخدمي RevenueCat الذين ضبطوا خيار «فضّل الرفض دائمًا» ورأوا فجأة كل عمليات الاسترداد تُقبل. قالت RevenueCat إنه تغيير في السياسة من جانب Apple. وأيًا كان السبب، فقد حسم جدلًا قديمًا. Refund Preference ليس مفتاح تشغيل. DECLINE الشامل نمط، وتستطيع Apple تجاهله.
طرق للحصول على خطأ 400
Apple صارمة بشأن جسم الطلب. هذه الأخطاء التي نراها مرارًا وتكرارًا.
مسألة وحدات الميلي. يقرأ أحدهم «نسبة مئوية» فيرسل 100، وبذلك يكون قد أخبر Apple أن العميل استخدم عُشر واحد بالمئة. النطاق من 0 إلى 100000.
نسبة غير صفرية على عنصر لم يُسلَّم. إذا لم تكن delivery Status هي DELIVERED، فيجب أن تكون Consumption Percentage صفرًا وإلا رُفض الطلب.
أي نسبة على اشتراك تلقائي التجديد. لدى Apple خطأ مخصص لذلك. أسقطها.
المفتاح الخاطئ. هذا الاستدعاء يتطلب مفتاح In-App Purchase، يُنشأ في App Store Connect ضمن Users and Access ثم Integrations. وليس مفتاح App Store Connect API، رغم أنهما يبدوان متطابقين. المفتاح الخاطئ يعطيك 401 وساعة من الشك في JWT الخاص بك.
تجاوز الموافقة. ليس خطأ HTTP بل خطأ امتثال. أدرج الصياغة في شروطك قبل إطلاق هذا.
اختبر في sandbox أولًا. ملاحظة واحدة: وثيقة الاختبار من Apple تمنحك خمس دقائق هناك، لا اثنتي عشرة ساعة. إذا استغرق خادمك ست دقائق، يتجاهل الاختبار بياناتك. ولفرض الرفض، اختر Other في نموذج الاسترداد واكتب DECLINE.
كيف يتعامل المطورون مع طلبات استرداد App Store عندما تكثر
بعدم التعامل معها في الغالب، إن أردنا الصراحة. يصل الطلب في الثالثة فجرًا. أو يوم السبت. أو في عطلة يكون فيها الشخص الوحيد الذي يفهم خط المعالجة غير متصل. تمر اثنتا عشرة ساعة. وتحكم Apple بناءً على كلام العميل.
كيفية التعامل مع طلبات استرداد Apple بصفتك مطورًا تتلخص في قرار واحد. إما أن تبني السلسلة بنفسك (التحقق من JWS، والبحث عن المستخدم، وسحب بيانات الاستخدام، وحساب النسبة، وإنشاء JWT، واستدعاء نقطة النهاية، وتسجيله، وإعادة المحاولة) وتبقيها تعمل إلى الأبد. أو أن تربط برنامجًا لإدارة استردادات Apple يفعل ذلك بالفعل.
Refund Sensor خيار واحد ضمن المجموعة الثانية. تلصق عنوان URL للإشعارات الخاص بنا في App Store Connect، وتربط المفتاح، فتخرج الردود في ثوانٍ. عبر التطبيقات الموجودة عليه حاليًا، جرى الدفاع عن 77% من الطلبات المؤهلة، بنحو $33 محمية لكل حالة. لا شيء ذكي يحدث. رد ببيانات حقيقية يخرج في كل مرة، قبل الموعد النهائي. وإن كنت تفضل المقارنة بين الخيارات، فإن دليلنا عن أدوات إدارة استردادات Apple
يغطي ما ينبغي أن تسأل عنه.
لهذا يتكرر الحديث عن أتمتة استردادات Apple للمطورين. اثنتا عشرة ساعة، لكل طلب، كل أسبوع، ليست مهمة بشرية. أيًا كان ما تختاره، اختر شيئًا. الصمت يعني أن Apple تسمع طرفًا واحدًا فقط.
الأسئلة الشائعة
اثنتا عشرة ساعة في الإنتاج، وخمس دقائق في sandbox. كلاهما مذكور في وثائق Apple.
لا. تصف Apple معلومات الاستهلاك التي ترسلها بأنها «واحد من عوامل متعددة». إنها تحسّن فرصك. لكنها لا تحسم شيئًا.
على كل طلب وافق فيه العميل، نعم. حتى تلك التي ترسل فيها GRANT_FULL لأن خادمك كان متوقفًا. الردود الصادقة في الحالات السهلة هي سبب ثقة Apple في ردود DECLINE الخاصة بك لاحقًا
deliveryStatus وsampleContentProvided بدقة. تجاوز النسبة المئوية. ثم اذهب وأصلح التتبع لديك.
نعم. DECLINE وGRANTFULL يعملان مع كل أنواع المنتجات. وGRANTPRORATED أيضًا، لكن Apple تتولى حساب التناسب بنفسها للخطط التلقائية التجديد.
