كيف يمكن للمطورين استخدام بيانات الشراء للرد على طلبات استرداد الأموال

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

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

أهم النقاط

• تتخذ Apple و Google قرار الاسترداد بنفسيهما، وكلاهما يطلب منك الآن بيانات الشراء أولًا. تمنحك Apple 12 ساعة، وتمنحك Google 24 ساعة.

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

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

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

• التطبيقات التي تبدأ بالرد تشهد انخفاضًا في معدلات الاسترداد بنحو الثلث، ولكن فقط إذا كان هناك ما يمكن قوله من السجلات.

ما يطلبه المتجران منك فعليًا

طلب Apple صغير. عندما يطلب عميل استردادًا لعملية شراء داخل التطبيق، تحصل على CONSUMPTION_REQUEST، وترد عبر نقطة النهاية Send Consumption Information بخمسة حقول: هل وافق العميل على مشاركتك للبيانات، وهل تم تسليم عملية الشراء، وما النسبة التي تم استهلاكها (بوحدة المليونية، حيث يمثل 100,000 الاستهلاك الكامل)، وهل حصل على نسخة تجريبية أو فترة مجانية أولًا، وتفضيلك بشأن الاسترداد. كانت Apple في السابق تطلب اثني عشر حقلًا وتخلّت عن معظمها، وأفسّر ذلك على أنه قرار من Apple بأنها تعرف تاريخ العميل بالفعل أفضل منك.

نسخة Google مخصصة لعمليات استرداد المدفوعات (chargebacks)، وهي أغنى قليلًا. يصل إشعار مراجعة استرداد معلّق عبر Real-time Developer Notifications مع رمز (token). ترسل طلبًا إلى orders.reviewrefund مع هذا الرمز، وعلامة النسخة التجريبية نفسها، وتفضيل من بين DECLINE أو APPROVE أو NEUTRAL، ونسبة استهلاك اختيارية، وما يصل إلى 1000 حدث استخدام مع طوابع زمنية. ويزداد هذا الأمر أهمية الآن بعد أن أصبحت Google تفرض على المطورين رسومًا عن عمليات استرداد المدفوعات على الطلبات التي تتم بعد 3 أغسطس 2026.

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

سجل الشراء الخاص بالاسترداد: ما يجب الاحتفاظ به ولأي مدة

الحد الأدنى:

معرّف عند الدفع. appAccountToken في Apple، وobfuscatedAccountId في Google. بدونه، يذكر طلب الاسترداد معاملة معينة ولا تملك أي فكرة عن هوية صاحبها. كما توصي فرق Apple التقنية بالاحتفاظ بمعرّف originalTransactionId واحد على الأقل لكل مستخدم، لأنه بواسطة أي واحد منها يمكنك استدعاء Get Transaction History واستخراج سجل الشراء الكامل لذلك العميل في تطبيقك، سواء كان لا يزال مثبتًا على جهازه أم لا.

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

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

علامة نسخة تجريبية لكل منتج. هل حصل هذا العميل على فترة تجريبية، أو معاينة، أو مستوى مجاني؟ إجابة بنعم أو لا في كلا المتجرين، وكثيرًا ما ينسى الناس تسجيلها.

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

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

كيف يساعد سجل الشراء في عمليات الاسترداد

بمجرد أن يكون ذلك جاهزًا، لا يعود الطلب قرارًا تقديريًا بل يصبح عملية بحث بسيطة.

تم التسليم، والاستهلاك كامل، ولا نسخة تجريبية، ولا عمليات استرداد سابقة: هذه حالة مناسبة لـ DECLINE. تم التسليم، ولم يُستخدم إلا بشكل طفيف، وطُلب الاسترداد في غضون يوم واحد: هنا تكلّف GRANT_FULL القليل والبديل يبدو تافهًا. فشل التسليم من جانبك: وافق على الاسترداد وأصلح الخلل. استُخدم جزئيًا على مدى عدة أسابيع: لدى Apple خيار GRANT_PRORATED لهذه الحالة، وفي Google تؤدي نسبة الاستهلاك الدور نفسه.

والأرقام تؤكد ذلك. بدأ تطبيق Dipsea، وهو تطبيق صوتي يعمل بنظام الاشتراك، بالرد على طلبات Apple في أواخر عام 2024، فانخفض معدل الاسترداد لديه من 3 percent إلى 1.9 percent في غضون نحو أسبوعين. وفي ما يتعلق باسترداد المدفوعات، أخبرت Appcharge موقع PocketGamer أن النزاعات غير المدعومة بالأدلة تُكسب بنسبة 20 إلى 30 percent من الوقت، بينما تُكسب النزاعات المدعومة بالأدلة بنسبة تزيد عن 80 percent. وفي أكثر من 800 تطبيق على Refund Sensor، تم الدفاع عن 77 percent من الطلبات المؤهلة، أما الطلبات التي خسرناها فكان معظمها بلا أي بيانات مسجّلة.

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

كيف تعالج طلبات الاسترداد ضمن المهلة المحددة

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

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

برمجيات معالجة الاسترداد للمطورين، أو شيفرتك الخاصة

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

إذا كنت تستخدم RevenueCat أو Adapty، فكلاهما يرد على طلبات استهلاك Apple بالاستناد إلى بيانات الاستخدام التي تجمعها SDKs الخاصة بهما بالفعل، وتغطي Adapty مراجعة Google أيضًا. خيار افتراضي معقول إذا كان SDK موجودًا في التطبيق على أي حال.

تقوم Refund Sensor بنفس المهمة دون الحاجة إلى SDK. تربط مفتاح API من App Store Connect ورابط إشعارات، فيستقبل الطلبات، ويرسل الرد ضمن المهلة المحددة، ويحتفظ بسجل زمني لكل حالة. يستغرق الإعداد بضع دقائق والتسعير ثابت. التفاصيل موجودة على موقع Refund Sensor.

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

الخلاصة

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

اربط معرّفًا، وسجّل التسليم والاستهلاك بطوابع زمنية، وضع علامة على النسخ التجريبية، واحتفظ بكل ذلك لمدة 90 يومًا. وبوجود ذلك، تصبح كيفية معالجة طلبات الاسترداد مجرد قاعدة ومهمة مجدولة (cron job)، ويميل معدل الاسترداد إلى الانضباط من نفسه.