من يطلب استرداد أمواله للمرة الرابعة ليس عميلاً غير راضٍ. إنه يتبع روتينًا معتادًا، وهذا يكلفك الإيراد المسترد بالإضافة إلى كل ما أنفقته في تنفيذ الطلب. يوفر كل من Apple و Google حقل هوية – appAccountToken من جهة، ومعرّف الحساب المموه (obfuscated account id) من الجهة الأخرى – يحوّل هذه الحوادث المتفرقة إلى نمط واضح.
أهم النقاط
لا تصل أدلّتك إلى المتجر إلا في حالتين فقط: طلب CONSUMPTION_REQUEST من Apple، الذي يمكن الرد عليه خلال 12 ساعة، ومراجعة الاسترداد (chargeback review) من Google Play عبر Review Refund API، التي يمكن الرد عليها خلال 24 ساعة. أما كل ما عدا ذلك، فيُحسم القرار فيه دون علمك.
في Apple، تنتقل UUID تُنشئها أنت مع عملية الشراء كقيمة appAccountToken. يربطها StoreKit بالمعاملة، وهذا يعني أن أي استرداد لاحق يُعزى إلى حساب واحد يمكن تحديده في سجلاتك الخاصة.
النظير لدى Google هو سلسلة نصية مجزّأة (hashed) لا يتجاوز طولها 64 حرفًا. تقرأ Google نفسها هذا الحقل لرصد السلوك غير المعتاد، كحساب واحد يشتري عبر عدد غير معقول من الأجهزة في فترة زمنية قصيرة.
وجود بيانات شخصية غير مشفّرة في ذلك الحقل لدى Google يؤدي إلى حظر عمليات الشراء فورًا. المطلوب هو قيمة مشفّرة أو تجزئة أحادية الاتجاه، وليس عنوان بريد إلكتروني خام.
يميّز حقل voidedReason في Play بين friendly_fraud وfraud وبين الاسترداد العادي الناتج عن تغيير الرأي، وهذا يعطيك مبررًا لإرسال المخالفين المتكررين إلى قائمة مراجعة بدلاً من المسار الافتراضي المتمثل في الاسترداد والمتابعة.
تفيد Google بأنها أوقفت أكثر من 2 مليار دولار من المعاملات الاحتيالية والمخالفة خلال عام 2022. وتعتمد هذه الدفاعات على إشارات الهوية التي لا توجد إلا إذا كانت عمليات الشراء تحملها.
الوصول الذي يستمر بعد الاسترداد يظل يستهلك مساحة التخزين، والحوسبة، وموازنة API التي لم تعد تتقاضى مقابلها، ومن يسترد أمواله عمدًا يدبّر هذه النتيجة بالضبط مرارًا وتكرارًا.
مقدمة
عمليات الاسترداد تحدث، وبعضها ليس أكثر من تكلفة تشغيلية عادية. ما يغيّر الصورة هو أن يعود الحساب نفسه للمرة الرابعة، بعد أن استهلك السلعة في كل مرة سابقة. ولا يمكنك إدراك هذا السلوك إلا إذا وصلت كل معاملة حاملةً معرّفًا خصصته أنت. وكلا النظامين يوفر معرّفًا من هذا النوع. كما يفتح كل منهما نافذة ضيقة للرد قبل أن يُحسم القرار النهائي. فإذا تجاهلت المعرّف، أو فوّت النافذة، أصبح من يستغل النظام لا يختلف عن شخص يطلب الاسترداد للمرة الأولى بشكوى حقيقية. وما يفصل بين الحالتين، وما قيمة هذا الفرق من الناحية المالية، هو ما سيأتي لاحقًا.
إساءة استخدام الاسترداد هي في الحقيقة مشكلة هوية متنكّرة في ثوب استرداد
قرارات الاسترداد مملوكة للمتجر. سيطلب العملاء الاسترداد، وفي معظم المسارات سيوافق المتجر، دون أي إمكانية للتدخل من جانبك. يكمن تأثيرك في موضع آخر: تحديد ما إذا كان لهذا الحساب بالذات سجل سابق بهذا السلوك، وما إذا كان ما شُري قد تم تسليمه واستخدامه فعلاً. وكلا السؤالين هو في الأساس سؤال عن الهوية: من هو المستخدم الذي يقف خلف هذه المعاملة، وماذا فعل من قبل. والمشتريات التي لا تحمل رابطًا ثابتًا بسجلات مستخدميك تجعل كلا السؤالين بلا إجابة، فيصل كل استرداد مجردًا من أي سياق.
هذه هي الثغرة التي يجدر إغلاقها. تحدد السياسات الآليات ولا يمكنك تغييرها. أما الأدلة، فجمعها مسؤوليتك، وتبدأ هذه العملية عند الدفع لا عند الاسترداد.
نافذتان فقط يُحسب فيهما حساب ما ترسله
مساران فقط يتعاملان مع ما تقدّمه كمُدخَل فعلي. فطلب العميل استردادًا لسلعة استهلاكية أو اشتراك متجدد تلقائيًا يُفعّل طلب CONSUMPTION_REQUEST من Apple، ويكون ردّك مستحقًا خلال 12 ساعة. ونزاع العميل على رسم مع بنكه يُفعّل مراجعة الاسترداد لدى Google Play، التي يمكن الرد عليها عبر Review Refund API خلال 24 ساعة. وفيما عدا هذين المسارين، يُحسم القرار دون تدخّلك: كالاسترداد الذاتي لدى Play ضمن 48 ساعة، أو استرداد يمنحه فريق الدعم، أو استرداد تلقائي لعملية شراء لم تقرّ بها قط.
وتصبح كلتا القناتين أكثر دقة بكثير عندما تحمل المعاملة معرّفك مسبقًا. فمعلومات الاستهلاك المُرسَلة إلى Apple يمكن أن تتضمن appAccountToken إلى جانب سجل إنفاق ذلك الحساب وتاريخه، في حين تستند مراجعة Google إلى معرّف الحساب المموه الذي كانت تراقبه منذ اكتمال الشراء. وحيث لا يوجد معرّف، لا يوجد سجل يمكن تقديمه.
مقارنة بين حقلَي الهوية
توصّلت الشركتان إلى حلول متطابقة تقريبًا تحت أسماء وقيود مختلفة. فكل منهما يتيح لك وسم عملية الشراء بقيمة تُعاد إلى سجل مستخدمك الخاص. ولا يُفعَّل أي منهما تلقائيًا نيابة عنك. وكلاهما عديم الفائدة إلا إذا تم ضبطه أثناء حدوث عملية الشراء.
Apple: appAccountToken
أنشئ UUID، ومرّره عند بدء عملية الشراء، فيربطه StoreKit بالمعاملة الناتجة. ثم يظهر هذا المعرّف في بيانات المعاملة التي يتحقق منها خادمك، ومرة أخرى في معلومات الاستهلاك التي تُرسلها خلال طلب CONSUMPTION_REQUEST. وبما أن القيمة نشأت من جانبك، فإنها تربط معاملة المتجر بسجل في قاعدة بياناتك دون أي تدخل من اسم أو بريد إلكتروني. ولا تُقبَل إلا قيم UUID حقيقية؛ وأي شيء آخر يُرفض. وقد أصدرت Apple منذ ذلك الحين نقطة وصول (endpoint) باسم Set App Account Token قادرة على كتابة أو تحديث هذا الرمز في معاملات حدثت فعلاً، بما في ذلك استبدال رموز العروض وعمليات الشراء المشابهة التي تتم خارج التطبيق.
Google Play: معرّف الحساب المموه
setObfuscatedAccountId هو إصدار Google من هذا المفهوم، وهو سلسلة نصية اختيارية مرتبطة بحساب الشراء. وتوضح وثائق Google الغرض منه دون مواربة: تستخدم Play هذه القيمة لرصد النشاط غير المعتاد، ومثالها المذكور هو عدة أجهزة تنفّذ معاملات على حساب واحد في غضون فترة قصيرة، ولإيقاف بعض عمليات الشراء الاحتيالية قبل اكتمالها. والحد الأقصى هو 64 حرفًا، والبيانات الشخصية غير المشفّرة ممنوعة. فوضع بريد إلكتروني خام هناك يؤدي إلى حظر الشراء، لأن ما يتوقعه الحقل هو قيمة مشفّرة أو تجزئة أحادية الاتجاه. والتطبيقات التي يحتوي فيها الحساب الواحد على ملفات تعريف متعددة لديها حقل مرافق هو setObfuscatedProfileId.
appAccountToken هو حقل Apple. يجب أن يكون قيمة UUID ولا شيء آخر، ويضبطه كودك عند الدفع، ويكون غائبًا إلا إذا أضفته أنت. تستخدمه Apple لربط المعاملة بمستخدمك، ويظهر مجددًا في حمولات المعاملة والاستهلاك.
obfuscatedAccountId هو حقل Google Play. يأخذ سلسلة نصية مجزّأة لا يتجاوز طولها 64 حرفًا، ويضبطه كودك عند الدفع، وهو أيضًا غائب افتراضيًا. تستخدمه Google في رصد النشاط غير المعتاد وفي إيقاف بعض عمليات الشراء الاحتيالية قبل اكتمالها.
هناك تباين واحد ذو أهمية بالغة. لا تقدّم Google أي إمكانية للتعبئة الرجعية (backfill) على الإطلاق. فعملية شراء في Play تمت دون المعرّف تظل مجهولة الهوية بشكل دائم، والحل الوحيد المتاح هو وسم عمليات الشراء المستقبلية. أما نقطة وصول Set App Account Token لدى Apple، فيمكنها إصلاح السجل التاريخي، وهذا ما يجعلها الاستثناء لا القاعدة.
حساب تكلفة استرداد من شخص يكرر ذلك باستمرار
الإيراد المسترد هو الجزء الظاهر، وهو أيضًا الجزء الأصغر. فمنح الاسترداد يعيد سعر البيع، وهو ما يسجله دفتر حساباتك. أما ما يغيب عن هذا البند، فهو كل ما أُنفق لإنتاج ما يحمله العميل الآن مجانًا.
تخيّل سلعة استهلاكية تُحرّك عملاً فعليًا: صور تُولَّد، ومجموعة من الاستدعاءات لمزوّد نموذج، ومقطع فيديو يُصدَّر، ومبلغ يُدفع لمُنشئ محتوى. تلك الموارد الحاسوبية اشتُريت في لحظة الاستخدام. والاسترداد يستعيد سعر البيع فقط، ويترك فاتورة المزوّد كما هي تمامًا. ومن اكتشف أن السلعة تبقى بعد الاسترداد، يكرر التسلسل بكل بساطة: يشتري، ويستهلك، ويسترد، وكل تكرار يحمّلك تكلفة التسليم مرة أخرى.
وهناك أيضًا تحوّل في التكاليف نحوك من جانب المنصة نفسها. فابتداءً من 3 أغسطس 2026، ستحمّل Google Play كلاً من سعر الشراء ورسوم استرداد البنك (chargeback) على المطورين بالنسبة للطلبات المقدَّمة من ذلك التاريخ. وستتحول النزاعات التي كانت إلى حد كبير تكلفة تتحملها Google إلى إيراد مفقود منك بالإضافة إلى رسم، ومن يقدّم نزاعات بشكل معتاد يرفع هذا الرقم مع كل محاولة. وحقول الهوية هي ما يجعل من الممكن تزويد Review Refund API بما يستحق القراءة خلال نافذة الـ 24 ساعة.
وتضع Google رقمًا يوضح حجم المشكلة: أكثر من 2 مليار دولار من المعاملات الاحتيالية والمخالفة جرى حظرها خلال عام 2022. ويعود وجود هذا الرقم إلى أن الإشارات الأساسية، ومن بينها معرّف الحساب المموه، كانت مُعبَّأة بالفعل. وإطلاق عمليات شراء بحقول فارغة هو قرار بوضع نفسك خارج هذه الحماية.
رصد المسترجعين المتكررين قبل أن يحكم المتجر
وسم كل عملية شراء بهوية تتحكم فيها
لا ينبغي لأي من المنصتين أن ترى عملية شراء دون هوية. فعمليات شراء StoreKit تحمل appAccountToken، وعمليات شراء Play Billing تحمل setObfuscatedAccountId، وتنشأ كلتا القيمتين من سجل مستخدمك الخاص. تتوقع Apple قيمة UUID حقيقية مرتبطة بذلك الحساب، وتتوقع Google مفتاح الحساب مجزّأً بحيث لا تنتقل أي بيانات شخصية بشكل صريح. ولحظة الدفع هي اللحظة المناسبة لكلتيهما، وفي حالة Google لا يمكن إعادة التفاوض على هذا التوقيت بعد ذلك.
احتفظ بدفتر حسابات مبني على هذه الهوية
سجّل عمليات التسليم، وأحداث الاستهلاك، والمشتريات، وحالات الاسترداد، وكل ذلك مدوَّن تحت هذا المعرّف. وهكذا يصبح الماضي الكامل لهذا الحساب، بما فيه عمليات الاسترداد السابقة، على مسافة استعلام واحد عند حدوث CONSUMPTION_REQUEST أو مراجعة استرداد. وتوفّر معلومات الاستهلاك لدى Apple حقولاً مخصصة لهذا النوع من البيانات بالضبط: consumptionStatus، وdeliveryStatus، وplayTime، وaccountTenure، وlifetimeDollarsPurchased، وrefundPreference الخاص بك.
تعامل مع voidedReason كقرار توجيه
تحمل عمليات شراء Play المُلغاة حقل voidedReason يوضح السبب، وتُسجَّل حالتا friendly_fraud وfraud بشكل منفصل عن الندم العادي على الشراء. وتستحق هذه الحالات قائمة مراجعة وسياسة أكثر صرامة بدلاً من المعالجة التلقائية التي يحصل عليها استرداد أول مرة. وتصف إرشادات Google استجابات متصاعدة: تحذير في البداية، وإجراء أكثر صرامة عند التكرار، وتعطيل عمليات الشراء للحسابات التي تستمر في ذلك.
لا تفوّت النافذة الزمنية أبدًا
الأدلة المُقدَّمة بعد فوات الوقت قد لا تختلف عن عدم وجودها على الإطلاق. فأتمِتْ الرد على CONSUMPTION_REQUEST بحيث يُرسَل بسهولة ضمن 12 ساعة، وكذلك مراجعة الاسترداد ضمن 24 ساعة. وسجل الحساب الذي لا تشوبه شائبة، إن قُدِّم بعد الموعد النهائي، يصبح سجلاً لن يفتحه أحد في المتجر.
لرصد حساب واحد ينفّذ معاملات عبر عدد غير معقول من الأجهزة في الوقت نفسه، استند إلى نظام رصد النشاط غير المعتاد لدى Google Play، الذي يقرأ معرّف الحساب المموه.
لمعرفة سجل استرداد سابق على هذا الحساب، استند إلى سجلاتك الخاصة، أي دفتر الحسابات الذي بنيته على معرّف أيٍّ من المنصتين.
لتأكيد أن السلعة وصلت فعلاً إلى المشتري واستُخدمت، استند إلى Apple، حيث يوجد consumptionStatus وdeliveryStatus داخل معلومات الاستهلاك.
لرصد نزاع هو في حقيقته احتيال من المشتري عليك، استند إلى Google Play، حيث يعود voidedReason بقيمة friendly_fraud.
أين تساعد المنصتان، وأين تتوقف مساعدتهما
من المفيد أن تكون دقيقًا بشأن تقسيم المسؤولية، لأن افتراض أن المتاجر تتولى إساءة الاستخدام أمر سهل، لكنها نادرًا ما تعلن عن النقطة التي تتوقف عندها. تقرأ Google بالفعل معرّف الحساب المموه لحظر بعض الاحتيال قبل الشراء، وتعترض الأنظمة على مستوى المنصة حجمًا كبيرًا منه. وتحتفظ Apple بكل قرار استرداد لنفسها، وتتعامل مع معلومات الاستهلاك التي تقدّمها كدليل لا كتصويت. وما لا تفعله أي من المتجرين هو الاحتفاظ بقائمة مخالفين نيابةً عنك، أو إعادة قيمة سلعة استهلاكية مستردة إلى رصيدك، أو رفض مسترجع متكرر من أجلك. فعلى الهوامش، تملك الهوية قرار التصرف للمتجر نفسه. وفي كل مكان آخر، القرار لك.
وقد صُمم Refund Sensor حول هذه الهوية للسبب نفسه. فالاسترداد، ومراجعة الاسترداد، وطلب الاستهلاك الخاصة بحساب واحد تتجمع في سجل واحد، بحيث يصبح النمط المتكرر ظاهرًا منذ الحادثة الثانية، لا بعد سداد الفاتورة الرابعة بالفعل.
مصادر توثيق هذه القواعد
Google Play Developer API: عمليات الشراء الملغاة (Voided Purchases)
Google Play Billing: اقتراحات الاسترداد ومراجعة الاسترداد عبر Review Refund API
Android Developers Blog: Play Commerce ومبلغ 2 مليار دولار المحظور في عام 2022
Google Play Console Help: حماية الاسترداد ومسؤولية تكلفة الاسترداد (chargeback)
الأسئلة الشائعة
يصف هذا المصطلح عميلاً يطلب استرداد أمواله مرارًا وتكرارًا بعد استلام واستخدام ما اشتراه، فيحتفظ بالمنفعة مع استرجاع المبلغ المدفوع. وفي سياق متاجر التطبيقات، يظهر ذلك غالبًا على هيئة حساب واحد يسترد قيمة سلع استهلاكية أو اشتراكات مرارًا وتكرارًا، أو على هيئة احتيال ودي (friendly fraud)، حيث يُعترَض على رسوم صحيحة عبر البنك بدلاً من ذلك.
في Apple، تُنشئ UUID وتُرسله كقيمة appAccountToken عند بدء الشراء، ويقوم StoreKit بربطه بالمعاملة الناتجة، حيث يظهر لاحقًا في بيانات المعاملة وبيانات الاستهلاك على السواء. وفي Google، تستدعي setObfuscatedAccountId باستخدام قيمة مجزّأة (hashed) مستمدة من ذلك الحساب. يتيح كلا النهجين ربط معاملة المتجر بسجل المستخدم الخاص بك دون الكشف عن أي بيانات شخصية.
لا، لن تفعل أي منهما ذلك، على الأقل ليس بشكل مباشر. تقرأ Google معرّف الحساب المموه (obfuscated account id) لتحديد النشاط غير المعتاد وإيقاف بعض عمليات الاحتيال قبل الشراء، وتقبل Apple سجل الحساب المُرسَل خلال طلب الاستهلاك (consumption request)، لكن لا تعيد أي من الشركتين قائمة بالمخالفين المتكررين. بناء هذه القائمة مسؤوليتك، ويُستمد من السجلات التي دوّنتها تحت هذه المعرّفات.
السبب المعتاد هو وجود بيانات شخصية غير مشفّرة في معرّف الحساب المموه. فوضع شيء كعنوان بريد إلكتروني خام هناك يجعل Play تحظر الشراء فورًا. بدلاً من ذلك، قدّم قيمة مشفّرة أو قيمة مجزّأة أحادية الاتجاه (one-way hash)، مع الالتزام بالحد الأقصى البالغ 64 حرفًا.
هو يقلّلها بدلاً من أن يوقفها. يُعدّ CONSUMPTION_REQUEST أحد المسارين الوحيدين اللذين تصل فيهما أدلّتك قبل اتخاذ القرار، ويساعد سجل الحساب إلى جانب بيانات التسليم والاستهلاك Apple على تمييز إساءة استخدام الاسترجاع والاحتيال الودي. ومع ذلك، يبقى القرار النهائي بيد Apple، وتظل إساءة الاستخدام التي تمر عبر مسارات لا يمكنك الاعتراض عليها دون معالجة.
