تصل ثلاثة إشعارات استرداد من App Store بعد أن يقرر Apple، وإشعار REFUND_REVERSED يعيد البيع إليك

يقرر Apple بشأن استردادك، ثم يستمر في التحدث. بمجرد تحديد النتيجة، يرسل App Store إلى خادمك واحداً من ثلاثة إشعارات استرداد من App Store، ويطلب كل منها خطوة مختلفة. يقول إشعار REFUND إن المال قد ذهب وعليك سحب الوصول. يقول إشعار REFUND_DECLINED إن العميل خسر الطلب وأنت تحتفظ بالبيع. يقول إشعار REFUND_REVERSED إن Apple ألغى استرداداً كان قد منحه بالفعل، فالبيع لك من جديد وعليك أن تعيد كل ما سحبته. معظم التطبيقات تربط الإشعار الأول وتتجاهل الآخرين بهدوء. هكذا ينتهي الأمر بعميل يدفع محروماً من شيء دفع مقابله.

هذه الثلاثة منفصلة عن CONSUMPTION_REQUEST، وهو رسالة الاسترداد الوحيدة التي تطلب منك الرد. إشعارات ما بعد القرار لا تريد جدالاً. تريد HTTP 200 والتغيير الصحيح في وصول العميل. إليك ما يعنيه كل واحد منها، والحقول الدقيقة التي تحمل الحقائق، وأين يتسرب المال عندما تتعامل معها بشكل خاطئ.

إشعارات الاسترداد الأربعة، وأيها يريد رداً

App Store Server Notifications V2 هو موجز واحد. توجّهه إلى عنوان URL واحد ويرسل Apple كل نوع من الإشعارات إليه، لذا فأنت تتلقى بالفعل رسائل الاسترداد الأربعة سواء تعاملت معها أم لا. أربعة من الأنواع تخص الاسترداد، وواحد منها فقط سؤال.

ماذا يخبرك إشعار REFUND فعلاً

ينطلق إشعار REFUND عندما ينجح App Store في استرداد قيمة معاملة لعميل. ينطبق على كل نوع شراء: منتج استهلاكي، ومنتج غير استهلاكي، واشتراك تلقائي التجديد، واشتراك غير متجدد. المعاملة الموقّعة داخل الإشعار تحمل الآن حقلين لم تكن تحملهما قبل الاسترداد، وهذان الحقلان هما القصة كاملة.

يحمل الحقلان revocationDate وrevocationReason الحقائق

الحقل revocationDate هو توقيت UNIX، بالمللي ثانية، الذي استرد فيه App Store قيمة المعاملة أو ألغاها. يخبرك الحقل revocationReason بفئة الاسترداد، ويأخذ قيمتين بالضبط.

وجود revocationDate على معاملة هو بحد ذاته العلامة. إذا جلبت معاملة لاحقاً ووجدت فيها revocationDate، فإن عملية الشراء تلك قد استُردت، بإشعار أو بدونه. اقرأ السبب إلى جانبه حتى لا تمر موجة من عمليات الاسترداد بقيمة 1 على إصدار واحد بجوارك كأنها ضجيج.

ألغِ حسب المعاملة، لا حسب المنتج

الفخ هنا هو الإلغاء المفرط. يسمّي إشعار REFUND معاملة واحدة. لا يطلب منك تعطيل كل عملية شراء أجراها العميل من ذلك product id. توجيه Apple نفسه هو التحقق من الوصول الذي لا يزال العميل يملكه قبل أن تقطع أي شيء، لأن الاستحقاقات تتداخل. الحالة الكلاسيكية هي اشتراك: يصل استرداد على تجديد الشهر الماضي بينما تجديد هذا الشهر نشط ومدفوع بالكامل. ألغِ على المنتج وتكون قد قطعت للتو الوصول عن عميل حالي يدفع، بسبب استرداد لفترة انتهت بالفعل.

يعني إشعار REFUND_DECLINED أنك فزت بالفعل، فلا تتراجع عن ذلك

يصل إشعار REFUND_DECLINED عندما يرفض App Store طلب استرداد العميل. طلب العميل، ورفض Apple، وأنت تحتفظ بالبيع. ظاهرياً لا يوجد ما تفعله، وهذا هو المقصود. الخطأ الذي يكشفه هذا الإشعار مختلف: إلغاء الوصول مبكراً.

إذا كان شفرتك تتفاعل مع CONSUMPTION_REQUEST بسحب وصول العميل قبل أن يحكم Apple، فإن إشعار REFUND_DECLINED هو اللحظة التي ينفجر فيها ذلك القرار. احتفظ Apple بمالك، وحرمت عميلاً رُفض استرداده من الوصول. ذلك العميل يدفع الآن مقابل منتج لا يستطيع استخدامه، ويفتح تذكرة دعم، ويتذكر ذلك. الحل قاعدة، لا ميزة: ألغِ عند REFUND، ولا تلغِ أبداً عند الطلب. إشعار REFUND_DECLINED هو ببساطة تأكيد من Apple بأن الإلغاء المبكر كان سيكون القرار الخاطئ.

إشعار REFUND_REVERSED هو الإشعار الذي يعيد إليك المال

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

مشكلة ما بعد أسابيع

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

أين يكمن المال في إتقان هذا

كل من هذه الإشعارات يرتبط برقم حقيقي، وتكلفة سوء التعامل معه ليست سعر البيع وحده.

REFUND: توقف عن الدفع لخدمة عميل استُرد ماله

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

REFUND_DECLINED: لا تحوّل فوزاً إلى استرداد من حسن النية

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

REFUND_REVERSED: أسوأ اقتران هو ذهاب مالهم ووصولهم معاً

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

ماذا تُعِد

التعامل بسيط بمجرد أن يكون النموذج صحيحاً. اربط الاستحقاقات بـ transaction id حتى يشير كل إشعار إلى عملية شراء واحدة. عند CONSUMPTION_REQUEST، أرسل بياناتك خلال 12 ساعة. عند REFUND، ألغِ تلك المعاملة. عند REFUND_DECLINED، لا تفعل شيئاً. عند REFUND_REVERSED، أعِد الوصول. أرجِع HTTP 200 بسرعة على جميعها ونفّذ تغيير الوصول في وقتك الخاص.

بالنسبة للفجوة التي تتركها الإشعارات، استخدم نقطة نهاية Get Refund History. إذا كان خادمك متوقفاً أثناء انقطاع وفاته إشعار REFUND، فاستدعِ بحث الاسترداد في App Store Server API لأجل transaction id، على /inApps/v2/refund/lookup/{transactionId}، واقرأ المعاملات الموقّعة مع revocationDate وrevocationReason الخاصة بها. يطابق معاملة واحدة في كل مرة ويتصفح عمليات الشراء المستردة للعميل، فلا يصبح webhook فائت استحقاقاً مضبوطاً بشكل خاطئ بشكل دائم.

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