تقارير الاسترداد لديك لا تتطابق أبدًا بين Apple و Google وخادمك، إليك كيفية تسويتها

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

لماذا يظهر استرداد واحد كثلاثة أرقام مختلفة

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

تمنحك Apple عائلتي تقارير، إضافة إلى webhook الخاص بك

تُبلغ Apple عن عمليات الاسترداد في مكانين ليسا الأداة نفسها وليسا مقصودين للتطابق في يوم معين. Sales and Trends هو العرض السريع المقدَّر: تصل التقارير اليومية في اليوم التالي، والتقارير الأسبوعية أيام الاثنين، والتقارير الشهرية بعد نحو خمسة أيام من انتهاء الشهر، عمومًا بحلول 8 a.m. Pacific. يقدّر المبيعات والعائدات بعملة USD باستخدام متوسط متحرك لأسعار صرف الشهر السابق، ما يجعله جيدًا لرصد اتجاه وخاطئًا لتسوية دفعة. Payments and Financial Reports هو العرض المسوّى: يُنشأ مرة في الشهر على التقويم المالي لـ Apple، ويتوفر بحلول أول جمعة من الشهر المالي الحالي عن الشهر المالي السابق، ويُنشأ فقط إذا كانت هناك عمليات شراء أو استرداد في تلك الفترة. يستخدم سعر الصرف النهائي المطبق على دفعتك. ذلك التقرير هو سجل المحاسبة. إلى جانب كليهما، يتلقى خادمك App Store Server Notification REFUND في اللحظة التي تمنح فيها Apple الاسترداد، مرتبطًا بـ transaction id واحد.

تنقسم Google بالطريقة نفسها

تعكس Google Play الانقسام. earnings report هو سجل المحاسبة، يُنشأ شهريًا ويتوفر عادةً بحلول اليوم الخامس من الشهر التالي، ويسرد عمليات الاسترداد كأنواع معاملات خاصة بها: Charge refund للمال المعاد إلى المشتري و Google fee refund لرسوم الخدمة التي تعيدها Google، كل منها موسوم بـ Full أو Partial. estimated sales report هو عرض التحليلات منخفض الكمون الذي يوضح ما دفعه المشترون قبل الضرائب والرسوم، وتقول Google صراحةً إنه مناسب للتحليلات وغير موصى به للمحاسبة. من جهة الخادم تحصل على Real-time Developer Notification في الوقت الفعلي ويمكنك قراءة استرداد من Voided Purchases API.

كيف تعرض Apple استردادًا داخل التقرير، وفخ السطر السالب

افتح Summary Sales Report ولن يطرح الاسترداد نفسه بهدوء من عملية بيع. يظهر كصف خاص به. تكون Units و Customer Price في ذلك الصف سالبة، وهذا كيف تكتشف الاسترداد أصلًا، ورقم Developer Proceeds لا يتصرف بالطريقة التي يتصرف بها السعر. التقرير ليس صافيًا من عمليات الاسترداد بطبيعته. يسرد صفوف الاسترداد بجانب صفوف البيع، وتقسيمها هو مهمتك. اجمع عمود Units بالنظر وستحسب مرتين أو تفوت عمليات الاسترداد تمامًا، لأن صف استرداد بقيمة ناقص واحد يجلس في العمود نفسه مع مبيعاتك الموجبة.

القاعدة العملية بسيطة: ابحث عن عمليات الاسترداد عبر Units السالبة، واجمع تلك الصفوف بمفردها، ولا تفترض أبدًا أن التقرير قد صفّاها لك مسبقًا. عدّ featured snippet لعمليات استردادك هو عدد الصفوف ذات Unit السالبة، وليس المجموع الحسابي لعمود.

التقويم المالي هو سبب عدم تطابق إجمالياتك الشهرية أبدًا

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

earnings report من Google شهري، لكنه يحمل توقيته الخاص ومنطقته الزمنية الخاصة، وليس أي منهما ساعة UTC لخادمك. الفخ الأعمق مشترك بين المتجرين: يُنسب الاسترداد إلى تاريخ تسويته، وليس تاريخ البيع الأصلي. استرد عملية شراء في مارس في أوائل أبريل وستقلل من أرقام أبريل لديك، وليس أرقام مارس. صفّ شهرين حسب تسمياتهما وسيبدو أن الاسترداد اختفى من أحدهما وتجسّد في الآخر.

كم يكلّف الاسترداد، وفي أي تقرير تقرؤه

التسوية في الحقيقة سؤال محاسبي، لذا اتبع المال. عند الاسترداد يعيد المتجر عمولته الخاصة، ما يعني أن المبلغ الذي يغادر حسابك فعليًا هو حصتك من البيع، وليس السعر الكامل الذي يراه العميل معادًا. على Google Play تكون تلك الإعادة سطرًا مرئيًا: نوع المعاملة Google fee refund في earnings report لديك هو رسوم الخدمة العائدة إليك، جالسًا بجانب Charge refund الذي ذهب إلى المشتري. على App Store، تخصم Apple عائداتك بعد العمولة وتعيد عمولتها في الحركة نفسها، لذا يعرض التقرير المالي الخصم صافيًا من حصة Apple.

توقيت التدفق النقدي هو حيث يُفاجأ المطورون. على Google Play، إذا استردت طلبًا قبل أن تدفع لك Google مقابله، فأنت ببساطة لا تتلقى ذلك المبلغ أبدًا. إذا استردت بعد الدفعة، تخصمه Google من دفعة مستقبلية. وإذا دفعت موجة من عمليات الاسترداد رصيدك إلى السالب وبقي سالبًا لمدة 48 ساعة على الأقل، فستخصم Google من الحساب البنكي الذي يتلقى دفعاتك عادةً قيمة العجز. الـ chargeback هو النسخة الأحدّ من الحدث نفسه: على Google Play، للطلبات الموضوعة في أو بعد August 3, 2026، ينقل الـ chargeback سعر الشراء بالإضافة إلى رسوم البنك إلى المطور، ويظهر في تقرير شهر لاحق عن الشهر الذي حدث فيه البيع.

كيف تسوّي تقارير الاسترداد لديك، خطوة بخطوة

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

• قرر السؤال قبل أن تفتح تقريرًا. للمال، يوجد الجواب في تقرير Apple المالي و earnings report من Google، لا غير. للوصول، يوجد الجواب في إشعارات خادمك. لا تسوِّ أحدهما مقابل الآخر أبدًا.
• اختر transaction id كمفتاح ربط عبر الأسطح الأربعة كلها. إنه الحقل الوحيد الذي يتشاركه البيع واستراده والتقارير و webhook الخاص بك جميعًا.
• بالنسبة إلى Apple، عندما يختلف Summary Sales Report مع webhook الخاص بك، استدعِ endpoint المسمى Get Refund History من App Store Server API على /inApps/v2/refund/lookup/{transactionId}. يعيد المعاملات المستردة الموقّعة لعميل، مع revocationDate و revocationReason، transaction id واحد في كل مرة، ويتنقل عبر صفحات تاريخهم. ذلك الـ endpoint هو الفيصل.
• بالنسبة إلى Google، قارن أسطر Charge refund في earnings report بما يبلّغ عنه Voided Purchases API للطلبات نفسها، وتذكّر أن الاسترداد الجزئي موسوم بـ Partial ولن يصفّر الرسم الأصلي.
• تحاذَ مع ساعة التقرير، وليس ساعتك. ساعة Apple هي شهر مالي بتوقيت Pacific. لـ earnings report من Google شهرها ومنطقتها الزمنية الخاصان. سجلاتك على الأرجح بتوقيت UTC. حوّل إلى تقويم التقرير قبل أن تقارن، وإلا فإن حدود اليوم وحدها ستخلق حالات عدم تطابق وهمية.
• توقّع أن يتحرك التقدير. Sales and Trends تقدير وسيستمر في التحرك كلما تسوّت المعاملات. سوِّ مقابل التقرير المالي، وليس أبدًا مقابل التقدير، وليس أبدًا مقابل لقطة الأمس من التقدير.

عندما يعرض خادمك عمليات استرداد أكثر من التقرير

الذعر الأكثر شيوعًا هو إيجاد إشعارات REFUND على خادمك أكثر من صفوف الاسترداد في تقرير المبيعات للنافذة الزمنية نفسها. عادةً ليس مالًا مفقودًا. يحسب السطحان لحظتين مختلفتين، وقد يسبق الإشعار صف التقرير بأيام، وقد ينتج استرداد جزئي أو طلب معاد تقديمه أكثر من حدث واحد. أبلغ المطورون عن هذا الشكل بالضبط، آلاف من إشعارات REFUND مقابل عدد أصغر من الصفوف ذات Unit السالبة للشهر نفسه. حلّها بالطريقة نفسها في كل مرة: خذ معرّفات transaction id التي رآها خادمك، مرّرها عبر Get Refund History، ودع سجل Apple الخاص يحسم أيها استُرد فعلًا وبكم.

النسخة القصيرة

لا يمكنك جعل تقدير Apple وتقرير Apple المالي و earnings report من Google و webhook الخاص بك تعرض جميعها إجمالي الاسترداد نفسه في اليوم نفسه، وعليك أن تتوقف عن المحاولة. اقرأ كل واحد لما هو مبني ليخبرك به. ثق بالتقرير المالي و earnings report للمال، وثق بإشعارات خادمك للوصول، وعندما يتنازع سطحان، اربطهما على transaction id ودع بحث Get Refund History أو Voided Purchases يحسم الأمر. عمليات الاسترداد المسوّاة ليست إجماليات مطابقة. إنها معاملات مطابقة.