إجابة سريعة: يوفر لك Google Play طريقتين لمعرفة أن عملية شراء تم استردادها أو إلغاؤها. تُرسل Real-time Developer Notifications (RTDN) الأحداث إلى خادمك لحظة حدوثها، عبر Google Cloud Pub/Sub. أما Voided Purchases API فتتيح لك سحب قائمة بعمليات الشراء الملغاة عند الطلب. هاتان الأداتان ليستا بديلتين لبعضهما، فـ RTDN توفر لك السرعة، وVoided Purchases API توفر لك شبكة أمان، وأي إعداد موثوق يستخدم كلتيهما حتى لا يفوتك شيء.
لماذا يوفر Google آليتين
على Google Play، تحدث معظم عمليات الاسترداد دون الرجوع إليك، فـ Google يصدرها، ويُلغي الحق (entitlement)، ومهمتك هي معرفة ذلك حتى يبقى تطبيقك وبياناتك التحليلية دقيقة. (لمعرفة ما يمكنك وما لا يمكنك الطعن فيه، راجع Google Play Refunds & Chargebacks.)
يقدم Google أداتين مختلفتين لمعرفة ذلك، وهما تحلّان المشكلة من اتجاهين متعارضين. الأولى ترسل الأحداث إليك فور حدوثها. والثانية تتيح لك طلب قائمة في أي وقت تشاء. عند استخدامهما معًا، تغطي كل أداة نقاط ضعف الأخرى؛ وعند استخدام أي منهما بمفردها، تبقى هناك ثغرة.
بالنسبة للمطورين المهتمين بتتبع استرداد المبالغ في أندرويد، فهم هذا الاختلاف مهم لأن تدفق الأحداث في الوقت الفعلي وآلية التسوية التاريخية يحلّان جزأين مختلفين من مشكلة رصد عمليات الاسترداد.
Real-time Developer Notifications (الدفع push)
تُعدّ Real-time Developer Notifications (RTDN) آلية الدفع (push). فعند حدوث أمر ما لاشتراك أو عملية شراء، بما في ذلك عمليات الاسترداد وعمليات الشراء الملغاة، ينشر Google حدثًا إلى موضوع (topic) في Google Cloud Pub/Sub يكون نظام الخلفية (backend) الخاص بك مشتركًا فيه. الهدف هو الفورية: فأنت تعلم بالحدث بُعيد وقوعه مباشرة، بدلًا من اكتشافه بعد ساعات.
بالنسبة للمطورين الذين يبحثون عن دمج RTDN مع Google Play، هذه هي الآلية التي تربط أحداث فوترة Google Play بنظام الخلفية الخاص بك. وفي أي أمر حساس من ناحية التوقيت، مثل مراجعة chargeback، حيث يكون لديك نحو 24 ساعة للرد، تصبح هذه الفورية هي كل ما يهم. وإذا كنت تعتمد على التحقق بشكل دوري، فأنت قد خسرت فعلًا وقتًا لم يكن متاحًا لك أصلًا.
والمشكلة هي: تعمل RTDN على Pub/Sub، وهذا يعني إعداد مشروع على Google Cloud، وموضوع (topic)، وأذونات النشر الصحيحة لـ Google Play، ومشترِك (subscriber) من جهتك. فهذا يتضمن أجزاء متحركة أكثر من webhook واحد، وهنا يتعثّر كثير من المطورين.
Voided Purchases API (السحب pull)
تُعدّ Google Play Voided Purchases API آلية السحب (pull). فهي تُرجع قائمة بالطلبات التي تم إلغاؤها أو استردادها أو إجراء chargeback عليها أو إبطالها، ويمكنك الاستعلام عنها عند الطلب. وبدلًا من انتظار حدث، تسأل Google مباشرة: ما الذي تم إلغاؤه؟
تكمن قوتها في الاكتمال والتعافي. فإذا تأخر إشعار الدفع أو فُقد أو لم تتم معالجته أبدًا، فإن السحب من Google Play Voided Purchases API يُظهر عملية الشراء الملغاة على أي حال. وهكذا تقوم بالتسوية وتتأكد من أن سجلك يطابق سجل Google.
والمقايضة هي أنها ليست فورية بطبيعتها، فهي شيء تستعلم عنه، لذا فهي بمفردها شبكة أمان وليست محفّزًا (trigger).
لماذا تحتاج إلى كلتيهما، لا إلى واحدة فقط
وهنا يأتي الفرق الذي يُشوّش على الكثيرين: هذا ليس قرار "اختر الأفضل من الاثنين".
RTDN بمفردها تمنحك السرعة ولكن دون ضمان الاكتمال، فإذا فاتك إشعار أو تعاملت معه بشكل خاطئ، يختفي ذلك الحدث من رؤيتك ببساطة.
Voided Purchases API بمفردها تمنحك الاكتمال دون السرعة، فلن تعرف بعملية الاسترداد إلا في المرة التالية التي تستعلم فيها.
RTDN في Google Play تمنح نظام الخلفية الخاص بك إشارة فورية، في حين توفر Google Play Voided Purchases API طبقة التسوية للأحداث المفقودة أو المتأخرة.
يستخدم الإعداد الموثوق RTDN كمحفّز فوري وVoided Purchases API كطبقة تسوية تلتقط أي شيء أسقطه مسار الدفع (push). السرعة مع شبكة أمان. وكل واحدة منهما بمفردها تترك ثغرة ستقع فيها في النهاية.
حيث يصبح الأمر معقدًا
إن إعداد هذا النظام بشكل صحيح أكثر تعقيدًا مما يبدو، والجهد المطلوب مستمر وليس لمرة واحدة:
توفير Pub/Sub. إنشاء الموضوع (topic)، ومنح Google Play صلاحية النشر، واشتراك نظام الخلفية الخاص بك، وضبط الأذونات بدقة تامة، هي الخطوة الأكثر احتمالًا لاستهلاك عصر يوم كامل أو ثلاثة. كما يحتاج إعداد Pub/Sub لفواتير Play هذا إلى أن يبقى موثوقًا مع نمو بنية الفوترة لديك.
نظامان يجب إبقاؤهما متزامنين. أنت الآن تُشغّل مستهلِك (consumer) للدفع ومهمة مجدولة للسحب والتسوية، وتحتاج إلى التأكد من توافقهما.
إزالة التكرار والترتيب. يمكن أن يصلك الحدث نفسه أكثر من مرة، أو بترتيب خاطئ؛ ويجب أن تكون معالجتك متكافئة (idempotent).
البقاء محدّثًا. يُعدّل Google واجهات برمجة الفوترة وأنواع الأحداث باستمرار، ويجب أن يواكب تكاملك ذلك أو ينجرف بهدوء خارج التوافق.
إشعارات استرداد Google Play. يحتاج نظامك إلى معالجة كل إشعار استرداد ذي صلة من Google Play بشكل صحيح وربطه بعملية الشراء والحق (entitlement) وسجل العميل المناسبين.
كل عنصر من هذه العناصر بمفرده ليس أمرًا غريبًا. لكن مجتمعة، فهي قطعة حقيقية من البنية التحتية يجب بناؤها وصيانتها، لقاء ميزة تتبع عمليات الاسترداد بدقة والتي لا يمكنك في الغالب الطعن فيها على أي حال.
كيف يتناسب هذا مع معالجة عمليات الاسترداد
عند تجميع القطع معًا، تتكون معالجة عمليات استرداد Google Play من نصفين: الإمساك بالشيء الوحيد الذي يمكنك الطعن فيه (مراجعة chargeback) خلال نافذته الزمنية، والتسجيل الدقيق لكل ما لا يمكنك الطعن فيه حتى تبقى بيانات الحقوق (entitlements) والتحليلات الخاصة بك صحيحة. ويعتمد النصفان على أن تكون أساسيات RTDN + Voided Purchases راسخة.
بالنسبة للفرق التي تسأل عن كيفية تتبع عمليات استرداد Google Play باستخدام RTDN وVoided Purchases API، فالإجابة هي استخدام RTDN للكشف السريع عن الأحداث وVoided Purchases API للتسوية والتعافي. وهذا يمنح نظام الخلفية الخاص بك صورة أكثر اكتمالًا عن عمليات الاسترداد وعمليات الشراء الملغاة وعمليات chargeback.
هذه هي بالضبط الطبقة التي تديرها لك RefundSensor. فهي توفّر موضوع Pub/Sub تلقائيًا بحيث تلصق فقط اسم موضوع واحد في Play Console، وتستقبل RTDN في الوقت الفعلي، وتُجري التسوية مقابل عمليات الشراء الملغاة حتى لا يفوتك شيء، وتُقدّم توصية بالرفض في مراجعات chargeback خلال النافذة الزمنية المحددة، وتسجّل كل عملية استرداد أخرى، كل ذلك في لوحة تحكم (dashboard) واحدة إلى جانب عمليات استرداد Apple الخاصة بك. وبهذا تحصل على نتيجة إعداد صحيح للآليتين دون الحاجة إلى بناء أو صيانة أي منهما.
المصادر الرسمية {#official-sources}
تتغيّر واجهات برمجة الفوترة الخاصة بـ Google، لذا تعامل مع وثائقها الرسمية بصفتها السلطة النهائية:
إعداد واحد، آليتان، وصفر صيانة. توفّر RefundSensor Pub/Sub تلقائيًا، وتستقبل RTDN في الوقت الفعلي، وتُجري التسوية مقابل عمليات الشراء الملغاة، وتتولى مراجعات chargeback لكلٍّ من Google Play وApple، كل ذلك في لوحة تحكم واحدة. ابدأ مجانًا ←
روابط داخلية لإضافتها بعد النشر: Google Play refunds cornerstone · Apple refund automation cornerstone · the 12-hour window.
الأسئلة الشائعة
تُرسل RTDN الأحداث إلى خادمك في الوقت الفعلي عبر Pub/Sub؛ أما Voided Purchases API فتتيح لك سحب قائمة بالطلبات الملغاة عند الطلب. توفر RTDN السرعة، وتوفر Voided Purchases API الاكتمال.
من أجل إعداد موثوق، نعم. تُعد RTDN المحفّز الفوري لديك، وتُعد Voided Purchases API شبكة الأمان الخاصة بالتسوية لكل ما يفوت مسار الدفع (push). وكل واحدة منهما بمفردها تترك ثغرة.
هي طلب لم يعد صالحًا، وذلك عادة بسبب استرداد أو chargeback أو إبطال. يساعد تتبع عمليات الشراء الملغاة في الحفاظ على دقة الحقوق (entitlements) والتحليلات لديك.
تعمل RTDN على Google Cloud Pub/Sub، وهذا يتضمن موضوعًا (topic)، وأذونات نشر لـ Google Play، ومشترِكًا (subscriber) من جهتك، وهي أجزاء متحركة أكثر من مجرد لصق رابط URL واحد. تقوم RefundSensor بتوفير موضوع Pub/Sub تلقائيًا للتخلص من هذا العائق.
في الغالب لا. فعمليات الاسترداد والإبطال العادية يقررها Google. الحالة الوحيدة القابلة للطعن هي مراجعة chargeback قيد التقييم، والتي يجب أن تلتقطها عبر RTDN وترد عليها خلال نافذتها الزمنية التي تبلغ نحو 24 ساعة.
