يمكن أن تسلّم كل من Apple و Google نفس الاسترداد إلى خادمك أكثر من مرة، وإشعارات الاسترداد المكررة تكلّفك إن تصرفت بناءً على كل واحد منها

سيتلقى خادمك حدث الاسترداد نفسه أكثر من مرة، وقد صمم المتجران ذلك عن قصد. تعيد Apple إرسال App Store Server Notification حتى خمس مرات عندما لا تجيب نقطة النهاية لديك بوضوح. تسلّم Google Play إشعارات Real-time Developer Notifications عبر Cloud Pub/Sub، التي تعد بالتسليم مرة واحدة على الأقل ولا تعد بشيء عن الترتيب. لذا فإن السؤال ليس أبداً ما إذا كانت نسخة مكررة ستصل. السؤال هو ماذا يفعل رمزك في المرة الثانية التي يرى فيها الاسترداد نفسه. أخطئ في ذلك فتخصم رصيداً مرتين، أو تعكس دفعة مرتين، أو تستهلك حصة API قابلة للفوترة بإعادة فحص استرداد أغلقته بالفعل. إليك كيف تصل إليك إشعارات الاسترداد المكررة فعلياً، وأي التكرارات نسخ مكررة حقيقية وأيها يبدو كذلك فقط، وكيفية التعامل معها بحيث يكون التسليم الثاني مجانياً.

يُسلّم إشعار الاسترداد مرة واحدة على الأقل، وهو ليس نفس التسليم مرة واحدة بالضبط

يعامل المتجران الإشعار المُسلّم على أنه وعد يستمران في محاولة الوفاء به، لا طلقة واحدة يطلقانها وينسيانها. هذا جيد للموثوقية، لأن إشعاراً تفوته أثناء عملية نشر يظل يصل إليك لاحقاً. وهو فخ للصحة، لأن الآلية التي تضمن أنك ستحصل على الحدث في النهاية تضمن أيضاً أنك ستحصل عليه أحياناً مرتين. يجب أن يكون معالجك idempotent، بمعنى أن التسليم الثاني والثالث لاسترداد واحد لا يغيّر شيئاً لم يغيّره الأول بالفعل.

تعيد Apple المحاولة خمس مرات على مدى ثلاثة أيام

عندما ترسل Apple إشعار App Store Server Notification V2، تتوقع أن يجيب خادمك بحالة HTTP في نطاق 200 إلى 206. أي شيء آخر، أي 4xx أو 5xx، يخبر Apple بأن التسليم فشل، فتعيد Apple المحاولة. الجدول ثابت: خمس إعادات محاولة، بعد 1 و12 و24 و48 و72 ساعة من المحاولة السابقة. باحتساب المحاولة الأولى، يمكن أن يصل حدث استرداد واحد حتى ست مرات، موزعة على نحو أسبوع تقريباً. كل واحدة من إعادات المحاولة تلك تحمل نفس notificationUUID. ذلك الحقل هو مفتاح إزالة التكرار لديك. إذا كنت قد سجّلت بالفعل notificationUUID، فإن التسليم الذي بين يديك تكرار، والاستجابة الصحيحة هي ألا تخزّن شيئاً جديداً وأن تُرجِع 200 مع ذلك.

تعمل Google Play على Pub/Sub، التي تعد بمرة واحدة على الأقل ولا تقول شيئاً عن الترتيب

تُنشر إشعارات Real-time Developer Notifications من Google Play على موضوع Cloud Pub/Sub. ضمان التسليم في Pub/Sub هو مرة واحدة على الأقل، ولا تقدم أي ضمان للترتيب على الإطلاق. هذا يعني أن الرسالة نفسها يمكن أن تُسلّم إلى نقطة النهاية لديك أكثر من مرة، وأن رسالتين لنفس عملية الشراء قد تصلان خارج الترتيب. إرشاد Google نفسه صريح: فُك حقل data بترميز base64، واقرأ messageId، وتحقق من أنك لم تره من قبل قبل معالجة أي شيء. messageId مكرر هو تكرار تتخطاه. مع ذلك ينبغي أن يهبط إشعاران مختلفان عن عملية شراء واحدة على السجل نفسه، لذا اجعل مفتاح حالتك المخزنة على purchaseToken أيضاً، ودع حدثاً لاحقاً يحدّث الصف الذي أنشأه حدث سابق.

التكرارات التي ليست نسخاً مكررة

ليس كل إشعار يبدو كإشعار رأيته من قبل هو إعادة محاولة. سلوكان من Apple يرسلان أحداثاً جديدة فعلاً تشترك في عملية شراء لكن يجب معالجة كل منها، وطيّها معاً بإزالة تكرار ساذجة يُلقي معلومات كنت بحاجة إليها.

ترسل Apple طلبات CONSUMPTION_REQUEST جديدة، لا إعادات محاولة

أثناء طلب استرداد مفتوح على عنصر استهلاكي، لا ترسل Apple طلب CONSUMPTION_REQUEST واحداً وتنتظر. ترسل طلبات جديدة دورياً طوال نافذة الاسترداد المفتوحة كاملة حتى يُغلق الاسترداد. أكّد موظفو Apple أن هذه ليست إعادات محاولة، والدليل هو الحقل الذي تزيل التكرار بناءً عليه: يحمل كل CONSUMPTION_REQUEST جديد notificationUUID مختلفاً. لذا فإن إزالة تكرار مفتاحها notificationUUID تقوم بالعمل الصحيح تلقائياً. تطوي إعادات المحاولة الحقيقية وتُبقي كل مطالبة مميزة. ما يجب ألا تفعله هو إزالة التكرار بناءً على معرّف المعاملة ونوع الإشعار، لأن ذلك سيُسكت كل CONSUMPTION_REQUEST بعد الأول ويكلّفك نافذة الأدلة البالغة 12 ساعة على تلك التي أسقطتها.

يمكن أن تحمل معاملة واحدة أكثر من قرار

يمكن أن ينتج نفس transactionId أكثر من نتيجة استرداد خلال عمره. يمكن أن ترسل Apple REFUND_DECLINED ثم لاحقاً REFUND للمعاملة نفسها، ويبلّغ المطورون عن تلقي ثلاثة إشعارات متعلقة بالاسترداد أو أكثر لمعرّف معاملة واحد. كل منها حدث مميز له notificationUUID الخاص به. إذا كان مفتاح إزالة التكرار لديك هو معرّف المعاملة، فإن القرار الثاني يبدو كنسخة مكررة من الأول ولا تعرف أبداً أن الاسترداد قد مُنح في النهاية. معرّف المعاملة يجمّع الأحداث. لا يعرّفها.

ماذا تكلّفك النسخة المكررة فعلاً

إشعار الاسترداد ليس ضوء حالة. إنه يُطلق إجراءات حقيقية: تلغي الوصول، تخصم رصيداً استهلاكياً، تعكس دفعة لصانع محتوى، تستدعي App Store Server API أو Play Developer API لتأكيد الحالة. شغّل أياً منها مرة ثانية على نسخة مكررة والتكلفة حقيقية.

تتبّع المال. إلغاء الوصول مرتين غير مؤذٍ، لأن الوصول قد زال بالفعل. خصم الرصيد مرتين ليس كذلك: مستخدم اشترى حزمة عملات واستردها يمكن أن يُدفع إلى رصيد سالب يضطر فريق الدعم لديك بعد ذلك إلى تسويته يدوياً. عكس دفعة مرتين يسترد مالاً أعدته بالفعل مرة واحدة، والآن أنت مدين لصانع محتوى باعتذار وتصحيح. وكل نسخة مكررة تعيد معالجتها مقابل API متجر تنفق حصة تحذّر Google صراحة من حمايتها، لذا فإن دفقة من إعادة تسليم Pub/Sub أثناء انقطاع يمكن أن تدفعك إلى تحديد المعدل في اليوم نفسه الذي تقل فيه قدرتك على تحمله.

ترفع نوافذ أدلة الاسترداد المخاطر من جانب Apple. إذا أسكتت إزالة تكرار ساذجة طلبات CONSUMPTION_REQUEST المتكررة التي ترسلها Apple طوال نافذة الاسترداد المفتوحة، فقد تفوتك تلك التي كنت بحاجة للرد عليها، وطلب CONSUMPTION_REQUEST لا ترد عليه خلال 12 ساعة هو استرداد كثيراً ما تمنحه Apple افتراضياً. هذا ليس خصماً مزدوجاً. إنه بيع مفقود إضافة إلى الحوسبة واستدعاءات API والتخزين والدفعات التي أنفقتها بالفعل في تسليم عملية الشراء، ولا يعيد الاسترداد أياً منها.

كيفية التعامل مع إشعارات الاسترداد المكررة دون التصرف مرتين

النمط نفسه على المتجرين، بمفتاح مختلف. سجّل التسليم، تحقق من المفتاح قبل أن تتصرف، تصرّف مرة واحدة، وأخبر المتجر دائماً بأنك استلمته.

• أزل التكرار بناءً على معرّف تسليم المتجر، لا المعاملة. استخدم notificationUUID لـ Apple وPub/Sub messageId لـ Google Play. خزّنه بقيد فريد بحيث تخسر نسخة مكررة متزامنة السباق بدلاً من التصرف مرتين.
• اجعل الإجراء اللاحق idempotent بشروطه الخاصة. المفتاح على معرّف التسليم يوقف إعادة المعالجة، لكن اكتب الأثر أيضاً بحيث يتحقق الإلغاء أو الخصم أو العكس من الحالة الراهنة أولاً ويكون آمناً للتشغيل مرتين.
• احفظ أولاً، ثم أكّد الاستلام. اكتب الحدث إلى قاعدة بياناتك قبل أن تُرجِع 200 أو تؤكد رسالة Pub/Sub. إن أكّدت أولاً وفشلت الكتابة، يعتبر المتجر الرسالة مُسلّمة ولا يرسلها أبداً مرة أخرى، والآن فقدتها إلى الأبد.
• أرجِع دائماً حالة نجاح، حتى لنسخة مكررة. 200 إلى 206 لـ Apple، و200 لدفع Pub/Sub لـ Google. رفض تكرار بخطأ يجعل المتجر يعيد إرساله فقط.
• اجمع على الكيان، عرّف على الحدث. اجعل مفتاح حالة الشراء المخزنة على purchaseToken أو originalTransactionId بحيث تحدّث التسليمات خارج الترتيب صفاً واحداً، لكن عامل كل notificationUUID أو messageId كحدثه الخاص، لأن عملية شراء واحدة تنتج عدة أحداث بشكل مشروع.

قائمة تحقق قصيرة قبل أن تثق في webhook الاسترداد لديك

• تُزال تكرارات تسليمات Apple بناءً على notificationUUID، والتكرار لا يكتب شيئاً جديداً لكنه يُرجِع 200 مع ذلك.
• تُزال تكرارات تسليمات Google Play بناءً على Pub/Sub messageId، ويُتحقق منها قبل أي معالجة.
• مفتاح حالة الشراء على purchaseToken أو originalTransactionId، بحيث تهبط الأحداث خارج الترتيب على سجل واحد.
• كل أثر جانبي للاسترداد، إلغاء أو خصم أو عكس، آمن للتشغيل أكثر من مرة.
• يكتب معالجك الحدث قبل أن يؤكد الاستلام، لا بعده أبداً.
• تُعامل طلبات CONSUMPTION_REQUEST المتكررة كمطالبات مميزة، لا كنسخ مكررة، بحيث لا تُسقط أي نافذة استرداد مفتوحة.

مرّر نسخة مكررة عبر webhook الخاص بك عمداً وراقب كيف لا تغيّر شيئاً في المرة الثانية. هذا هو الاختبار كله. معالج استرداد آمن للاستدعاء مرتين هو معالج يمكنك التوقف عن القلق بشأنه في اللحظة التي يقرر فيها متجر استدعاءه ست مرات.