إجابة سريعة: إشعار CONSUMPTION_REQUEST هو الإشعار الذي ترسله Apple إلى خادمك عندما يطلب عميل استرداد أموال عملية شراء مؤهلة داخل التطبيق أو اشتراك. للرد، ترسل مرة أخرى ConsumptionRequest منظَّمًا وهو مجموعة من الحقول التي تصف كيفية استخدام العميل لما اشتراه، وما إذا كان قد وافق على ذلك، وتفضيلك بشأن الاسترداد. تأخذ Apple هذه الحقول في الحسبان عند اتخاذ قرارها. يوضح هذا الدليل معنى كل حقل وسبب أهميته.
ما هو هذا الإشعار
عندما يطلب عميل من Apple استرداد أمواله، يرسل App Store إشعار CONSUMPTION_REQUEST إلى خادمك عبر App Store Server Notifications. وهذا يعني أن Apple تقول: أخبرنا بما تعرفه عن كيفية استخدام هذا العميل لهذه العملية الشرائية، وسنأخذ ذلك في الحسبان عند اتخاذ قرارنا.
وترد عن طريق إعادة إرسال نص ConsumptionRequest. كل قيمة تمثل إشارة. فإذا أرسلت بيانات استرداد أموال دقيقة وكاملة من Apple، يكون لدى Apple سياق كافٍ؛ وإذا تركت الحقول فارغة، فإنها تتخذ قرارها بناءً على معلومات أقل. أنت لا توافق على الاسترداد أو ترفضه بنفسك، فـ Apple هي التي تتخذ القرار النهائي دائمًا، لكن جودة ما ترسله تؤثر في الاحتمالات. لمعرفة سير العملية كاملًا، راجع كيفية أتمتة طلبات استرداد أموال Apple.
الحقول التي تقبلها Apple
هذا ما يدخل في ConsumptionRequest وما يخبر به كل حقل Apple. توفر حقول consumption request هذه البيانات المنظمة المستخدمة في سير عمل consumption api:
الحقل | ما يمثله | سبب أهميته |
customerConsented | ما إذا كان العميل قد وافق على مشاركة هذه البيانات | مطلوب. يجب أن تكون القيمة true، وإلا فلن تعالج Apple الرد. |
consumptionStatus | غير مستهلكة / مستهلكة جزئيًا / مستهلكة بالكامل | عملية الشراء المستهلكة بالكامل تمثل حالة مختلفة تمامًا عن عملية لم تُستخدم إطلاقًا. |
deliveryStatus | ما إذا كانت القيمة أو الخدمة قد تم تسليمها بنجاح | يميّز بين حالة "قمنا بالتسليم واستخدمها العميل" وحالة فشل التسليم الحقيقي. |
refundPreference | توصيتك: غير معلنة / تفضيل الموافقة / تفضيل الرفض | أحد مدخلات Apple — وحين تدعم أدلتك ذلك، يكون هذا بمثابة صوتك في القرار. |
accountTenure | المدة التي يمتلك فيها العميل حسابًا معك | الحساب القديم يُقرأ بشكل مختلف عن الحساب الجديد تمامًا. |
playTime | مقدار الوقت الذي قضاه العميل في تطبيقك | دليل مباشر على التفاعل مع ما يطلب استرداد أمواله بشأنه. |
lifetimeDollarsPurchased | إجمالي ما أنفقه العميل في جميع تطبيقاتك | سياق يوضح ما إذا كان هذا عميلًا لمرة واحدة أو عميلًا راسخًا وذا قيمة. |
lifetimeDollarsRefunded | إجمالي ما تم استرداده سابقًا لهذا العميل | نمط تكرار الاسترداد يمثل إشارة مهمة. |
sampleContentProvided | ما إذا كان بإمكان العميل التجربة قبل الشراء | يوضح ما إذا كانت عملية الشراء مبنية على معرفة كافية. |
userStatus | حالة الحساب الحالية (نشط، معلّق، إلخ) | يحدد وضع العميل وقت تقديم الطلب. |
تربط Apple معظم هذه الحقول بمجموعات قيم محددة (فعلى سبيل المثال، تستخدم consumptionStatus وdeliveryStatus رموزًا معدودة محددة). توجد الرموز الدقيقة في وثائق Apple، المُشار إليها أدناه، وقد تتغير، وهذا جزء من سبب كون الحفاظ على تحديث الرد عملًا مستمرًا وليس بناءً لمرة واحدة.
الحقول الثلاثة الأكثر أهمية
إذا كان عليك التركيز على شيء واحد، فليكن هذا:
customerConsented: هذا الحقل ليس مهمًا فقط، بل هو بوّابة فعلية. ترفض Apple الطلب بالكامل إذا لم تكن قيمته true، وأنت مسؤول قانونيًا عن الحصول على تلك الموافقة داخل تطبيقك قبل إرسال أي بيانات على الإطلاق. فهو حقل يتعلق بالامتثال بقدر ما يتعلق بالجانب التقني. نتناول متطلب الموافقة بالتفصيل في موافقة العميل وواجهة Consumption API.
refundPreference: هذا أقرب ما تملكه إلى "صوت" في القرار. وحين تدعم أدلتك بالفعل الرفض، فإن التعبير عن هذا التفضيل يُعد أحد المدخلات التي تأخذها Apple في الحسبان. وحين لا تدعمه، فإن فرض تفضيل الرفض ليس تجاوزًا سحريًا للقرار — فـ Apple تظل هي من يتخذه.
consumptionStatus: غالبًا ما تكون مسألة استخدام العميل الفعلي لما اشتراه جوهر القضية. وهو أيضًا أحد الحقول التي يسهل الوقوع في خطأ بشأنها إذا لم تكن بيانات الاستخدام لديك دقيقة وحديثة لحظة وصول الطلب.
لماذا تعبئة هذه الحقول بشكل صحيح أصعب مما يبدو
عند قراءة جدول الحقول، قد يبدو هذا مجرد عمل يسير في فترة بعد ظهر واحدة. لكن في الواقع، الرد الجيد يعني:
سحب بيانات استخدام وفوترة دقيقة ومحدّثة لحظيًا لكل عميل فور وصول الطلب، لا لقطة من الأمس.
ربط بياناتك الداخلية بمجموعات القيم الدقيقة لدى Apple، والحفاظ على صحة هذا الربط مع تنقيح Apple لها.
تنفيذ ذلك خلال نافذة الـ 12 ساعة التقريبية، في أي وقت، دون أن يراقبه أحد.
التعامل مع حالة الموافقة، وإعادة المحاولات، والأعطال، والتسجيل، حتى تتمكن من إثبات ما أرسلته ومعرفة ما إذا كان الأمر يعمل.
لا شيء من ذلك معقّد من الناحية المفاهيمية. لكن كل ذلك عبارة عن بنية تحتية ستملكها وتصونها لأجل سير عمل ليس هو منتجك. وهذا هو الحساب الذي تنتهي إليه معظم الفرق: الحقول معروفة ويمكن فهمها، لكن بناء والحفاظ على نظام استجابة موثوق وآمن من حيث المواعيد النهائية ومتوافق مع المتطلبات يمثل تكلفة مستمرة دون أي فائدة حقيقية لتطبيقك.
وهذه هي الثغرة التي يغطيها RefundSensor. فهو يربط كل حقل ببياناتك، ويبقى متوافقًا مع تغييرات Apple، ويستجيب تلقائيًا خلال النافذة الزمنية المحددة، حتى تُدار الدقة التي تحدد نتائج الاسترداد دون أن تضطر إلى بنائها أو متابعتها بنفسك. وبالنسبة إلى الفرق التي تقارن بين حلول أتمتة استرداد أموال Apple، فهذا يزيل عبء البنية التحتية عن سير العمل.
مصادر رسمية
تتغير مجموعات القيم والمتطلبات الخاصة بـ Apple، لذا تعامل مع وثائقها بصفتها المرجع النهائي:
الحقول معروفة ويمكن فهمها. لكن صيانة نظام استجابة لها ليست مهمتك. يربط RefundSensor كل حقل من ConsumptionRequest ببياناتك ويجيب تلقائيًا خلال النافذة الزمنية لدى Apple، بدقة وتحديث وامتثال. ابدأ مجانًا
الأسئلة الشائعة
إنه إشعار App Store Server Notification الذي ترسله Apple عندما يطلب عميل استرداد أمواله عن عملية شراء مؤهلة. وهو يطلب منك إرجاع بيانات استهلاك تأخذها Apple في الحسبان عند اتخاذ قرار الاسترداد.
حقول تصف الموافقة، وحالة الاستهلاك، وحالة التسليم، ومدة الحساب، ووقت اللعب، والإنفاق الكلي والمبالغ المستردة مدى الحياة، ومحتوى العينة، وحالة الحساب، وتفضيلك بشأن الاسترداد. كل حقل منها إشارة تدخل في حساب Apple لقرارها.
customerConsented يمثل بوّابة صارمة، فيُرفض الرد بدونه. أما refundPreference وconsumptionStatus فهما الأكثر تأثيرًا مباشرًا في النتيجة حين تدعم أدلتك قضيتك.
يحمل التفضيل وزنًا أكبر عندما يكون مدعومًا ببيانات استهلاك وتسليم دقيقة. فالردود الناقصة تعطي Apple معلومات أقل للاعتماد عليها، لذا يكون التفضيل بمفرده أضعف من التفضيل المدعوم بأدلة.
لا. تتخذ Apple القرار النهائي دائمًا. فالبيانات الدقيقة تحسّن حظوظك، لكنها لا تمنحك حق النقض.
