إجابة سريعة: عندما يطلب أحد العملاء من 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. تحتوي الحمولة على بيانات معاملة موقّعة تحدد هوية عملية الشراء. وهذه الإشعارات من app store server notifications هي التي تُطلق سير العمل المؤتمت.
ترد ببيانات الاستهلاك. تستدعي Send Consumption Information باستخدام معرّف المعاملة الأصلي وجسم ConsumptionRequest منظّم يصف التسليم والاستخدام والموافقة وتفضيلك بشأن الاسترداد. تُعد نقطة نهاية send consumption information الخطوة الأساسية في هذه العملية.
تتخذ 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: غير معلنة، تفضيل الموافقة، أو تفضيل الرفض. |
كل حقل هو إشارة. إذا تُرك فارغًا، فهو سياق لن تحصل عليه Apple أبدًا. نستعرض كل حقل وقيمه المقبولة بالتفصيل في ما هو إشعار CONSUMPTION_REQUEST؟ شرح تفصيلي لكل حقل. كما ينبغي على المطورين الذين يقيّمون apple refund api فهم كيفية اندماج هذه الحقول ضمن سير عمل الاسترداد الكامل.
نافذة الـ12 ساعة
أمامك حوالي 12 ساعة للرد على CONSUMPTION_REQUEST في بيئة الإنتاج. وإذا فاتتك هذه المهلة، تفقد فرصة تقديم أي مدخلات؛ وتتخذ Apple قرارها بناءً على ما لديها بالفعل.
المشكلة ليست في طول النافذة الزمنية بل في وقت فتحها. فطلبات الاسترداد لا تنتظر ساعات العمل الرسمية. يمكن أن تُفتح النافذة في منتصف الليل، أو في عطلة نهاية الأسبوع، أو خلال عطلة رسمية، ولا يمكن لطابور مراجعة يدوية تغطية ذلك دون وجود شخص متاح دائمًا. وهذا هو السبب الأكثر شيوعًا وراء خسارة المطورين لعمليات استرداد كان بإمكانهم الطعن فيها: ليس بسبب رد سيئ، بل بسبب غياب الرد تمامًا. نتناول هذا الموضوع بتعمق أكبر في نافذة الـ12 ساعة: لماذا يخسر معظم المطورين عمليات الاسترداد افتراضيًا.
شرط الموافقة لا تتجاهل هذا
هذا هو الجزء الذي يقع فيه الجميع تقريبًا، وهو مسألة قانونية وليست مجرد مسألة تقنية.
لا يخبرك CONSUMPTION_REQUEST الصادر عن Apple بما إذا كان العميل قد وافق على مشاركة بياناته أم لا. وهذا مقصود، إذ تتوقع Apple من تطبيقك، وليس من خادمك، جمع الموافقة وتأكيدها قبل إرسال أي بيانات استهلاك. يجب عليك تعيين customerConsented إلى true في طلب واجهة برمجة التطبيقات، وأنت، بصفتك المطور، المسؤول الوحيد عن الحصول على موافقة صالحة، لأنك من يشارك البيانات التي جمعتها من المستخدم.
إذا أخطأت في هذا الأمر، فأنت لا تخاطر فقط برفض الإرسال بل تخاطر بمشكلة امتثال تتعلق بـ GDPR أو DPDP. تعامل مع الموافقة بشكل صحيح في شروط تطبيقك وتدفق الشراء قبل أتمتة أي شيء. نستعرض بالتحديد أين وكيف يتم ذلك في موافقة العميل وConsumption API: ما الذي تتطلبه Apple فعليًا.
ما الذي تتطلبه أتمتة هذه العملية فعليًا
على الورق، تبدو أتمتة الرد وكأنها مشروع يمكن إنجازه في عطلة نهاية أسبوع: التقاط الإشعار، وتعبئة الحقول، واستدعاء نقطة النهاية. لكن في بيئة الإنتاج، الأمر عبارة عن بنية تحتية قائمة ودائمة، وفهم ما يتطلبه الأمر فعليًا هو الفارق بين قول "سنبنيه" وقول "سنتجاهله".
يجب على أي نظام رد داخلي موثوق أن يستقبل إشعارات Apple الموقّعة ويتحقق منها، وأن يستخرج بيانات استخدام وفوترة دقيقة ومحدّثة لحظيًا لكل عميل فور وصول الطلب، وأن يطابق هذه البيانات مع قيم ConsumptionRequest الدقيقة التي تحددها Apple، وأن يرسلها ضمن نافذة الـ12 ساعة تقريبًا في أي ساعة من ساعات اليوم، دون إشراف بشري. وإلى جانب ذلك، يحتاج إلى إعادة محاولات آمنة زمنيًا، ومعالجة للأعطال، وسجلات يمكن مراجعتها، ومراقبة لمعرفة ما إذا تعطل النظام، وصيانة مستمرة في كل مرة تُعدّل فيها Apple حمولاتها أو حقولها. لا شيء من هذا يمثل منتجك. كل ذلك بنية تحتية ستتحملها إلى أجل غير مسمى من أجل سير عمل لا علاقة له بما يقوم به تطبيقك. (نتناول طبقة الإشعارات بتعمق أكبر في إعداد App Store Server Notifications V2.)
وهذا هو الحساب الذي تنتهي إليه معظم الفرق: الآليات معروفة، لكن بناء ومتابعة نظام رد متوافق وآمن زمنيًا يمثل تكلفة دائمة دون أي فائدة إضافية للتطبيق نفسه. وهذا بالضبط النوع من المهام التقنية الروتينية غير المميزة التي وُجدت من أجلها الخدمات المُدارة.
وهذا بالضبط ما يقوم به RefundSensor. فهو يتصل بإعداد App Store Connect لديك عبر عنوان URL واحد لـwebhook دون الحاجة إلى SDK، أو تغييرات في الكود، أو إعادة إرسال التطبيق ثم يرد تلقائيًا على كل CONSUMPTION_REQUEST ضمن نافذة Apple الزمنية، ويطابق الحقول من بياناتك، ويتولى إعادة المحاولات والمراقبة، ويظل محدّثًا مع تغييرات Apple، ويسجل كل نتيجة في dashboard واحد. تحصل على نتيجة نظام رد مُصمَّم جيدًا دون الحاجة إلى بنائه أو صيانته. وبالنسبة للفرق التي تبحث عن Apple refund automation software، يوفر هذا بديلًا مُدارًا عن الحفاظ على سير العمل داخليًا.
هل يقلل الرد فعليًا من عمليات الاسترداد؟
نعم، رغم أن النتائج تتفاوت وأن Apple هي من تتخذ القرار دائمًا. يمنح إرسال بيانات استهلاك دقيقة نظام Apple سياقًا إضافيًا، وعادةً ما يشهد المطورون الذين يردون باستمرار عدد عمليات استرداد أقل تتم الموافقة عليها مقارنة بالمطورين الذين يتركون الطلبات دون رد. كما يُعد اختيار توصية "prefer decline" (تفضيل الرفض)، عندما تدعمها أدلتك فعليًا، مُدخلًا إضافيًا تأخذه Apple في الاعتبار. وقد يكون هذا الأمر مهمًا بشكل خاص عند إدارة سير عمل استرداد الاشتراكات على نطاق واسع.
ما الذي يمكن للأتمتة فعله وما لا يمكنها فعله
كن صريحًا مع نفسك بشأن الحدود القصوى لما يمكن تحقيقه:
لا يمكنها ضمان رفض أي عملية استرداد معينة. فـ Apple هي من تتخذ القرار النهائي في كل مرة.
لا يمكنها الطعن في عمليات الاسترداد التي لا تُولّد إشعار CONSUMPTION_REQUEST أصلًا — فليست كل عملية استرداد تفعل ذلك.
يمكنها ضمان الرد على كل طلب مؤهل ضمن النافذة الزمنية، ببيانات متسقة ودقيقة، بحيث لا تخسر أي استرداد لمجرد أن أحدًا لم يرَ الإشعار.
هذه النقطة الأخيرة هي بيت القصيد. فأنت لا تتجاوز قرار Apple بل تضمن أن تحصل دائمًا على فرصتك للتعبير عن رأيك.
وللاطلاع على التفاصيل، اعتبر مواد Apple الرسمية هي المرجع النهائي:
أمضت الصناعة 15 عامًا في كسب صوت للمطورين في عمليات الاسترداد. استخدم هذا الصوت في كل مرة. يرد RefundSensor تلقائيًا على إشعارات CONSUMPTION_REQUEST الصادرة عن Apple ضمن النافذة الزمنية، ويتتبع كل نتيجة، لكل من Apple وGoogle Play.ابدأ مجانًا
الأسئلة الشائعة
هو إشعار App Store Server Notification ترسله Apple إلى خادمك عندما يطلب أحد العملاء استرداد أموال عن عملية شراء داخل التطبيق أو اشتراك مؤهل. إنه بمثابة إشارة لك للرد ببيانات الاستهلاك التي ستأخذها Apple في الاعتبار عند اتخاذ قرار الاسترداد.
حوالي 12 ساعة في بيئة الإنتاج. إذا لم ترد في الوقت المحدد، تتخذ Apple القرار دون مدخلاتك، وغالبًا ما تتم الموافقة على الطلبات التي لا يُرد عليها بشكل افتراضي.
لا. يمكنك إرسال refundPreference يوصي بالرفض، لكن Apple هي التي تتخذ القرار النهائي دائمًا. تعمل الأتمتة على تحسين فرصك من خلال ضمان إرسال بيانات دقيقة في كل مرة، لكنها لا تمنحك حق النقض.
نعم. يجب عليك الحصول على موافقة صالحة داخل تطبيقك وتعيين customerConsented إلى true. لا تجمع Apple هذه الموافقة نيابة عنك، وإرسال البيانات دون موافقة يخلق مخاطرة تتعلق بالامتثال للخصوصية أنت المسؤول عنها.
لا. يتم الرد على CONSUMPTION_REQUEST من جانب الخادم عبر App Store Server Notifications وConsumption API. باستخدام RefundSensor، تقوم بلصق عنوان URL واحد لـwebhook في App Store Connect، دون الحاجة إلى SDK، أو تغييرات في الكود، أو إعادة إرسال التطبيق.
تمضي Apple قدمًا دون بياناتك. تفقد الفرصة الوحيدة لتقديم السياق، ويصبح احتمال الموافقة على عمليات الاسترداد، بما فيها غير المبررة، أكبر.
