معظم قوائم "أفضل أدوات استرداد الأموال" يكتبها أشخاص لم يقوموا فعليًا بربط أي أداة منها بالنظام. وهذه هي النسخة التي كنت أتمنى أن أجدها، بناءً على ما يرسله كل منصة بالفعل إلى Google وما يفوّته بصمت.
توضيح سريع، لأن هذه النقطة تُشكّل التباسًا لدى الكثيرين. حدث استرداد اشتراك google play وعملية chargeback يتبعان مجموعتين مختلفتين من القواعد، ومعظم المنصات تتعامل مع إحداهما بشكل جيد والأخرى بشكل جزئي فقط. لا يمكنك سوى الطعن في chargeback. أما كل ما عداه، فلا يمكنك سوى اكتشافه.
إذا كنت تفضّل تجاوز هذه المقارنة، فصفحة الدفاع عن chargeback في Google Play هي صفحة منتجنا الخاص وتمثّل النسخة المختصرة من هذا المقال.
الخلاصات الرئيسية
لا تتيح لك Google الطعن إلا في chargebacks، من خلال Review Refund API، في غضون نحو 24 ساعة. وتعمل كل المنصات المذكورة هنا ضمن هذا القيد.
تقبل Google ثلاثة تفضيلات فقط: APPROVE و DECLINE و NEUTRAL. ولا توجد استردادات جزئية عبر الـ API، في أي منصة.
العامل الفاصل الحقيقي هو الأدلة. بعض الأدوات ترسل بيانات الاستخدام الفعلي. وبعضها يرسل تفضيلًا وقيمة منطقية واحدة (boolean) فقط.
لا تُطلعك Google أبدًا على النتيجة. فتقوم المنصات باستقصائها (polling)، مما يجعل تقارير معدل الفوز متأخرة في كل مكان.
الاكتشاف هو الثغرة الأكبر. فعمليات الاسترداد دون إلغاء الوصول، والاستردادات الجزئية، والمشتريات غير المُقرّة تبقى غير مرئية بالنسبة لمعظم الأنظمة.
ما الذي يجب مقارنته فعليًا
أربعة أمور فقط. وكل ما عداها مجرد ضجيج في صفحات التسعير.
هل ترسل الأداة أدلة على الاستهلاك، أم تفضيلًا فقط؟ هذا هو جوهر الغرض من Review Refund API. فقد طلبت Google حالة التسليم ومدى استهلاك العنصر لتتمكن من الدفاع عن قضيتك أمام البنك. والأداة التي تقدّم فقط APPROVE أو DECLINE تستخدم تقريبًا ثلث القناة المتاحة فقط.
هل تحتاج إلى SDK؟ إذا كان الجواب نعم، فأنت تربط الدفاع عن الاستردادات ببنية اشتراكاتك التحتية. وهذا قرار حقيقي، ولا يكون سيئًا دائمًا.
ما الذي تكتشفه الأداة؟ الطعن هو نصف عملية إدارة استردادات Google Play. ومعرفة أن عملية استرداد قد حدثت، وقطع الوصول عن المستخدم، هو النصف الآخر.
هل تغطي الأداة Apple أيضًا؟ تعمل معظم الفرق على كلا المتجرين. والاعتماد على مزوّدين مختلفين لمهمة واحدة هو السبب الذي يجعل الأمور تُهمَل.
RevenueCat Refund Control
هذا هو الخيار الأقوى إذا كانت اشتراكاتك تعمل بالفعل من خلال RevenueCat، وهو الحال بالنسبة لكثير من التطبيقات.
تستخدم Refund Control سياسات على مستوى المشروع يتم تقييمها من الأعلى إلى الأسفل. وتفوز أول سياسة مطابقة. ويمكنك الاختيار بين Prefer full refund أو Prefer no refund أو Send consumption data only أو Do not respond. وتتولى الأداة استدعاء نقطة orders.reviewrefund الخاصة بـ Google نيابةً عنك.
وهذا هو الجزء الذي يستحق قراءته مرتين. وفقًا لوثائق RevenueCat نفسها، يحتوي الطلب الذي يرسلونه إلى Google على ثلاثة حقول: pendingRefundToken، و sampleContentProvided مضبوطًا على true، و refundPreference الخاص بك. وهم يوضحون بصراحة أنهم لا يرسلون حتى الآن نسب الاستهلاك أو أحداث الاستخدام. أي أنك تحصل على قناة التفضيل فقط، وليس قناة الأدلة.
وهم أيضًا صريحون بشأن حدود الاكتشاف. فعملية استرداد تتم من Play Console دون تفعيل خانة الإلغاء (revoke) لن يتم اكتشافها. والاستردادات الجزئية لا تُرصد، واستردادات المشتريات غير المُقرّة لا تُسجَّل. وأي عملية تمنحها Google بدلًا منك قد تستغرق حتى 24 ساعة لتظهر.
وتتميز RevenueCat حقًا في أمر لا تقدمه أي أداة أخرى هنا: يمكنك أنت نفسك إصدار استرداد لاشتراك Google Play، من لوحة التحكم (dashboard) أو من خلال نقطة REST، وتقوم الأداة بإلغاء الوصول في نفس الاستدعاء. وإذا كان فريق الدعم يتعامل مباشرة مع الاستردادات، فهذا أمر مهم.
Adapty Refund Saver
تغطي Refund Saver الآن Google Play، وليس Apple فقط، وهي مُفعّلة افتراضيًا إذا كنت تستخدمها بالفعل على iOS.
فهي ترسل أدلة على الاستخدام في مراجعات chargeback، مما يجعلها متقدمة على RevenueCat في الجانب الذي يؤثر فعليًا على النتيجة. وقد وصل دعم Google Play بعد أن جعل تغيير 3 أغسطس عمليات chargeback مكلفة.
وهناك حدّان صريحان، كلاهما وارد في وثائق Adapty نفسها. فـ Google لا تقبل إلا decline أو approve أو no preference، لذا فإن خيار Grant prorated المتاح على جانب Apple لا نظير له في Google، وترسل Adapty عندئذٍ No preference بدلًا منه. كما أن Google لا تُخطر أحدًا عند حل المراجعة، فتقوم Adapty باستقصاء (polling) حالة الطلب حتى تُحسم. وتظهر نتائج Play لاحقًا مقارنة بنتائج Apple.
والعائق الحقيقي هو SDK. فـ Refund Saver ميزة ضمن المنصة، وليست منتجًا مستقلًا. وإذا لم تكن تستخدم Adapty لإدارة الاشتراكات، فستحتاج إلى تغيير منصتك بالكامل للحصول عليها. وبالنسبة لبعض الفرق، هذه مقايضة مقبولة. لكن بالنسبة لمعظمها، ليست كذلك.
Refund Sensor
هذا منتجنا، فاحكم على كلامنا وفقًا لذلك.
بلا SDK. سجّل الدخول باستخدام Google، ومنح صلاحيتين في Play Console (عرض البيانات المالية، وإدارة الطلبات والاشتراكات)، وتقوم الأداة بإنشاء موضوع Pub/Sub واشتراك push في مشروع Google Cloud الخاص بك. لا حاجة للصق أي شيء في Play Console، ولا إصدار تطبيق جديد.
وتقدّم الأداة توصية decline مرفقة بأدلة التسليم والتفاعل من خلال orders.reviewrefund في غضون 24 ساعة، وتتابع بشكل منفصل عمليات الاسترداد التي لا يمكنك الطعن فيها، وهي الجزء الذي لا تملك فيه معظم الفرق أي رؤية. ويجمع كلا المتجرين في لوحة تحكم واحدة.
ثغرات بصراحة: فهي أحدث من RevenueCat أو Adapty، ولا توجد فيها paywalls أو اختبارات A/B أو تحليلات اشتراكات، لأن هذا ليس الهدف من المنتج. هل تحتاج إلى بنية تحتية للاشتراكات؟ عندها ستحتاج إلى أداة أخرى من هذه الأدوات أيضًا.
RefundHalt
تستحق النظر فيها إذا كنت تريد قواعد مخصّصة لكل حالة على حدة بدلًا من تفضيل شامل واحد. بلا SDK، وتغطي كلا المتجرين، وتسحب أدلة الاستخدام من نقطة نهاية (endpoint) على خادمك الخاص، بحيث تكون الأدلة ملكك فعليًا وليست مُستنتَجة.
تنبيه واحد: بعض المقارنات المنشورة من قبلهم تعود إلى ما قبل دعم Refund Saver لـ Google Play، لذا تحقق من الوثائق الحالية بدلًا من صفحات المقارنة.
بناء الحل بنفسك كبديل
خيار منطقي، وأرخص مما يبدو إذا كنت تدير بالفعل خادم backend.
تحتاج إلى تفعيل RTDN من قسم Monetize، ثم Monetization setup. وموضوع Pub/Sub. ومُستهلِك (consumer) يقوم بفكّ ترميز حقل البيانات base64 ويتفرّع بحسب أي من كائنات الإشعار الخمسة التي وردت. وعند وصول pendingRefundReviewNotification، تُخزّن pendingRefundToken وتبدأ عدًا تنازليًا لمدة 24 ساعة. ثم استدعاء واحد لـ orders.reviewrefund.
والجزء الذي لن يستغرق عطلة أسبوع واحدة فقط: الحصول على بيانات استهلاك حقيقية لاشتراك تم شراؤه منذ سبعة أسابيع، بالإضافة إلى التعامل مع idempotency لأن Google تُعيد المحاولات، بالإضافة إلى عملية مسح ليلية عبر Voided Purchases لرصد ما فاتته الإشعارات. مقارنة Voided Purchases API مع إشعارات المطورين في الوقت الفعلي يوضّح أي تغذية (feed) تقوم بأي وظيفة.
وهذا أيضًا هو الجواب الصريح عن كيفية أتمتة المطورين لاستردادات Google Play عندما لا يريدون الاعتماد على مزوّد خارجي. إنه مجرد مُستهلِك webhook، ومؤقّت، ومسألة بيانات.
فأيّها تختار؟
تستخدم RevenueCat بالفعل وتحتاج بشكل أساسي إلى الاكتشاف إضافة إلى تفضيل؟ اختر Refund Control. فعّلها اليوم.
تستخدم Adapty بالفعل وتريد إرسال الأدلة دون عمل إضافي؟ اختر Refund Saver. من المحتمل أنها مُفعّلة بالفعل.
لا تستخدم أيًا منهما، ولا تريد تغيير منصتك للدفاع عن الاستردادات؟ اختر Refund Sensor أو RefundHalt.
نزاعاتك تميل غالبًا إلى الاحتيال وتريد منطقًا مخصصًا لكل حالة؟ اختر RefundHalt، أو قم ببنائها بنفسك.
لا شيء من هذا، وعمليات الاسترداد لديك غير مؤثرة؟ لا تفعل شيئًا الآن، ولكن فعّل RTDN على أي حال. فهي مجانية، وستحتاج إلى السجل التاريخي عندما تزداد الأحجام.
النقطة التي تتجاهلها كل صفحات المنصات
سؤال كيفية أتمتة استردادات اشتراكات Google Play هو السؤال الأول الخاطئ لمعظم التطبيقات. فاستردادات Google Play بالنسبة للمطورين تنقسم إلى ما يمكنك التأثير فيه وما لا يمكنك إلا الاستجابة له، والقائمة الثانية أطول.
يمكنك الطعن في مراجعة chargeback. هذا كل ما في الأمر. أما استردادات الدعم، واستردادات Play خلال 48 ساعة، وتحويلات التجربة المجانية غير المُقرّة، فكلها تُحسم دون تدخّلك. والأتمتة الوحيدة المتاحة هنا هي اكتشافها بسرعة وقطع الوصول.
وهذا يعني أن أتمتة استردادات Google Play هي في الواقع منتجان في قالب واحد: محرّك استجابة لعمليات chargeback، ومحرّك اكتشاف لكل ما عداها. ومعظم المزوّدين يتميزون في أحدهما فقط. تحقق مما تشتريه بالضبط. ويستحق إعلان Google بشأن حماية الاستردادات وتكلفة chargeback أن تقرأه قبل أن تختار، لأنه يوضّح لماذا أصبح جانب الاستجابة مهمًا بشكل مفاجئ.
المصادر
الأسئلة الشائعة
فقط فئة chargeback الفرعية. تفتح Google مراجعة عندما يتقدّم العميل بنزاع لدى بنكه، وتحصل على نحو 24 ساعة للرد من خلال Review Refund API. أما كل أنواع الاسترداد الأخرى فتُحسم دون تدخّلك، ولا يمكنك سوى اكتشافها.
يعتمد على ما تستخدمه حاليًا. RevenueCat إذا كانت اشتراكاتك موجودة فيه بالفعل. Adapty إذا كنت تستخدم SDK الخاص بها وتريد إرسال أدلة الاستخدام تلقائيًا. Refund Sensor أو RefundHalt إذا كنت تريد الدفاع عن الاستردادات دون تغيير منصتك.
لا. تقبل Google فقط APPROVE أو DECLINE أو NEUTRAL من خلال الـ API. والاستردادات النسبية (prorated) موجودة على جانب Apple لكن لا نظير لها في Google، لذا فإن المنصات التي تقدّمها ترسل No preference على Play بدلًا من ذلك.
إما أن تبني الحل بنفسك باستخدام RTDN و orders.reviewrefund، أو تستخدم خدمة تتصل عبر صلاحيات Play Console ومشروع Google Cloud. وكلا الخيارين يتجنبان التعامل مع ملف التطبيق الثنائي (app binary).
ببطء. فـ Google لا تُخطر أحدًا عند حل المراجعة، لذا تقوم المنصات باستقصاء حالة الطلب. توقّع تأخرًا في بيانات النتائج، واحكم على الأداة من خلال ما إذا كانت قدّمت الطعن ضمن المهلة المحددة، وليس من خلال معدل الفوز في اليوم نفسه.
منذ 3 أغسطس 2026، تكلّفك خسارة chargeback سعر الشراء مطروحًا منه رسوم خدمة Google إضافة إلى رسوم البنك. وفي منتج رخيص الثمن، يمكن أن تتجاوز هذه الرسوم وحدها قيمة البيع نفسها. احسب الأرقام بناءً على قيم طلباتك الخاصة قبل اتخاذ القرار.
