شرح سياسة استرداد الأموال في App Store لمطوري تطبيقات الجوال

Apple هي من تقرر ما إذا كان سيتم منح الاسترداد. أما ما تتركه السياسة لك فهو كل ما يحدث حول ذلك القرار، وهناك تكمن معظم الخسائر التي يمكن تجنبها.

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

هكذا يتعرف معظم المطورين على سياسة استرداد الأموال في App Store. ليس بقراءتها، بل باكتشافهم، بعد أشهر، ما لم تغطِّه قط.

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

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

أهم النقاط

● Apple تتخذ كل قرار استرداد. لا يوجد زر في App Store Connect للموافقة على استرداد أو رفضه، لأن هذا الخيار لم يكن يومًا بيد المطور.

● مكان إقامة العميل قد يغيّر النتيجة. تختلف الأهلية والإجراءات حسب الدولة أو المنطقة، وفقًا لـ شروط وأحكام Apple Media Services.

● يمكن لـ Apple إرسال إشعارات متعلقة بالاسترداد إلى خادمك، وقد تطلب معلومات حول كيفية استخدام عملية الشراء أثناء مراجعتها للطلب.

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

● الاسترداد الذي توافق عليه Apple والاسترداد الذي تسجّله قاعدة بياناتك حدثان منفصلان. والمسافة بينهما هي حيث يتسرب المال.

● يمكن للأتمتة أن تجعل جانبك من العملية أسرع وأكثر اتساقًا. لكنها لا تؤثر على ما تقرره Apple.

ما هي سياسة استرداد الأموال في App Store؟

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

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

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

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

الجزء الثاني هو القرار نفسه. وهذا قرار Apple بالكامل. ولا تعلم به إلا بعد اتخاذه.

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

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

يمكنك على الأرجح تخمين أي جزء يهمنا أكثر.

كيف تعمل عملية استرداد الأموال في Apple App Store بالنسبة للمطورين؟

العميل يبدأها. Apple تنهيها. وأنت في مكان ما في المنتصف.

يطلب العميل استردادًا عبر Apple

↓

تراجع Apple الطلب

↓

قد يتلقى خادمك إشعارًا متعلقًا بالاسترداد

↓

تقدّم معلومات داعمة، إن كان ذلك ينطبق

↓

تتخذ Apple قرارها

↓

تتلقى النتيجة كإشعار

↓

يتم تحديث الاستحقاق وصلاحية الوصول

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

ماذا تعني قواعد استرداد App Store بالنسبة للمطورين؟

أزل لغة السياسة، وستتحول القواعد إلى قائمة تحقق قصيرة وغير براقة إلى حد ما لفريقك الهندسي.

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

● نقطة نهاية للإشعارات تعمل وتتحقق من التوقيعات. تصل أحداث الاسترداد عبر App Store Server Notifications، وتكون الـ payloads موقّعة. تحقق من تلك التوقيعات في كل مرة. نقطة النهاية التي تثق بأي شيء يُرسل إليها هي خطر أمني مرفق بعنوان URL.

● تدفق موافقة، مُعدّ مسبقًا. إذا طلبت Apple معلومات الاستهلاك، فلا يُسمح لك بالرد إلا حيث وافق العميل مسبقًا على مشاركة تلك البيانات. هذه المسؤولية تقع عليك. وتوضح وثائق Send Consumption Information من Apple ذلك بشكل مباشر، وأي رد يُرسل دون موافقة يُرفض. كما لا يمكنك العودة لجمع الموافقة بعد وصول الطلب. إما أن تكون قد حصلت عليها وقت الشراء، أو تتنحى عن ذلك الطلب.

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

● مكان تستقر فيه النتائج ويمكن لفريق المالية استخدامه فعلًا. الاسترداد الموجود فقط داخل قاعدة بيانات التطبيق لن يتطابق أبدًا مع تقرير المدفوعات. معظم الفرق تكتشف ذلك عند إقفال ربع السنة، ونادرًا ما يكون يومًا جيدًا.

كيف تؤثر سياسة استرداد Apple على المطورين؟

الجميع يركز على المبلغ المسترد. وهو عادةً أصغر رقم في القصة.

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

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

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

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

ماذا يجب على المطورين فعله عند طلب استرداد من Apple؟

سبع خطوات. معظم العمل يحدث قبل ظهور أي طلب بوقت طويل.

1. استقبل الإشعار وتحقق منه

تصل أحداث الاسترداد إلى نقطة النهاية لديك كـ payloads موقّعة بصيغة JWS. تحقق من التوقيع مقابل سلسلة شهادات Apple. تأكد من معرّف الحزمة (bundle ID). وعندها فقط، تصرّف بناءً على المحتوى. هذه نظافة أساسية، ومع ذلك لا تزال بعض الفرق تتجاوزها. نقطة النهاية التي تقبل أي شيء يُعطى لها هي نقطة يمكن لشخص آخر استغلالها.

2. اعثر على المعاملة والحساب

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

3. راجع ما تعرفه بالفعل عن عملية الشراء

لا يمكنك إخبار Apple بأي شيء مفيد حتى تعرف ما سجّلته أنظمتك. هل تم تسليم المحتوى؟ هل عمل كما هو متوقع؟ ما مقدار ما استخدمه العميل منه فعلًا؟ إذا لم تستطع الإجابة عن هذه الأسئلة من سجلاتك، فهذه مشكلتك الحقيقية الأولى، وليست الاسترداد.

4. أرسل معلومات الاستهلاك عندما تطلبها Apple وتتوفر الموافقة

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

5. تتبّع النتيجة النهائية

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

6. حدّث الاستحقاق وصلاحية الوصول

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

7. سوِّ الأمر مع تقارير الإيرادات والاشتراكات

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

لماذا تصبح الإدارة اليدوية لاستردادات App Store صعبة

الأمر لا يتعلق بالإهمال. القيود ببساطة لا تناسب عملية تعتمد على وجود شخص مستيقظ ومنتبه على مدار الساعة.

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

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

كيف يمكن للمطورين إدارة استردادات App Store بشكل أكثر موثوقية؟

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

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

ما لا تستطيع فعله هو تغيير رأي Apple. الأتمتة لا تجعل عمليات الاسترداد أقل احتمالًا، ولا يمكنها التأثير على القرار، مهما أوحت بعض الأدوات بذلك. كل ما تغيّره هو ما إذا كان جانبك من العملية يحدث باتساق وفي الوقت المناسب، وهذا أمر يستحق الإصلاح بحد ذاته.

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

RefundSensor يغطي هذا الجزء من المهمة. يربط أحداث الاسترداد من App Store وGoogle Play بسير عمل مؤتمت، بحيث تخرج الردود ضمن نافذة المتجر دون أن يراقب أحد الإشعارات يدويًا، وتبقى سجلات الاسترداد دقيقة مع نمو الحجم. لن يغيّر ما تقرره Apple، لأن لا شيء يستطيع ذلك. لكنه يغيّر مقدار العمل الذي يتركه كل استرداد لفريقك بعد ذلك.

أين تُوثَّق هذه القواعد

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

طلب استرداد الأموال للتطبيقات أو المحتوى — السياسة التي يراها العملاء. تغطي كيفية تقديم الطلبات، ونافذة التحديث من 24 إلى 48 ساعة، وملاحظة Apple حول الأهلية الإقليمية.

Send Consumption Information — سير عمل الرد الموجه للمطورين. يغطي متطلب الموافقة، ونافذة الـ 12 ساعة، وحقول الطلب. يستحق القراءة كاملًا قبل التعامل مع معالجة الاستهلاك.

App Store Server Notifications — كيف تصل أحداث الاسترداد إلى الواجهة الخلفية لديك. يغطي صيغة الـ payload الموقّع وأنواع الإشعارات، بما في ذلك CONSUMPTION_REQUEST وREFUND وREFUND_DECLINED وREFUND_REVERSED.

إذا كانت أحداث الاسترداد لا تزال تُراجع يدويًا

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

إذا بدا ذلك مألوفًا، فيمكن لـ RefundSensor إخراج سير عمل الاسترداد من التتبع اليدوي: أحداث المتجر، ونوافذ الرد، والتأكد من وصول النتائج إلى سجلاتك ومنطق الاستحقاقات لديك على حد سواء.