استخدم Google Play RTDN للتعامل السريع مع الأحداث. استخدم Voided Purchases API للتحقق من الطلبات الملغاة ومطابقة سجلاتك. بالنسبة لمعظم التطبيقات المدفوعة، الخيار الأكثر أمانًا هو استخدام كلتا الأداتين معًا.
إذا كنت تخطط لـ الدفاع عن المبالغ المستردة لتطبيقات Google Play، فابدأ بهذا التقسيم. يخبرك أحد المسارين بأن شيئًا ما قد تغيّر. ويتيح لك المسار الآخر أن يجلب خادمك قائمة بعمليات الشراء الملغاة ويتحقق من ما فاته.
الاختيار هنا ليس بالضبط بين نظامي إشعارات. فـ Google Play RTDN يرسل الرسائل عبر Cloud Pub/Sub. أما Voided Purchases API فهي واجهة برمجية تعتمد على السحب (pull API): يستدعيها خادمك الخلفي.
لا يمنع أي منهما بمفرده أي شخص من طلب استرداد الأموال. تكمن قيمتهما في اكتشاف التغييرات، والتحقق من الطلبات، والتأكد من أن الوصول المدفوع يتطابق مع حالة الشراء.
أهم النقاط
استخدم RTDN للاستجابة لأحداث الشراء والاشتراك على الفور.
استخدم قائمة عمليات الشراء الملغاة كمسار ثانٍ للتحقق من الطلبات المتأثرة.
لا تعتبر إلغاء الاشتراك دليلًا على استرداد الأموال.
اجعل كلا المسارين يستخدمان منطق تحديث وصول آمنًا واحدًا.
احتفظ بمراجعة النزاع المصرفي (chargeback) المعلّقة منفصلة عن الإلغاء المكتمل.
ما هو Google Play RTDN؟
يرسل Google Play Real-Time Developer Notifications، المعروف غالبًا باسم RTDN، أحداثًا متعلقة بالشراء إلى موضوع (topic) في Cloud Pub/Sub.
يستقبل خادمك الخلفي رسالة ويوجّهها إلى العامل (worker) المناسب. نوع الرسالة مهم. فالتجديد والإلغاء وعملية الشراء الملغاة ليست الحدث نفسه.
لتتبع المبالغ المستردة، انتبه جيدًا إلى voidedPurchaseNotification. وهو يتضمن:
purchaseToken: يربط الحدث بعملية شراء محددة.
orderId: يحدد الطلب المتأثر.
productType: يحدد إن كان اشتراكًا أو عملية شراء لمرة واحدة.
refundType: يميّز بين الإلغاء الكامل والاسترداد الجزئي القائم على الكمية.
مرجع Google لـ RTDN وتعريفات الأحداث يشرح هذه الحقول وأنواع الإشعارات الأخرى.
يُعد RTDN مفيدًا عندما تريد التحرك سريعًا بعد حدوث تغيير. لكن الرسالة الواحدة ليست قاعدة بياناتك الكاملة للشراء. طابقها مع السجلات المخزنة واسترجع حالة الشراء ذات الصلة عند الحاجة قبل تغيير الوصول.
هل يعني إلغاء الاشتراك استرداد الأموال؟
لا. يمكن للعميل إيقاف التجديدات المستقبلية بينما لا يزال يحتفظ بالوصول المدفوع لبقية الفترة الحالية.
لا تبنِ قاعدة تزيل الوصول في كل مرة يَرِد فيها SUBSCRIPTION_CANCELED. بل تحقق من حالة الاشتراك وتاريخ انتهائه بدلًا من ذلك. يحتاج الإلغاء الفوري (revocation) وانتهاء الصلاحية إلى معالجة خاصة بهما.
ما هي Voided Purchases API؟
تُعيد Google Play Voided Purchases API قائمة بعمليات الشراء التي تم إلغاؤها أو استرداد أموالها أو عكسها عبر نزاع مصرفي (chargeback) ضمن نطاقها المدعوم.
تنطبق على طلبات الشراء داخل التطبيق لمرة واحدة وعلى الاشتراكات. يمكن لخادمك استخدام النتائج للتحقق من عمليات الشراء التي لم يعد ينبغي أن تمنح الوصول.
يمكن أن تتضمن القائمة رقم الطلب (order ID)، ورمز الشراء (purchase token)، ووقت الإلغاء، ومصدر الإلغاء، وسبب الإلغاء. وبالنسبة إلى عمليات الاسترداد الجزئي القائمة على الكمية المدعومة، يمكن أن تتضمن أيضًا الكمية المستردة.
دليل Google لـ Voided Purchases API يوثّق فترة استرجاع مدتها 30 يومًا. وهو ليس أرشيفًا دائمًا للمبالغ المستردة. احفظ السجلات المعالجة في نظامك الخاص.
تُعد هذه الواجهة البرمجية مفيدة بشكل خاص بعد تعطل أحد العمال (worker)، أو خطأ في التوجيه، أو وجود ثغرة في سجلاتك المحلية. كما توفر لك فحصًا دوريًا مقابل الأحداث التي عالجتها.
RTDN مقابل Voided Purchases API: الفرق العملي
السؤال | Google Play RTDN | Voided Purchases API |
كيف يعمل؟ | تنشر Google حدثًا إلى Pub/Sub. | يطلب خادمك قائمة. |
ما هو دوره الأساسي؟ | التعامل السريع مع تغييرات حالة الشراء. | التحقق من الطلبات الملغاة ومطابقتها. |
هل يغطي أحداثًا تتجاوز المبالغ المستردة؟ | نعم، بما في ذلك التجديدات وأحداث دورة الحياة الأخرى. | يركّز على عمليات الشراء الملغاة. |
هل يمكن أن يساعد بعد وجود ثغرة في المعالجة؟ | يعتمد استرجاع Pub/Sub على إعداداتك وفترة الاحتفاظ بالبيانات. | يمكنه سرد السجلات المتاحة ضمن نافذة الـ30 يومًا. |
هل يحتاج إلى حماية من التكرار؟ | نعم. | نعم، خصوصًا عندما تتداخل عمليات الفحص أو تتشارك الأحداث مع RTDN. |
السؤال الأساسي ليس أي أداة أفضل بمفردها. بل أي نوع من الفشل تساعدك كل أداة على التعامل معه.
يوفر لك RTDN مسارًا سريعًا. وتوفر لك الواجهة البرمجية (API) مسار تحقق. يجب أن تجمع قاعدة بياناتك الخاصة بينهما.
أي واحدة يجب أن يستخدمها تطبيقك؟
استخدم RTDN عندما تكون السرعة مهمة
لا ينبغي أن يحتاج التطبيق المدفوع إلى الانتظار حتى عملية فحص مجدولة قبل أن يلاحظ تغيّرًا في حالة الشراء.
استخدم RTDN عندما يحتاج تطبيقك إلى تحديثات فورية للاشتراكات وعمليات الشراء لمرة واحدة والطلبات الملغاة. وجّه كل حدث حسب نوعه بدلًا من تطبيق قاعدة استرداد واحدة على جميع الرسائل.
استخدم الواجهة البرمجية عندما يكون الاكتمال مهمًا
استخدم فحوصات مجدولة عبر الواجهة البرمجية للعثور على الطلبات الملغاة التي لم يطبّقها عامل (worker) تطبيقك على سجلاتك.
على سبيل المثال، قد يكون المستقبل (receiver) لديك قد قبل رسالة، ولكن خطأ ما قد أوقف تحديث الوصول اللاحق. إصلاح عملية التسليم وحدها لن يصلح تلك الثغرة المحلية.
استخدم كلتا الأداتين في سير عمل استرداد فعلي (production)
بالنسبة لمعظم التطبيقات المدفوعة، اجمع بينهما. اجعل كلا المسارين يغذيان معالجًا مشتركًا واحدًا يتحقق من الطلب ويطبّق أي تغيير بأمان.
يقلّل هذا من خطر أن يترك حدث واحد فائت الوصول نشطًا. كما يقلّل من الخطر المعاكس: إزالة الوصول مرتين لعملية الاسترداد نفسها.
كيفية اكتشاف عمليات استرداد الأموال في Google Play خطوة بخطوة
1. احتفظ بسجل للشراء (ledger)
خزّن حزمة التطبيق (app package)، ورمز الشراء، ورقم الطلب، والمنتج، وربط المستخدم، والكمية الممنوحة. السجل هو ببساطة سجل واضح لما تم شراؤه وما الوصول الذي منحه.
بالنسبة للاشتراكات، خزّن أيضًا أرقام طلبات التجديد. يشير مرجع RTDN إلى أن كل تجديد تلقائي له رقم طلب جديد. رمز الشراء بمفرده لا يكفي لتحديد كل تجديد متأثر.
2. أمّن رسائل RTDN ووجّهها
اضبط إعدادات الوصول إلى Pub/Sub بشكل صحيح. بالنسبة للتسليم الدفعي (push)، تحقق من الطلب الموثّق. وبالنسبة للتسليم بالسحب (pull)، قيّد من يمكنه قراءة الاشتراك (subscription).
فكّ تشفير الرسالة، وتحقق من اسم الحزمة، واحفظها قبل تنفيذ أي عمل بطيء. أرسل أحداثًا اختبارية عبر المسار الكامل، لا عبر نقطة الاستقبال فقط.
3. شغّل فحصًا مجدولًا لعمليات الشراء الملغاة
استدعِ طريقة القائمة (list method) باستخدام بيانات اعتماد مناسبة وصلاحيات Play Console. تابع جميع صفحات النتائج.
هناك إعدادان للاستعلام يسهل تفويتهما:
type=1 يشمل عمليات الشراء لمرة واحدة والاشتراكات معًا. القيمة الافتراضية، 0، تشمل فقط عمليات الشراء لمرة واحدة.
includeQuantityBasedPartialRefund=true يشمل عمليات الاسترداد الجزئي القائمة على الكمية المدعومة. قيمته الافتراضية هي false.
مرجع Google لـ voidedpurchases.list يغطي حقول الطلب والتصفح بالصفحات (pagination).
استخدم تداخلًا معتدلًا بين عمليات الفحص وأزل التكرار من النتائج. اختر معدل الفحص بناءً على حجم بياناتك، والحصص المخصصة (quotas)، ومقدار التأخير الذي يمكن أن يتحمله تطبيقك. لا تنتظر حتى تكون نافذة الاسترجاع على وشك الانتهاء.
4. طبّق كل تغيير مرة واحدة فقط
قد يُعلم كل من المسارين عن نفس الإلغاء. صمّم معالجة متكافئة القوة (idempotent): تنفيذ نفس التغيير مرة أخرى لا ينبغي أن يغيّر النتيجة.
لا تستخدم رقم الطلب بمفرده لتجاهل كل حدث لاحق. يمكن أن يحتوي شراء متعدد الكمية على عدة عمليات استرداد جزئي. تتبّع التعديلات المعالجة والكميات المستردة حتى لا يُفقد استرداد لاحق حقيقي.
5. راقب الثغرة، لا عدد الرسائل فقط
تتبّع آخر عملية فحص ناجحة، والصفحات غير المكتملة، وأخطاء العامل (worker)، والطلبات غير المتطابقة. قِس المدة التي يستغرقها تحديث الوصول بعد تأكيد الحدث.
للحصول على تقارير أوسع، راجع دليلنا لتتبع المبالغ المستردة والنزاعات المصرفية لتطبيقات الموبايل.
مثال: استرداد واحد، مساران للاكتشاف
هذا سير عمل افتراضي، ولا يمثل حالة عميل تم الإبلاغ عنها.
يشتري لاعب حزمة لمرة واحدة تمنح 500 عملة. ثم يتم إلغاء عملية الشراء بالكامل في وقت لاحق.
يرسل RTDN رسالة شراء ملغى. يجد عامل تطبيقك الطلب، ويتحقق من المنحة المسجلة، ويطبّق سياستك المنشورة على العملات المرتبطة بتلك عملية الشراء.
بعد ذلك، يُعيد فحص الواجهة البرمجية المجدول نفس الطلب. يرى المعالج المشترك أن تعديل الإلغاء الكامل قد طُبّق بالفعل. فيسجّل التطابق ولا يقوم بأي خصم ثانٍ.
الآن لنفترض أن العامل فشل قبل تطبيق التغيير الأول. يجد الفحص الطلب ويمنح نظامك مسارًا آخر لمعالجته.
هذا هو الهدف من استخدام كلتا الأداتين. ليس عقابين منفصلين، بل طريقتين للوصول إلى نتيجة صحيحة واحدة.
إذا كانت بعض العملات قد أُنفقت مسبقًا، فلا تقم بإزالة العملات بشكل عشوائي من حزمة مدفوعة غير مرتبطة. استخدم سياسة واضحة، واشرح الإجراء، ووفّر مسار دعم.
مراجعة الاسترداد المعلّقة هي سير عمل منفصل
تسرد وثائق Google الحالية أيضًا pendingRefundReviewNotification لطلب نزاع مصرفي (chargeback) يتطلب مراجعة من المطوّر.
بالنسبة لهذا الحدث، تقول Google إنه ينبغي تقديم اقتراح استرداد ودليل على استخدام الشراء من خلال orders.reviewrefund في غضون 24 ساعة.
لا تخلط بينه وبين voidedPurchaseNotification. أحدهما يتعلق بمراجعة معلّقة. والآخر يُعلم عن عملية شراء تم إلغاؤها.
لا تُعد Voided Purchases API بديلًا عن التعامل مع حدث المراجعة المعلّقة. احتفظ بهذا الفرع منفصلًا، ولا تفترض أن كل طلب استرداد يُنتج هذا الحدث.
مبالغ استرداد App Store وتسرب الإيرادات: ما يحتاج المطورون إلى معرفته
لا يقتصر تسرّب الإيرادات على ما إذا كان المتجر يُعيد الأموال. فقد يعني أيضًا أن خادمك الخلفي يستمر في منح الوصول المدفوع بعد أن لم تعد عملية الشراء المعنية تدعم ذلك.
بالنسبة للفرق التي تعمل على كلتا المنصتين، الهدف مشابه: الحفاظ على توافق الأموال وحالة الشراء وسجلات الوصول. إلا أن أدوات المتجر وقواعد الأحداث مختلفة. لا تنسخ سير عمل من Apple إلى Google Play دون تعديل.
دليلنا لإدارة إيرادات استرداد App Store يغطي مشكلة إدارة الإيرادات الأوسع. بالنسبة لهذا التكامل مع Google Play، ركّز أولًا على الإلغاءات الفائتة، والخصومات المكررة، والتغييرات غير الصحيحة في الوصول إلى الاشتراكات.
ما يمكن وما لا يمكن لمنع الاحتيال في استرداد أموال Google Play القيام به
يبدأ منع الاحتيال في استرداد أموال Google Play بسجلات سليمة وقواعد عادلة. الطلب الملغى ليس دليلًا على أن العميل تصرّف بعدم أمانة.
قد يكون للمستخدم شكوى مشروعة. قد تفشل عملية الدفع. قد يكون تطبيقك قد سلّم العنصر الخاطئ.
استخدم هذه الأدوات للتحقق من الحقائق وتطبيق تغييرات الوصول. راجع الأنماط المتكررة في سياقها. تجنّب الحظر التلقائي للحسابات بناءً على استرداد واحد، واسمح للعملاء بالطعن في الأخطاء.
لا يضمن لك RTDN ولا واجهة القائمة البرمجية (list API) إمكانية منع عملية استرداد أو رفضها أو عكسها.
الخلاصة
الاختيار بين RTDN وVoided Purchases API ليس قرارًا من نوع "إما هذا أو ذاك" بالنسبة لمعظم التطبيقات المدفوعة.
استخدم RTDN للاستجابة بسرعة. استخدم فحوصات مجدولة لعمليات الشراء الملغاة لمطابقة السجلات. أرسل كليهما عبر معالج آمن واحد، واحتفظ بالمراجعات المعلّقة منفصلة عن الإلغاءات المكتملة.
ابدأ باختبار صغير: أرسل إلغاءً واحدًا عبر كلا المسارين وتأكد من أن الوصول يتغيّر مرة واحدة فقط. ثم أوقف عاملك (worker) وتحقق من أن مسار الاستعادة يلتقط الثغرة.
الأسئلة الشائعة
يُعد RTDN أكثر ملاءمة للتعامل السريع مع الأحداث. أما الواجهة البرمجية (API) فهي أكثر ملاءمة للفحوصات المجدولة للطلبات الملغاة. تستفيد معظم التطبيقات المدفوعة من استخدام كلتا الأداتين معًا.
نعم. فهو يتضمن إشعار شراء ملغى (voided-purchase notification) يحتوي على تفاصيل الطلب ونوع الاسترداد. تعامل مع هذا الحدث بشكل منفصل عن إلغاء الاشتراك.
يمكنك اكتشاف السجلات الملغاة المتاحة من خلال الاستقصاء الدوري (polling)، ولكن الاكتشاف ينتظر حتى عملية الفحص الناجحة التالية. كما ستفوّت أيضًا تدفق أحداث دورة الحياة الأوسع الذي يوفره RTDN.
توثّق Google نافذة زمنية مدتها 30 يومًا. احتفظ بسجلاتك الخاصة للفحوصات طويلة الأمد واحتياجات الدعم.
نعم. فعِّل نتائج الاسترداد الجزئي المدعومة في طلبات القائمة (list requests). تتبّع الكميات المستردة واحسب إمكانية حدوث أكثر من استرداد جزئي واحد على الطلب.
