وقعت أول حالة chargeback فوّتها في حياتي في الساعة 11:40 من مساء يوم سبت. لم أكتشف ذلك إلا بعد أن بحثت في سجلّات Pub/Sub يوم الاثنين، فوجدتها جالسة في موضوع (topic) لا يستهلكه أحد.
كان ذلك قبل 3 أغسطس 2026. في ذلك الوقت، كانت خسارة واحدة تكلّفك البيعة ولا شيء آخر تقريبًا.
أصبحت Google Play الآن تحمّل المطوّرين تكاليف chargeback على الطلبات التي تتم بعد ذلك التاريخ. فتتحمّل أنت قيمة الطلب مطروحًا منها رسم الخدمة الخاص بهم، بالإضافة إلى رسم شبكة البطاقات الذي يتراوح بين 15 و25 دولارًا للحالة الواحدة. وقد أعطتك Google شيئًا في المقابل أيضًا: واجهة Review Refund API، ونحو 24 ساعة لتقديم الأدلة.
فالسؤال ليس هل تتعامل مع حالات chargeback. السؤال هو ما الذي يتعامل معها في منتصف الليل. يمكنك إعداد ذلك عبر الدفاع عن chargeback في Google Play. وهذا هو الشرح المطوّل: أربعة خيارات، اثنان منها سأحاول إقناع معظم الفرق بتجنّبهما.
أهم النقاط
التعامل مع chargeback في Google Play له نقطة إدخال واحدة: واجهة ReviewRefund API، خلال 24 ساعة من صدور Pending Refund Review Notification.
تسجّل Google أول استدعاء تقوم به وتتجاهل بقية الاستدعاءات، مع أنها تستمر في إرجاع استجابة OK. فرصة واحدة بلا تصحيحات.
فقط حالات chargeback قابلة للطعن. أما استردادات الدعم، واستردادات الـ48 ساعة في Play، والتجارب غير المؤكدة (unacknowledged trials)، فتُحسم دون تدخّلك.
أربعة بدائل حقيقية: أن تبنيه بنفسك، أو تستخدم منصة الاشتراكات التي تتعامل معها، أو تشتري برنامجًا جاهزًا، أو تتقبّل الخسارة.
تغيّرت المعادلة في 3 أغسطس 2026. فوّت مهلة واحدة على خطة سنوية بقيمة 99 دولارًا، وستُكلّفك قيمة الطلب بالإضافة إلى رسم الشبكة.
كيف يبدو التعامل اليدوي في الواقع
بصراحة، تشمل كلمة "يدوي" نطاقًا واسعًا. في أحد طرفيه، هناك صندوق بريد مشترك وشخص يتحقق من Play Console حين يتذكّر. وفي الطرف الآخر، هناك جدول دوام، وقناة على Slack، وجدول بيانات لتتبّع الطلبات المتنازع عليها.
النسخة الثانية أفضل. ومع ذلك فهي تفشل أيضًا، لأسباب لا علاقة لها بالجهد المبذول.
أولًا، لا يمكنك رؤية العدّاد. تبدأ مهلة الـ24 ساعة من لحظة وصول PendingRefundReviewNotification إلى موضوع Pub/Sub الخاص بك. ألم تُفعّل إشعارات المطورين في الوقت الفعلي (RTDN) من قبل؟ لن يُخبرك شيء بأن هناك مراجعة مفتوحة، ولن يضع Play Console أي شارة تنبيه لها.
ثانيًا، وهذا ما يفاجئ الكثيرين: تسجّل Google أول استدعاء لـ ReviewRefund وتتجاهل كل استدعاء يليه، بينما تستمر في إرجاع استجابة OK. يبدو الأمر كأنه نجح. وحين يكتب أحدهم ردًا في سكريبت في الساعة التاسعة صباحًا، بالاستناد إلى بيانات مُستخرجة يدويًا، فهذه هي الطريقة التي تحصل من خلالها على حقل خاطئ واحد بلا إمكانية للتراجع.
بذل مزيد من الجهد لا يحلّ أيًا من المشكلتين.
عملية chargeback في Google Play
يستحق الأمر التوضيح، لأن المهلة أقصر مما يتصوّره الكثيرون.
يتنازع العميل على المبلغ مع بنكه. ليس معك، ولا مع Google.
تضع Google علامة على الطلب للمراجعة، وترسل PendingRefundReviewNotification عبر RTDN، يحمل pendingRefundToken، و orderId، وقيمة refundReason تساوي 7 (وهي CHARGEBACK)، وكذلك obfuscatedAccountId إن كنت قد حدّدته عند الشراء.
أمامك نحو 24 ساعة لاستدعاء ReviewRefund مع تحديد تفضيلك وأي أدلة تستطيع جمعها.
تستخدمها Google للدفاع عن القضية أمام البنك.
وإذا خسرت، فإن التكلفة تقع عليك في الطلبات التي تمت بعد 3 أغسطس 2026.
هناك عدم تماثل يستحق التوقّف عنده. تسأل Apple عن الاستردادات العادية عبر CONSUMPTION_REQUEST. أما Google Play فلا تفتح مراجعة إلا لحالات chargeback. وكل ما عدا ذلك يُحسم دون تدخّلك، وتعرف به عبر عملية شراء مُلغاة (voided purchase). التفاصيل الكاملة هنا: شرح حالات chargeback في Google Play.
الخيار الأول: بناء المعالِج بنفسك
موضوع (topic) في Pub/Sub. تفعيل RTDN من قسم Monetize، ثم Monetization setup. نقطة نهاية push تتحقق من صحة الرسالة قبل الوثوق بها. ثم فك ترميز حقل data بصيغة base64، والتفرّع بحسب أي من خمسة كائنات إشعار ظهر، ومطابقة الطلب بالمستخدم، وجمع الأدلة، واستدعاء ReviewRefund برمز OAuth محدد الصلاحيات.
البناء ليس هو الجزء المكلف. أسبوعان، إذا سبق لك التعامل مع تمديدات (plumbing) الـ webhook.
السنة الثانية هي الجزء المكلف. تُغيّر Google حقلًا ما. وينتهي صلاحية رمز OAuth refresh token بهدوء في يوم أحد. ويتعطّل معالِجك في نفس الليلة التي يصل فيها نزاع بقيمة 200 دولار، وهذا دائمًا ما يحدث بطريقة غريبة. ستحتاج إلى قابلية رصد (observability)، ومعالجة إعادة التشغيل (replay)، واختبارات لأشكال إشعارات لم ترها من قبل.
إذا كنت تدير بنية خلفية (backend) وتمثّل الاستردادات بندًا حقيقيًا في إيراداتك، فابنِه. وأفضّل أن تفعل ذلك. أما إذا كنت شخصًا واحدًا يُصدر المنتج بمفرده، فهذا استغلال سيئ لوقتك خلال الشهر.
الخيار الثاني: استخدام منصة الاشتراكات التي تدفع لها أصلًا
تحقّق من هذا قبل كتابة أي كود. أضافت RevenueCat واجهة Review Refund API الخاصة بـ Google تحت ميزة Refund Control، وتمتلك Adapty ميزة Refund Saver في جانب Apple.
جاذبية هذا الخيار: إيصالاتك، وصلاحياتك (entitlements)، وربط العملاء موجودة هناك أصلًا، لذا تكون الأدلة أقرب إليك، وتكون مسألة مطابقة الحسابات محسومة.
الحد: الاستجابة للاسترداد هي مجرد ميزة بالنسبة لهم، لا المنتج الأساسي. تَوقّع تفضيلًا واحدًا وبعض الأعلام (flags)، لا 1000 حدث استخدام (usage events) مزوّد بعناوين IP. وهذا يكفي لكثير من التطبيقات. لكنه لا يكفي في النزاعات الكثيفة بالاحتيال.
الخيار الثالث: برنامج مخصّص لإدارة chargeback في Google Play
كانت هذه الفئة من البرامج نادرة الوجود قبل 3 أغسطس، وهذا يُخبرك بمدى حداثة هذا الحافز.
الشكل العام متّسق. تشترك الخدمة في RTDN الخاصة بك، وتقدّم توصية بالرفض (decline) مدعومة بأدلة التسليم والتفاعل خلال المهلة المحددة، وتتابع نتيجة كل حالة.
Refund Sensor تقوم بذلك لكل من Google Play وApp Store من حساب واحد. سجّل الدخول باستخدام Google، ومنحه صلاحيتين من Play Console (عرض البيانات المالية، وإدارة الطلبات والاشتراكات)، وسيقوم بإنشاء موضوع Pub/Sub بنفسه. بلا SDK، وبلا تغييرات في الكود، وبلا أي شيء يحتاج إلى إعادة إرسال.
الخيار الرابع: تقبّل الخسارة
هذا خيار معقول بالنسبة لبعض التطبيقات، ولن أتجاهل ذلك. فإذا كنت تبيع عنصرًا قابلًا للاستهلاك بسعر 1.99 دولار، وترى أربع حالات chargeback في السنة، فإن أسبوعين من العمل الهندسي لن يعوّضا تكلفتهما أبدًا.
لكن احسب الأرقام أولًا. خسارة حالة chargeback واحدة على خطة سنوية بقيمة 99 دولارًا تكلّفك قيمة الطلب مطروحًا منها رسم خدمة Google، بالإضافة إلى رسم شبكة يتراوح بين 15 و25 دولارًا. وحالتان من هذا النوع في ربع سنة واحد يُغيّران الإجابة.
كيف تُؤتمِت التعامل مع chargeback في Google Play
إذا اختَرت الخيار الأول، فهذا هو ترتيب البناء. والتسلسل أهم مما يتوقّعه الكثيرون.
فعّل RTDN في Play Console، وأنشئ موضوع Pub/Sub. انقر على Send Test Message قبل أن تثق في القناة.
فكّ ترميز حقل data وتفرّع بحسب كائن الإشعار الذي وصل. يصل كائن واحد فقط في كل رسالة. عند استلام pendingRefundReviewNotification، خزّن pendingRefundToken وابدأ عدّادًا زمنيًا (timer). ليس بريدًا إلكترونيًا. عدّاد زمني.
طابِق orderId بمستخدم. يُعدّ obfuscatedAccountId المسار الأسرع لذلك، وهذا سبب كافٍ لتبدأ بتحديده عند الشراء.
جمّع الأدلة: sampleContentProvided، وconsumptionPercentageMilliunits (حيث تعني القيمة 45200 نسبة 45.2 بالمئة)، وحتى 1000 من consumptionUsageEvents مزوّدة بالطوابع الزمنية وعناوين IP.
استدعِ orders.reviewrefund مرة واحدة، مع تحديد refundPreference بقيمة APPROVE أو DECLINE أو NEUTRAL. سجّل الاستدعاء، والحمولة (payload)، والاستجابة.
وبشكل منفصل، تعامل مع voidedPurchaseNotification لإزالة الوصول، وشغّل Voided Purchases API كل ليلة لإجراء المطابقة. وهي محدودة بسقف 6000 استدعاء في اليوم.
تلك الخطوة الأخيرة هي التي يتجاهلها الجميع. وقد تجاهلتُها بنفسي لعدة أشهر. تُفوَّت الإشعارات أثناء الأعطال، وواجهة pull API هي طريقتك لمعرفة ما وصل خلال فترة توقّف خدمتك. Voided Purchases API في مقابل إشعارات المطورين الفورية يغطّي أي تغذية (feed) تقوم بأي وظيفة.
الوقاية من chargeback في Google Play
أرخص من كل ما سبق، ويعمل حتى على النزاعات التي لا تتوقّعها أبدًا.
العميل الذي يصل إلى دعمك لا يصل إلى بنكه. فمسار تواصل واضح داخل التطبيق، بالإضافة إلى رد في غضون يوم واحد، يقضي على نسبة مفاجئة من النزاعات قبل أن تبدأ.
ثم اجعل التجديد واضحًا تمامًا: السعر، والمدة، وتاريخ التجديد على نفس شاشة زر الشراء. فالمفاجأة تتسبّب في مزيد من النزاعات أكثر من أي شيء آخر رأيته.
وأمران إضافيان لا يحصلان على اهتمام كافٍ. راقب المشتريات غير المؤكدة (unacknowledged purchases)، لأن التجارب التي تتحول دون أن يلاحظها أحد تصبح حالات chargeback بعد شهر. واستخدم voidedReason كمؤشر على الاحتيال. فهو يحمل تسع قيم، من بينها fraud وfriendly_fraud وchargeback، وتلك الحسابات تتكرر. ضع علامة عليها قبل أن تمنحها تجربة أخرى.
حافظ على معدّلك أقل من الحد الذي تضعه Google. فالمشاكل المستمرة تؤثّر على سمعة الحساب، وهذا أسوأ من أي استرداد فردي.
المصادر
الأسئلة الشائعة
الاسترداد (refund) يتم عبر Google، وتقرره Google أو أنت في Play Console. أما chargeback فهو أن يتوجه العميل إلى بنكه، وهذا يضع الأمر تحت قواعد شبكة البطاقات. فقط chargeback يفتح مراجعة يمكنك الرد عليها، وتكلفته فقط هي التي تنتقل إليك.
نحو 24 ساعة من لحظة استلام PendingRefundReviewNotification. يبدأ العدّاد عند التسليم، لا عند ملاحظتك له.
تتولى Google الدفاع عن حالة chargeback دون أدلتك، وهذا أضعف موقف ممكن. وفي الطلبات التي تمت بعد 3 أغسطس 2026، تكلّفك الخسارة قيمة الطلب مطروحًا منها رسم الخدمة، بالإضافة إلى رسم شبكة البطاقات.
لا. تسجّل Google أول استدعاء لـ ReviewRefund وتتجاهل أي استدعاء لاحق، مع أنها تستمر في إرجاع استجابة OK. اختبره مقابل عملية شراء تجريبية قبل أن يقترب من بيئة الإنتاج.
أيًا كان البرنامج الذي يقدّم الرد دون حاجة إلى أن تكون مستيقظًا. إذا كنت تدير بنية خلفية (backend)، فبناء الحل مشروع معقول. وإن لم تكن تدير واحدة، فإن برنامج إدارة استرداد أموال Google Play الذي يتصل عبر صلاحيات Play Console أفضل من كتابة مستهلك (consumer) لـ Pub/Sub من أجل حالة استثنائية واحدة.
لا. أنت تقدّم توصيتك عبر Google Play Developer API الخاصة بـ Google نفسها، مدعومة بأدلة التسليم والاستهلاك. هذه هي القناة التي صممتها Google لهذا الغرض.
