إذا كان تطبيقك لا يزال يعمل على App Store Server Notifications V1، فإن Apple لا تسألك أبدًا عن استرداد مبالغ الاشتراكات

لا يزال Version 1 من App Store Server Notifications يُبلغك بعمليات الاسترداد، لكنه يُغفل الإشعار الوحيد الذي يتيح لك الدفاع عن موقفك في استرداد اشتراك. أوقفت Apple دعم V1 في 5 يونيو 2023، إلى جانب نقطة النهاية verifyReceipt، ومنذ ذلك الحين أضافت كل ميزة متعلقة بالاسترداد إلى V2 فقط. إذا كانت إعدادات App Store Connect لديك لا تزال تشير إلى Version 1، فقد تبتّ Apple في استرداد اشتراك دون أن ترسل إلى خادمك CONSUMPTION_REQUEST أبدًا. أنت لا تخسر معركة هنا. أنت لا تُدعى إليها من الأساس.

ماذا يعني إيقاف Apple لدعم App Store Server Notifications V1

إيقاف الدعم لا يعني الإطفاء. كتب أحد مهندسي Apple في منتديات المطورين في يونيو 2023 أن verifyReceipt وإشعارات V1 ستستمر في العمل إلى أن يُعلن موعد نهاية العمر، وأن هذا الموعد لم يُحدَّد بعد، وأن المطورين سيُبلَّغون مسبقًا. وبعد أكثر من ثلاث سنوات، لا يزال App Store Connect يعرض "Version 1 (deprecated)" خيارًا عند ضبط عنوان URL للخادم.

ما يعنيه إيقاف الدعم فعلًا هو التجميد. كل تغيير في سجل تغييرات الإشعارات لدى Apple منذ يونيو 2023 هو تغيير في V2: حقول جديدة في المعاملة الموقّعة، وأنواع إشعارات جديدة، وبيانات الالتزام لمدة 12 شهرًا المضافة في أبريل 2026. لا يرى خادم V1 شيئًا من ذلك.

إشارات الاسترداد التي لا يتلقاها خادم V1 أبدًا

إليك كيف تصل أحداث الاسترداد نفسها إلى خادم V1 وخادم V2، وفقًا لوثائق Apple لكل إصدار.

هل لا يزال V1 يتلقى CONSUMPTION_REQUEST أصلًا؟

نعم، للمنتجات القابلة للاستهلاك. يصف مرجع V1 من Apple الإشعار CONSUMPTION_REQUEST بأنه الإشعار المرسل عندما يبدأ العميل طلب استرداد لعملية شراء قابلة للاستهلاك داخل التطبيق. وأكد أحد مهندسي Apple في المنتديات عام 2023 أن طلبات الاستهلاك على V1 تُرسل لعمليات الاسترداد المؤهلة. الفجوة في الاشتراكات. يؤرخ سجل تغييرات Apple طلبات الاستهلاك للاشتراكات بتاريخ 11 أبريل 2024، في V2، وتنص وثائق Send Consumption Information على أن Apple ترسل الطلب عبر نقطة نهاية V2 لديك.

لماذا يسهل سوء فهم CANCEL على V1

على V1، عندما تسترد Apple مبلغ اشتراك، يكون نوع الإشعار CANCEL، وغالبًا ما يقترن بـ DID_CHANGE_RENEWAL_STATUS. تتعامل خوادم كثيرة مع أي إلغاء على أنه عميل أوقف التجديد التلقائي، فيبقى الوصول مفعّلًا حتى نهاية الفترة. يزيل V2 هذا الالتباس. يصل الاسترداد على شكل REFUND، ويصل إيقاف العميل للتجديد على شكل DID_CHANGE_RENEWAL_STATUS بالنوع الفرعي AUTO_RENEW_DISABLED.

كم يكلفك البقاء على V1 من المال

Apple هي من تبتّ في كل عملية استرداد على App Store. والإشعار CONSUMPTION_REQUEST هو النقطة الوحيدة التي تصل فيها بيانات الاستخدام لديك إلى هذا القرار، وتطلب منك Apple الرد خلال 12 ساعة. على V1، تتخطى عمليات استرداد الاشتراكات هذه الخطوة.

إليك مثالًا تطبيقيًا بأرقام توضيحية. لنفترض أن تطبيقك يبيع اشتراكًا شهريًا بسعر $9.99 يتضمن توليد صور بالذكاء الاصطناعي. يُجري أحد المشتركين 400 عملية توليد في شهر، وكل واحدة تكلفك مالًا حقيقيًا في استدلال النموذج. ثم يطلب من Apple استرداد المبلغ.

الدفعة التي تخسرها هي حصتك، لا السعر المعلن. تدفع Apple 70% من سعر الاشتراك، بعد خصم الضرائب المطبقة، خلال السنة الأولى من الخدمة المدفوعة للمشترك، و85% بعد ذلك أو لأعضاء App Store Small Business Program. ولا تنخفض فاتورة الحوسبة معها. فالاستدلال واستدعاءات API لدى الأطراف الثالثة وتخزين الملفات دُفعت عندما استخدمها العميل.

والإشعاران الغائبان عن نتيجة الطلب يكلفان مالًا أيضًا. بدون REFUND_REVERSED، فإن الخادم الذي ألغى الوصول عند الاسترداد لا يعيده أبدًا عندما تتراجع Apple عن الاسترداد، فيبقى عميل يدفع محرومًا من الوصول ويراسل الدعم. وبدون REFUND_DECLINED، لا يمكنك التمييز بين استرداد لا يزال معلقًا واسترداد رفضته Apple.

كيف تنتقل من V1 إلى V2 دون أن تفقد أي استرداد

الانتقال إلى V2 تغيير في الخادم إضافة إلى إعداد واحد. توضح إرشادات Apple نفسها في المنتديات، من أحد مهندسي App Store Commerce في ديسمبر 2025، ما يحدث في يوم التحويل.

أنشئ نقطة نهاية V2 قبل تغيير الإعداد

• اقبل طلب POST يحمل جسمه signedPayload. حمولات V2 بتنسيق JWS وتوقّعها Apple، لذا تحقّق من التوقيع قبل أن تثق بأي شيء بداخلها. تتولى App Store Server Library من Apple ذلك نيابة عنك.
• اربط معالجة CANCEL بـ REFUND، وعالج REFUND_DECLINED وREFUND_REVERSED كحالات جديدة.
• أجب عن CONSUMPTION_REQUEST الخاص بالاشتراكات عبر Send Consumption Information، وفقط عندما يوافق العميل على مشاركة البيانات مع Apple. تقول Apple إنه لا ينبغي لك الرد دون موافقة.
• أعد HTTP 200 إلى 206 عند النجاح. أي رمز 40x أو 50x يجعل Apple تعيد المحاولة.

غيّر الإعداد في App Store Connect

في App Store Connect، افتح تطبيقك، واختر App Information ضمن General، وابحث عن App Store Server Notifications، واضبط Production Server URL على نقطة نهاية V2 لديك مع تحديد Version 2. افعل الشيء نفسه لعنوان sandbox أولًا إن أردت الاختبار، واستخدم Request a Test Notification للتأكد من أن خادمك يستجيب.

أبقِ معالج V1 يعمل لنحو ثلاثة أيام

بعد التحويل، تصل الإشعارات الجديدة بتنسيق V2 فورًا، لكل اشتراك، قديمًا كان أو جديدًا. أما إشعارات V1 التي هي قيد إعادة المحاولة فتستمر في الوصول بتنسيق V1 حتى تنجح أو تنفد محاولاتها. تحدد Apple آخر محاولة ممكنة لـ V1 بنحو 78 ساعة، أي 6 + 24 + 48. اترك المعالج القديم يعمل لما بعد ذلك، ثم أزله.

استبدل verifyReceipt وأنت في ذلك

أُوقف دعم verifyReceipt في اليوم نفسه. لا يزال يستجيب، لكن Apple توجّه الخوادم إلى App Store Server API بدلًا منه. يعيد Get Transaction Info معاملة موقّعة واحدة، ويعيد Get Transaction History سجل العميل، ويسرد Get Refund History كل عملية شراء مستردة للعميل. ومع إشعارات V2، تغطي هذه الواجهات ما كانت معظم الخوادم تستخدم الإيصالات من أجله، بما في ذلك الحقل cancellation_date الذي كان يميّز الاسترداد في الإيصال.

يتصل RefundHalt بـ App Store Server Notifications V2 ويرد على كل CONSUMPTION_REQUEST خلال مهلة الـ 12 ساعة، مستخدمًا بيانات الاستخدام التي يسجلها تطبيقك بالفعل. إذا كنت لا تزال على V1، فالتحويل هو الخطوة التي تجعل كل ذلك ممكنًا.